Electron is flash for the desktop (2016)(josephg.com)
josephg.com
Electron is flash for the desktop (2016)
https://josephg.com/blog/electron-is-flash-for-the-desktop/
188 comments
Previous discussion: https://news.ycombinator.com/item?id=14087381
and https://news.ycombinator.com/item?id=14121437 of similar vintage.
And nothing has changed since that discussion, really. The top post is still correct: if Electron didn't exist we wouldn't be seeing a collection of beautiful, performant desktop apps. We'd just have fewer desktop apps, and you'd be using your web browser more. Particularly on Linux.
Which, IMO, is fine! I don't use the Slack desktop app, I have a tab open in my browser. It can 'ping' the tab bar to get my attention, and it can send notifications. It works fine.
Which, IMO, is fine! I don't use the Slack desktop app, I have a tab open in my browser. It can 'ping' the tab bar to get my attention, and it can send notifications. It works fine.
Counterargument at least SOME people would be shipping actual apps that are worth something. 1 app worth using is better than 5 subpar ones.
No it isn't, flash was the best way to do many things for the years it was popular. Video, vector animation, simple interactivity.
Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language. Maybe a case could be made for severe misconceptions also helping electron like 'a custom native app has to be made for each platform', even though C++ and Qt and many other combinations can be written once with 99% of the source being the same for every platform.
Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language. Maybe a case could be made for severe misconceptions also helping electron like 'a custom native app has to be made for each platform', even though C++ and Qt and many other combinations can be written once with 99% of the source being the same for every platform.
I have never seen Qt be proposed without immediately being shot down for the licensing.
Isn’t Gnome/GTK supposed to be kind of close?
I was under the impression that it was available under the lgpl and only had to open source changes to the actual library that you aren't likely to need to make not your application.
It doesn't matter what the actual requirements are, the issue is that it gets dismissed out of hand for the perceived requirements.
Which is usually based on just misunderstanding LGPL.
You "can" write a proprietary app with Qt and you wouldn't have to pay for it.
You "can" write a proprietary app with Qt and you wouldn't have to pay for it.
Why did you put "can" in quotes?
You have to ensure you keep your business code separate from the Qt code. It's extra work that people might not want to deal with when they are more comfortable with other options that don't require special care.
To be specific, if you modify actual Qt code--which you shouldn't be doing generally--then you have to release those modifications.
But if you dynamically link your app with Qt you're fine; you don't have to open source anything.
But if you dynamically link your app with Qt you're fine; you don't have to open source anything.
You also must provide the Qt source code yourself, giving instructions on how to get Qt from the official website is not sufficient.
You also must allow relinking of your proprietary binary with different versions of Qt. This is easy on desktops but not on embedded or mobile devices.
You also may not begin using a commercial license for your proprietary code which you developed using the LGPL licensed Qt, unless you have written permission. Part of this also means you cannot use, let's say, a MIT licensed wrapper or utility for Qt, because that was probably developed against the LGPL licensed Qt, and thus cannot be used with a commercially licensed Qt.
There's certainly a reason people worry about Qt licensing.
Source: https://www.qt.io/faq/
(And despite all this, let's remember how great it is that one of the best widget toolkits in the world is open source.)
You also must allow relinking of your proprietary binary with different versions of Qt. This is easy on desktops but not on embedded or mobile devices.
You also may not begin using a commercial license for your proprietary code which you developed using the LGPL licensed Qt, unless you have written permission. Part of this also means you cannot use, let's say, a MIT licensed wrapper or utility for Qt, because that was probably developed against the LGPL licensed Qt, and thus cannot be used with a commercially licensed Qt.
There's certainly a reason people worry about Qt licensing.
Source: https://www.qt.io/faq/
(And despite all this, let's remember how great it is that one of the best widget toolkits in the world is open source.)
I don't mean to be harsh, but everything you wrote here is either wrong or misleading.
> You also must provide the Qt source code yourself, giving instructions on how to get Qt from the official website is not sufficient.
This isn't true [1].
> You also must allow relinking of your proprietary binary with different versions of Qt. This is easy on desktops but not on embedded or mobile devices.
If I'm distributing a game written with SDLv1 on mobile, I don't have to do anything at all differently than if I distribute the exact same game on desktop. Many, many games did this.
> You also may not begin using a commercial license for your proprietary code which you developed using the LGPL licensed Qt, unless you have written permission. Part of this also means you cannot use, let's say, a MIT licensed wrapper or utility for Qt, because that was probably developed against the LGPL licensed Qt, and thus cannot be used with a commercially licensed Qt.
This is also not at all true [2], in fact they couldn't release Qt under the LGPL if it were. That would be LGPL with a non-commercial-use clause, which would be incompatible.
> There's certainly a reason people worry about Qt licensing.
Yeah and honestly, it's because there's a lot of bad information out there. GPL and LGPL are subject to so much FUD. We as developers have a responsibility to know the facts.
[1] https://copyleft.org/guide/comprehensive-gpl-guidech10.html#...
[2] https://www.qt.io/faq/ (section 3.7)
> You also must provide the Qt source code yourself, giving instructions on how to get Qt from the official website is not sufficient.
This isn't true [1].
> You also must allow relinking of your proprietary binary with different versions of Qt. This is easy on desktops but not on embedded or mobile devices.
If I'm distributing a game written with SDLv1 on mobile, I don't have to do anything at all differently than if I distribute the exact same game on desktop. Many, many games did this.
> You also may not begin using a commercial license for your proprietary code which you developed using the LGPL licensed Qt, unless you have written permission. Part of this also means you cannot use, let's say, a MIT licensed wrapper or utility for Qt, because that was probably developed against the LGPL licensed Qt, and thus cannot be used with a commercially licensed Qt.
This is also not at all true [2], in fact they couldn't release Qt under the LGPL if it were. That would be LGPL with a non-commercial-use clause, which would be incompatible.
> There's certainly a reason people worry about Qt licensing.
Yeah and honestly, it's because there's a lot of bad information out there. GPL and LGPL are subject to so much FUD. We as developers have a responsibility to know the facts.
[1] https://copyleft.org/guide/comprehensive-gpl-guidech10.html#...
[2] https://www.qt.io/faq/ (section 3.7)
No, you don't. You just need to provide a way to replace or relink Qt libraries. Unless of course you modify Qt itself, but then you only have to publish those modifications. Absolutely nothing requires you to "keep you business code separate from the Qt code".
Misunderstanding or not, that's the reason.
With most software developers and most managers not moonlighting as lawyers, misunderstandings are to be expected.
With most software developers and most managers not moonlighting as lawyers, misunderstandings are to be expected.
I am wondering what is the issue with dynamically linking Qt, are developers statically linking with MS c/c++ runtime or GUI libs ? From my experience you must install c++ runtimes on windows or if you use C# you need to ask your user to make sure to have it installed, where with Qt you ship the dlls.
My understanding is that Windows has an odd memory allocation system where each DLL has its own allocator. Qt historically wasn't designed for that; it will allocate and return objects on the heap with the understanding that user code will free them.
They may have solved this since by using a custom allocator on windows for Qt types.
They may have solved this since by using a custom allocator on windows for Qt types.
Is this related to statically linking? HOW are alternatives like Electron? can you bundle your Electron app into a big binary file ? From my experience in year back when doing desktop apps there was never a pressure to combine your dependencies into 1 big binary
[deleted]
1% difference is a lot in software development. Electron is like Flash, it allows cross platform apps with one codebase. By the way Flash used ActionScript which have a lot in common with JS so that’s another similarity.
electron also allows sharing code between web and mobile, plus the cross platform. afaik qt doesn't address that.
>Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language.
Why is there always someone ready to jump in with this elitist nonsense? There's plenty of reasons to use a web stack even if you know other languages. It's inherently crossplatform, has an extensive library, and is extremely quick to iterate on.
Slack and Discord building in Electron means they only need to maintain one codebase across web, desktop, and mobile. They don't need separate teams for building in Java, Swift, and C#. They only need to write a new feature once. Crazy, right?
This "web programmers are dumb" attitude is nothing but elitist rhetoric. Cut it out.
Why is there always someone ready to jump in with this elitist nonsense? There's plenty of reasons to use a web stack even if you know other languages. It's inherently crossplatform, has an extensive library, and is extremely quick to iterate on.
Slack and Discord building in Electron means they only need to maintain one codebase across web, desktop, and mobile. They don't need separate teams for building in Java, Swift, and C#. They only need to write a new feature once. Crazy, right?
This "web programmers are dumb" attitude is nothing but elitist rhetoric. Cut it out.
Qt is also cross-platform, easy to use, and has a giant library to work with. You can use it with virtually any language you want. Plus it runs on mobile.
and lets not forget, it looks like this:
https://doc.qt.io/qt-5/qtwidgets-mainwindows-application-exa...
You didn´t really counter the parent´s post with an argument. You just pretended to do so by suggesting an alternative that is incompatible with the requirements he had in mind because you think you know better...
https://doc.qt.io/qt-5/qtwidgets-mainwindows-application-exa...
You didn´t really counter the parent´s post with an argument. You just pretended to do so by suggesting an alternative that is incompatible with the requirements he had in mind because you think you know better...
> and lets not forget, it looks like this
What are you trying to show here?
What are you trying to show here?
"It looks like this"
That just shows how little you know. One style in one configuration looks like that.
That just shows how little you know. One style in one configuration looks like that.
Qt is really trivial to style. That's like showing a blank HTML page without any CSS and discounting HTML because of that default appearance.
Yep, when all that one has is programmer art.
Doing web apps without CSS skills won't look much better.
Doing web apps without CSS skills won't look much better.
Qt is not suitable for building web pages/apps.
> You can use it with virtually any language you want.
huh!? When did this happen?
Spoiler Alert: It didn't.
huh!? When did this happen?
Spoiler Alert: It didn't.
> There's plenty of reasons to use a web stack even if you know other languages. It's inherently crossplatform, has an extensive library, and is extremely quick to iterate on.
The GP's point was that, in the year 2019, none of these features are unique to the web.
• For "frameworks", there's Silverlight, Adobe Air, Haxe, and—strangely enough—Flash itself, which still works just fine if your goal is to ship a standalone "projector" app rather than something that runs in a browser.
• Or you can use a cross-platform scripting language (e.g. Python) with a cross-platform GUI toolkit (e.g. QT, WxWidgets.)
• Or you can use a not-cross-platform language (e.g. C#) but just use the (pretty large) subset of that language that is compatible with a third-party cross-platform runtime (e.g. Mono). Before you laugh, this is exactly how many companies code games to be cross-platform: they just write them for Win32 but constantly test them under Wine to ensure they aren't breaking Wine compatibility. Then they ship one native version and two virtualization-layer-wrapped versions.
• Or—horror of horrors—you can just use Java, and use the various Java-to-native-X compilers to target mobile platforms like iOS. (It worked well enough for Minecraft!)
The GP's point was that, in the year 2019, none of these features are unique to the web.
• For "frameworks", there's Silverlight, Adobe Air, Haxe, and—strangely enough—Flash itself, which still works just fine if your goal is to ship a standalone "projector" app rather than something that runs in a browser.
• Or you can use a cross-platform scripting language (e.g. Python) with a cross-platform GUI toolkit (e.g. QT, WxWidgets.)
• Or you can use a not-cross-platform language (e.g. C#) but just use the (pretty large) subset of that language that is compatible with a third-party cross-platform runtime (e.g. Mono). Before you laugh, this is exactly how many companies code games to be cross-platform: they just write them for Win32 but constantly test them under Wine to ensure they aren't breaking Wine compatibility. Then they ship one native version and two virtualization-layer-wrapped versions.
• Or—horror of horrors—you can just use Java, and use the various Java-to-native-X compilers to target mobile platforms like iOS. (It worked well enough for Minecraft!)
> none of these features are unique to the web.
The web has all of them, I have yet to find another platform/language that meets all the same criteria.
Combine all of the above with a rich toolchain and extreme dev tools portability -- I can be up and running on basically any machine in minutes. As well as ease of deployment (at least for hobby projects).
All of those other platforms are, for me, less in one of the axes I care about. I've developed extensively in Python, C#, and Java for both personal and professional projects and while I like developing in them for many, many reasons, when I need to start a new project I nearly always find myself reaching for Javascript as the starting point.
The web has all of them, I have yet to find another platform/language that meets all the same criteria.
Combine all of the above with a rich toolchain and extreme dev tools portability -- I can be up and running on basically any machine in minutes. As well as ease of deployment (at least for hobby projects).
All of those other platforms are, for me, less in one of the axes I care about. I've developed extensively in Python, C#, and Java for both personal and professional projects and while I like developing in them for many, many reasons, when I need to start a new project I nearly always find myself reaching for Javascript as the starting point.
[deleted]
>For "frameworks", there's Silverlight, Adobe Air, Haxe, and—strangely enough—Flash itself...
With the exception of Haxe (and maybe Air), these are all dead or dying technologies.
Options 2 (Python/QT) works great, but is certainly more development hours and still requires platform-specific code.
>It worked well enough for Minecraft!
Minecraft was rewritten in C++ for mobile. It doesn't use Java.
With the exception of Haxe (and maybe Air), these are all dead or dying technologies.
Options 2 (Python/QT) works great, but is certainly more development hours and still requires platform-specific code.
>It worked well enough for Minecraft!
Minecraft was rewritten in C++ for mobile. It doesn't use Java.
Minecraft (Bedrock, the engine used by Android, iOS and modern console versions) is written in C++ with custom renderers for different platforms it target. They don't compile their Java code to native code.
> Why is there always someone ready to jump in with this elitist nonsense?
Because it's absolutely true. You'll know it once you watch a web dev try and work on desktop app.
Because it's absolutely true. You'll know it once you watch a web dev try and work on desktop app.
People working outside of their comfort zones generally don't know all the answers. That goes both ways. I recently watched a desktop developer reach for a Java servlet because they didn't know Javascript.
I think thee is also definitely a problem where if you don't use the right/current fad/popular stack you'll have a lot of trouble hiring people to work on your stuff.
Especially true since front and back end web stuff is so huge and high paying. problem comes when those stacks are a very poor fit for the problem at hand. But sure you could get an old neck beard to write that in C++ instead of java/Ruby or Node.js. Great you only need a single core embedded processor and it doen't even get hot! And yeah then who's going to maintain it?
Especially true since front and back end web stuff is so huge and high paying. problem comes when those stacks are a very poor fit for the problem at hand. But sure you could get an old neck beard to write that in C++ instead of java/Ruby or Node.js. Great you only need a single core embedded processor and it doen't even get hot! And yeah then who's going to maintain it?
I keep seeing this "extremely quick to iterate on" point being brought up in defense of Electron. Slack released threads 2 years ago and we still can't post snippets, images, or use many slash commands inside them. Their last genuinely new features in the last year were synced DM drafts and the little lock badge on workspaces you're signed out of. Where's the iteration?
Meanwhile, almost daily I hit so many issues with the macOS application that I have to walk away from my computer in frustration. It makes my working life miserable due to its poor performance and bugs, and it encourages awful organizational and communication habits.
Meanwhile, almost daily I hit so many issues with the macOS application that I have to walk away from my computer in frustration. It makes my working life miserable due to its poor performance and bugs, and it encourages awful organizational and communication habits.
It's a bit anecdotal, but I imagine Slack is being careful because they are targeting businesses. Discord is a similar platform which iterates new features extremely quickly.
If that is the case, Slack should want to maximize features, even to the point of excess redundancy, so users can tailor their business product to the specific needs of their business. People don't work productively being boxed into one way of doing something, people work best if they are free to find their own ideal way of doing that thing or are able to tailor the product to the unique tasks they work on.
Think of all the different code editors developers use. Some are straightforward, some have a steep learning curve, yet the good ones are good because users can customize them toward their own personal preferences.
Think of all the different code editors developers use. Some are straightforward, some have a steep learning curve, yet the good ones are good because users can customize them toward their own personal preferences.
> Slack and Discord building in Electron means they only need to maintain one codebase across web, desktop, and mobile. They don't need separate teams for building in Java, Swift, and C#.
Did you know that Slack has native iOS and Android apps, as well as a cross-platform C++ "LibSlack" run by another separate team?
Did you know that Slack has native iOS and Android apps, as well as a cross-platform C++ "LibSlack" run by another separate team?
I didn't. Are you saying they're not simple containers?
Not quite sure what you mean by "simple containers", but yes, they're native apps written in Objective-C and Java IIRC. And here's some more information on LibSlack: https://slack.engineering/libslack-the-c-library-at-the-foun...
Wait a minute. I have seen the argument for Electron because devs "get" to use one language they already know. So, let's just take a step back and reset...
> This "web programmers are dumb" attitude is nothing but elitist rhetoric.
I don't think that's the attitude. The attitude is that they are lazy/stubborn, not dumb. I personally believe most developers are smart enough to keep learning. Whether or not they are willing to put in the work is the question.
I don't think that's the attitude. The attitude is that they are lazy/stubborn, not dumb. I personally believe most developers are smart enough to keep learning. Whether or not they are willing to put in the work is the question.
"They only need to write a new feature once. Crazy, right?"
Yeah!, why you old farts want me to learn about the stack, the heap and all of that OS architecture crap?, I don't need or want that #$@&*, I barely can keep up with all the JavaScript frameworks/libraries/toolkits that came out last week!
Yeah!, why you old farts want me to learn about the stack, the heap and all of that OS architecture crap?, I don't need or want that #$@&*, I barely can keep up with all the JavaScript frameworks/libraries/toolkits that came out last week!
> Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language.
What toolkit or library would you propose instead? Seriously, what are these great alternatives? Doesn't necessarily have to support JS.
What toolkit or library would you propose instead? Seriously, what are these great alternatives? Doesn't necessarily have to support JS.
There's a ton of really popular, well-supported options
* GTK
* Qt
* WPF for Windows
* JavaFX
* Tk
* LibUI
I'm rooting for https://github.com/revery-ui/revery/ right now too, but it's still early in development
* GTK
* Qt
* WPF for Windows
* JavaFX
* Tk
* LibUI
I'm rooting for https://github.com/revery-ui/revery/ right now too, but it's still early in development
How many of those run on the web as a platform? (A cursory search suggests 'not many' or 'not without some effort'?)
There are some components I'd ideally like to avoid rewriting for my web and desktop applications. (E.g. why should I have to write render code for my friends list component more than once?)
There are some components I'd ideally like to avoid rewriting for my web and desktop applications. (E.g. why should I have to write render code for my friends list component more than once?)
I'm sure Revery does, don't know about the others.
As someone who used to develop with some of those options, I'm frankly glad that I can use HTML/CSS and Electron + React. It's much easier on the developer, even if it's less performant for the end user.
That's exactly the problem: the developer prioritizing their own convenience over the end user experience.
I can also just not write the software.
It's not like I don't get the pain of slow tooling. I cut my teeth on C++. However, it's not a laziness issue, it's trading performance in one place for functionality in another. Case in point, at the time I chose C++ because I was trying to do game development in the pre-unity days. These days I'd choose Unity in a heartbeat because it's fast enough and saves me a lot of busywork. I could write more performant code from scratch, but it's really not worth the extra months spent wrangling polygons because the game never gets made.
It's not like I don't get the pain of slow tooling. I cut my teeth on C++. However, it's not a laziness issue, it's trading performance in one place for functionality in another. Case in point, at the time I chose C++ because I was trying to do game development in the pre-unity days. These days I'd choose Unity in a heartbeat because it's fast enough and saves me a lot of busywork. I could write more performant code from scratch, but it's really not worth the extra months spent wrangling polygons because the game never gets made.
> GTK
GTK hasn't been well maintained or developed for ages and has always had poor docs. I wouldn't feel confident trying it on any platform which isn't its home (i.e. Linux).
> Qt
Qt is probably the best option in the list but it's language support is poor, only C++ and Python are practical. It is a big fully featured and mature library, but developing with QML is a poor experience compared to the tooling available on Chrome/Electron. Packaging and distributing Python and/or C++ Qt apps is a huge PITA too.
> WPF for Windows
not cross platform
> JavaFX
JavaFX looked interesting but just didn't seem to take off and develop a reasonable ecosystem around it. Certainly nothing that could rival the web ecosystem. I do love the language support that the JVM delivers. Regarding deployment size it isn't likely to be much better than Electron as most apps have to ship the whole JVM anyway. The stench of Oracle does taint it these days too.
> Tk
be serious
> LibUI
This isn't mature yet and it looks like another optimistic adventure in "write once, debug everywhere" like WxWidgets.
None of the options here can compete with Electron in terms of ecosystem or developer experience (often Chrome's dev tools). Nor are they built on open standards. Also JS is up there with the JVM and .Net platform in terms of languages which target and can run on it.
GTK hasn't been well maintained or developed for ages and has always had poor docs. I wouldn't feel confident trying it on any platform which isn't its home (i.e. Linux).
> Qt
Qt is probably the best option in the list but it's language support is poor, only C++ and Python are practical. It is a big fully featured and mature library, but developing with QML is a poor experience compared to the tooling available on Chrome/Electron. Packaging and distributing Python and/or C++ Qt apps is a huge PITA too.
> WPF for Windows
not cross platform
> JavaFX
JavaFX looked interesting but just didn't seem to take off and develop a reasonable ecosystem around it. Certainly nothing that could rival the web ecosystem. I do love the language support that the JVM delivers. Regarding deployment size it isn't likely to be much better than Electron as most apps have to ship the whole JVM anyway. The stench of Oracle does taint it these days too.
> Tk
be serious
> LibUI
This isn't mature yet and it looks like another optimistic adventure in "write once, debug everywhere" like WxWidgets.
None of the options here can compete with Electron in terms of ecosystem or developer experience (often Chrome's dev tools). Nor are they built on open standards. Also JS is up there with the JVM and .Net platform in terms of languages which target and can run on it.
Electron is the best way for a third-party to wrap someone else's web-app into a more-fully-featured desktop app when that someone else doesn't want to ship a native app.
For example, there are a number of desktop Facebook Messenger "clients", that can pop OS notifications and so forth. They're all based on Electron. None of them are built by Facebook.
Similarly, there are a number of desktop Gmail "clients", not built by Google. They're all Electron, too.
The only alternative to this approach, would involve reverse-engineering the company's web-app's (proprietary, undocumented) API to write a native client library for it, and then constantly fighting the company as they try to block your native client library from being able to access their backend service. Some projects do that (there are at least two "native Gmail clients" that are actually native and are built on a reverse-engineering of the Gmail web-app backend API) but it's really not worth it if you're just a dev trying to scratch your own itch of wanting better desktop integration from these web-apps.
For example, there are a number of desktop Facebook Messenger "clients", that can pop OS notifications and so forth. They're all based on Electron. None of them are built by Facebook.
Similarly, there are a number of desktop Gmail "clients", not built by Google. They're all Electron, too.
The only alternative to this approach, would involve reverse-engineering the company's web-app's (proprietary, undocumented) API to write a native client library for it, and then constantly fighting the company as they try to block your native client library from being able to access their backend service. Some projects do that (there are at least two "native Gmail clients" that are actually native and are built on a reverse-engineering of the Gmail web-app backend API) but it's really not worth it if you're just a dev trying to scratch your own itch of wanting better desktop integration from these web-apps.
Even if you were equally proficient in C++ and JavaScript, you can't tell me that Electron isn't significantly more productive.
Add up all the time and resources wasted by an Electron application for all users over the lifetime of the application, then compare that to the amount of developer time supposedly saved.
It’s about time to market and iteration speed being important success factors, coupled with users accepting the costs in exchange for the benefits.
So it is ok because money? I don't accept that reasoning. Computers today are orders of magnitude faster than they were in the past yet this concept of developer time being so much more important than everyone else's has them still feeling slow and unresponsive on essentially the same tasks we were performing 30 years ago.
This is why I hate this industry.
This is why I hate this industry.
I think it’s an economic reality for for-profit companies that make apps. If company A doesn’t go the html app route, and company B does for the same effective product, company B will have an advantage. It’s almost to the point where if your company app can be developed this way, you must do it this way to stay competitive.
It might feel like this, but if you boot up an old Windows XP machine and edit some text, it's still going to feel slow as hell in comparison to Atom on a modern machine. We get used to what's "fast" to do on our computers, and anything significantly slower than that feels "slow". And sure, the software is much less efficient. But compare it on hardware from the time it was developed, and it's not as bad as it seems.
And it's not just about money. With Discord as an example, they are able to quickly develop and deliver a great product, iterate on new features and integrations, and support all major platforms including web browsers. Their choice to use a web based stack helps A LOT with this.
And it's not just about money. With Discord as an example, they are able to quickly develop and deliver a great product, iterate on new features and integrations, and support all major platforms including web browsers. Their choice to use a web based stack helps A LOT with this.
It really isn't. Even the multiplatform aspect of Electron is PITA - abstraction layers are so poor you usually have to support every platform separately by yourself if you want to reliably use stuff like systray icons or notifications.
Well, there's one exception - it sure is more productive if you already have a webapp to reuse.
Well, there's one exception - it sure is more productive if you already have a webapp to reuse.
> Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language
and when you want to fire all the obsolete specialists while making a product with one person that works for everyone. I mean, you can keep one specialist, since they know javascript too
and when you want to fire all the obsolete specialists while making a product with one person that works for everyone. I mean, you can keep one specialist, since they know javascript too
>Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language.
More like Electron is only the best way to do something when you're a business that's in dire need of developers and needs a cross-platform solution.
Seems like yet another complaint about Electron's filesize/memory usage? We already know it isn't great. I don't see what this post adds.
Comparing Electron to Flash in this way brings in the reader's mind other considerations than performance, primarily closed source and security vulnerabilities. It is a misrepresentation, perhaps unintentional. The article should be entitled: "Electron has performance issues".
(2016)
It's ActiveX for the desktop.
Old user here... I still don’t understand how Java failed at this. It was supposed to be the solution. You can, today, make cross platform, mostly native apps, with Java. But didn’t really become ubiquitous like we all thought.
Personally I got really burnt out by the number of times software written for Java wasn't compatible with a new release, causing me to dig up an old Java exe that I knew was insecure to be able to take my online class or what have you.
I think we have Apple to thank for that. JavaFX was compelling but alas all rich platforms were sufficiently moot when they killed Flash on mobile and locked iOS down.
You could have JavaFX apps on iOS - but you had to deal with the security model not allowing a JIT to run. The only JIT on iOS is the javascript engine (which runs out-of-process).
Wasn't Java problem a a branding issue? Java got a bad reputation of being slow and not looking native. Java apps looked like Java apps. Also, they were so slow that could actually tell when the garbage collector was working. by the time Java got fast it was too late. Even now, .Net guys that didn't bother getting to know Java after its first decade, usually say Java is slow. Something similar happens now with people who hasn't used JavaScript in 15 years saying it's not a real language, etc., etc.
One reason must be JVM startup performance. It simply takes long to load.
Combination of things really
* Non-native look and feel. Personally I think this is the big one.
* Applications/Applets took (take?) forever to boot. JIT takes a while to kick in.
* High memory usage due to heap+reference memory model and GC model.
* Latency spikes due to GC
* Installing a JRE is cumbersome for users
* Incompatible JRE versions are a pain for users
And electron has a native look and feel?
Most of the electron apps have a very customized look and feel, and default to a website-ish look and feel. Maybe not native but at least users are used to it, and it's not as alien as Swing.
And yet nearly all the things that people complained about with Java are at least as bad with Electron. I've grown to hate developers because of this faddish nonsense and their ridiculous and arrogant belief that their time is worth more than everyone else's.
This doesn't align with what I see in my Activitiy Monitor when I open it up and look at the Slack usage. I don't know a ton about this stuff, so maybe it's a relative thing, but my Mac has next to no problems with Slack like he's raging over in this post. The memory footprint is way smaller than his screenshots show. I also have 10 workspaces connected (not sure how that plays into it).
> I mean come on. Its a text chat program.
Seriously? To boil Slack down to just a chat program is silly, when you look at all the feature it has with it (screen sharing, calling, file sharing, etc.).
Electron hate is the new PHP hate. As I've seen many others say before on HN, what people don't seem to get is the experience of using Electron is miles ahead of anything else in convenience. Instead of writing a blog post ranting about Electron, why not be constructive and talk about solutions or alternatives? Wouldn't that be more productive?
EDIT: Didn't realize this post was from 2016. Seems way out of date, carry on, nothing to see here.
> I mean come on. Its a text chat program.
Seriously? To boil Slack down to just a chat program is silly, when you look at all the feature it has with it (screen sharing, calling, file sharing, etc.).
Electron hate is the new PHP hate. As I've seen many others say before on HN, what people don't seem to get is the experience of using Electron is miles ahead of anything else in convenience. Instead of writing a blog post ranting about Electron, why not be constructive and talk about solutions or alternatives? Wouldn't that be more productive?
EDIT: Didn't realize this post was from 2016. Seems way out of date, carry on, nothing to see here.
I wish people understood that (especially when it comes to FOSS, but even for proprietary software), convenience = more features. With Electron, shipping a Linux desktop app after writing the Windows/macOS one is almost no extra effort. Meanwhile, asking a developer with <1% Linux users to rewrite a Windows Forms app into GTK is not going to happen.
Making the experience worse for 99% of users just so that the other 1% can have an app on their desktop that works the same way in their browsers is a horrible idea.
Hey, I'd be fine with Slack being completely unavailable for Linux. I don't think any of the places where I have to use it currently would use it in that case.
2 workspaces 1.3g.
"Electron hate is the new PHP hate."
The new thing that people hate because it makes their work life bad? That is harsh criticism indeed.
The new thing that people hate because it makes their work life bad? That is harsh criticism indeed.
On Windows I see very similar results. Discord, doing nothing, idles at 165mb of memory usage and Signal (with even fewer features than Discord) manages to use 233mb while doing fuck all. Telegram, which has just as many features, idles at 78.5 (still a lot!!) and opens in literally 5ms instead of loading up for 30+ seconds.
>what people don't seem to get is the experience of using Electron is miles ahead of anything else in convenience.
That just blatantly isn't true. QML has the same "write markup run JS" idea and WPF is just XML bound to whatever .NET language you want. They might take a few minutes to learn if you already know web programming, but once you start writing code it doesn't take any longer than writing the equivalent HTML/JS/CSS. Like the OP said, React Native accomplishes the same but runs 1000x better. Getting people to step away from Electron for 5 seconds, especially when they have the resources to do so (i.e. Slack being able to raise $400 million this year, Discord raising $150 million, etc.) It's insane that none of these companies have spent the tiny amount of time working on some open-source framework that's better than Electron.
>what people don't seem to get is the experience of using Electron is miles ahead of anything else in convenience.
That just blatantly isn't true. QML has the same "write markup run JS" idea and WPF is just XML bound to whatever .NET language you want. They might take a few minutes to learn if you already know web programming, but once you start writing code it doesn't take any longer than writing the equivalent HTML/JS/CSS. Like the OP said, React Native accomplishes the same but runs 1000x better. Getting people to step away from Electron for 5 seconds, especially when they have the resources to do so (i.e. Slack being able to raise $400 million this year, Discord raising $150 million, etc.) It's insane that none of these companies have spent the tiny amount of time working on some open-source framework that's better than Electron.
> idles at 165mb of memory usage
I was starting to build an Electron app recently. My "hello world" app was using about 200mb, and so I was thinking things looked pretty good, and it wouldn't be too heavy if I was careful.
Then I noticed there were actually more system processes involved with the app that I realized, it was really using about 400mb.
Then I starting resizing the "hello world" app's window. I maximized it, minimized it, and shook my mouse furiously making the window all kinds of shapes and sizes. After this the app related threads were using about 1gig of memory. Just for a "hello world" app.
Now I'm always hesitant to accept claims that an Electron app isn't using much memory. Are you sure you're looking at all the related system threads?
I was starting to build an Electron app recently. My "hello world" app was using about 200mb, and so I was thinking things looked pretty good, and it wouldn't be too heavy if I was careful.
Then I noticed there were actually more system processes involved with the app that I realized, it was really using about 400mb.
Then I starting resizing the "hello world" app's window. I maximized it, minimized it, and shook my mouse furiously making the window all kinds of shapes and sizes. After this the app related threads were using about 1gig of memory. Just for a "hello world" app.
Now I'm always hesitant to accept claims that an Electron app isn't using much memory. Are you sure you're looking at all the related system threads?
> Seriously? To boil Slack down to just a chat program is silly, when you look at all the feature it has with it (screen sharing, calling, file sharing, etc.).
I—and I think a lot of other people—want a version of Slack that does not have these things, and is lighter thereby. Just an IRC-like interface for Slack where every file or image uploaded is just a URL that will open with your OS-configured web browser.
(Yes, I know there are a few attempts, but they're CLIs and I do still want a GUI Slack. There's no reason for me to be reading conversational prose as monospace text with no styling. There is a place between plaintext and full-on HTML, called "rich text", and every proprietary chat program in the 90s sat in it and used next-to-no resources. Where has "rich text" gone in 2019? Everything is seemingly either plaintext or full-blown HTML webviews.)
I—and I think a lot of other people—want a version of Slack that does not have these things, and is lighter thereby. Just an IRC-like interface for Slack where every file or image uploaded is just a URL that will open with your OS-configured web browser.
(Yes, I know there are a few attempts, but they're CLIs and I do still want a GUI Slack. There's no reason for me to be reading conversational prose as monospace text with no styling. There is a place between plaintext and full-on HTML, called "rich text", and every proprietary chat program in the 90s sat in it and used next-to-no resources. Where has "rich text" gone in 2019? Everything is seemingly either plaintext or full-blown HTML webviews.)
First off, the primary issues with Flash were that it was proprietary, had numerous security issues (due to its open source nature) and required custom, non-portable code.
Electron is a free software platform that builds on the open web standards. It uses the Chromium browser, which is available on every major platform (that permits browser installation, that is). And it works with "walled garden" stuff like iOS/Safari, because the modern web actually does a pretty decent job of coordinating standards.
If you use Linux desktop, you should be cheering loud and proud for Electron, because that's how Spotify, Discord, and many other apps have full feature parity between Linux and Windows and macOS.
Electron is a free software platform that builds on the open web standards. It uses the Chromium browser, which is available on every major platform (that permits browser installation, that is). And it works with "walled garden" stuff like iOS/Safari, because the modern web actually does a pretty decent job of coordinating standards.
If you use Linux desktop, you should be cheering loud and proud for Electron, because that's how Spotify, Discord, and many other apps have full feature parity between Linux and Windows and macOS.
Linux user not cheering here. I don't really get the point for desktop apps for things like discord... Why would I want another browser engine running when I can chat in discord in Firefox that is already running? Electron is like starting a tiny VM for every app. The only advantages I see here is for the app developer, who can be more intrusive (full access to run proprietary code on my laptop, send desktop notifications to make me an addict of their service, etc.)
I could definitely run a bunch of apps in my browser, but I prefer the desktop clients when possible. They show up in the dock (I'm sure I could do this with a browser app), they keep my browser clear for browsign, I can more easily Alt+Tab to them, and I don't have to worry about closing my browser and killing my chat client.
If there was something like an electron server with many client windows/apps, we could get all those nice features without launching many chrome instances...
So something like X-Windows, but with a VM.
I've also found (anecdotally) that the resource usage between a browser tab an the same electron app has been inconsequential.
What you describe looks like the "install PWA" (Progressive Web Apps) feature coming to Chrome. It is available already in Chrome 72 if you enable a flag (#enable-desktop-pwas) - then, when visiting a PWA site (try https://mobile.twitter.com) you have a menu option to install it like an app.
> The only advantages I see here is for the app developer, who can be more intrusive (full access to run proprietary code on my laptop, send desktop notifications to make me an addict of their service, etc.)
From most people's perspective, that "intrusiveness" is the reason they're using a desktop OS with desktop apps, rather than e.g. ChromeOS.
From most people's perspective, that "intrusiveness" is the reason they're using a desktop OS with desktop apps, rather than e.g. ChromeOS.
Linux user cheering on here - I personally prefer having the option of a dedicated app.
can you tells us why and elaborate on your preference of dedicated app vs webpage?
One specifically is just that Discord works well for me when used "natively", but doesn't work well (won't connect, worse latency, etc) when I used it from the webpage.
I have had the same problem with WhatsApp Web version vs. mobile. Web version had some issues. Mobile one works okay.
WebApp vs Mobile makes sense there would be differences. From the conversations here, Electron apps use the same code (???) as the web app would. Kind of an apples oranges thing
Not necessarily. Any X vs. Y there would be differences. I'm a techie, but was speaking from a user perspective, in which case one does not care about whether same code is used or not, only about UX.
Not OP, but I share their sentiment that sometimes I also "prefer having the option of a dedicated app". Reasons for me: isolation, access to system tray and other desktop APIs, existence as a separate window which allows for windowmanager-level activation/minimization (I use my own https://github.com/ronjouch/marathon for that), versioning / releases / archival through regular OS packages (e.g. with AUR in Arch Linux land).
Also, people love stuff that will look like an "app" in their macOS dock. I maintain https://github.com/jiahaog/nativefier , which will make regular websites into "native desktop applications" based, obviously, on Electron. Yup, we've come full circle :D
I'd offer a counterpoint to folks asking that question: if you love webpages so much, why don't you do write all your code in Cloud9 in your browser? See, sometimes, a separate window brings a different feel and lots of nuances that matter :) . Maybe you don't feel those nuances, so you prioritize other axes (like resource usage), but some people do.
Also, people love stuff that will look like an "app" in their macOS dock. I maintain https://github.com/jiahaog/nativefier , which will make regular websites into "native desktop applications" based, obviously, on Electron. Yup, we've come full circle :D
I'd offer a counterpoint to folks asking that question: if you love webpages so much, why don't you do write all your code in Cloud9 in your browser? See, sometimes, a separate window brings a different feel and lots of nuances that matter :) . Maybe you don't feel those nuances, so you prioritize other axes (like resource usage), but some people do.
What about users that are locked out of being able to install apps. Web apps are a great way around that. Although, the Electron apps being discussed seemed to be developer related, so the user probably has more control to be able to install apps.
The use case you just described is another reason to cheer for Electron. It allows the web page version of the app to be identical to the desktop version without any major effort on the developers part.
Indeed. Electron supports code-sharing because both the frontend and some of the server code, if it is in Node, can be shared easily between desktop and web. Nearly every cloud service with an Electron app has a web app, unless it does something like Etcher that is incompatible with the web sandbox. But yeah, I'm all for web apps.
Can a web app running in a web browser even do push-to-talk voice communication when the browser doesn't have focus, like Discord's Electron app can?
I like to bind meta-1 to meta-9 to switch to the nth app on my desktop bar. This means Discord (which is always meta-4) will always a keypress away for me, while Firefox (meta-1) requires me to find the right window and the right tab.
(Also, I routinely close browser windows I am not using by force of habit, which means I'd need to wait a load time every time I want discordapp.com.)
(Also, I routinely close browser windows I am not using by force of habit, which means I'd need to wait a load time every time I want discordapp.com.)
I have a similar habit with tabs in my browser. I line up the tabs in the same order so my keyboard shortcuts work in the same manner as how you are using them in the desktop bar. I could see where attempting to close the wrong browser window would get annoying. What OS are you running? Can you drag-n-drop your apps in the bar to reorder them, or do you have to open the apps in the correct order?
I'm using the app Snap on MacOS, and you can just reorder the Dock using drag and drop.
I'm not OP but I hate that everything occupies space (tabs) in my browser. I'd rather use a separate application.
Apps such as discord & slack run in the background for me all the time. If all of them were in the browser each one needed a single tab for itself.
It has other benefits such as switching between windows via alt+tab and co.
Apps such as discord & slack run in the background for me all the time. If all of them were in the browser each one needed a single tab for itself.
It has other benefits such as switching between windows via alt+tab and co.
Because I use my Chrome window for web browsing, and apps for their function. I want to alt tab to it. I want it to have access to my media keys and work nicely, I want it to be in my dock so I can click on it, I want it to sit in my system tray.
Some apps may legitimately benefit from having access to local native functionality that they can't access from a browser.
Like system-wide PTT to use Discord as an example.
balenaEtcher is a good example, it's written in Electron but obviously requires direct USB access that webUSB can't provide.
That's fine, most places that utilize Electron in this fashion have a web client as well. I personally would rather run a separate app and have a bit more integration with the desktop.
Touché
As a Linux user, I've stopped using the Slack desktop app; I just keep tabs open in my browser for Slack.
I agree that I'd rather have an Electron-based app on Linux than no ability to use an app at all, but that doesn't mean we shouldn't demand better (like React Native!). I run zero Electron-based apps on my laptop. They destroy battery life and slurp RAM to an unacceptable degree.
I agree that I'd rather have an Electron-based app on Linux than no ability to use an app at all, but that doesn't mean we shouldn't demand better (like React Native!). I run zero Electron-based apps on my laptop. They destroy battery life and slurp RAM to an unacceptable degree.
>First off, the primary issues with Flash were that it was proprietary, had numerous security issues (due to its open source nature)
How can the primary issue being it was proprietary, yet you then say its open source nature was the security issue? Is there a way for something to be both open source and proprietary at the same time?
How can the primary issue being it was proprietary, yet you then say its open source nature was the security issue? Is there a way for something to be both open source and proprietary at the same time?
I assume they meant "closed source", but it isn't as though the open/closed nature had anything to do with its security problems.
Yeah, I was think of Electron being open source and Flash being closed, just wrote it wrong.
Flash and its VM were proprietary, but SWF/FLA/FLV file formats and related specs were not.
"Flash burns through CPU and battery like crazy" is exactly why Apple wouldn't let it onto iOS.
Exactly. The CPU and memory overhead isn't wasted; it's a tradeoff of computational resources for development resources. Being able to tap into the latest developments of the (much more active) web community instead of being stuck with neglected native APIs, and being able to code for all platforms at once without issue, are valuable. Making developers' lives easier at the cost of performance may seem like laziness, but it opens doors for things like builds that target niche platforms.
That doesn't mean Electron and its use shouldn't be criticized, scrutinized, or optimized, but it's more than just "these young'uns being too lazy to learn a new language".
That doesn't mean Electron and its use shouldn't be criticized, scrutinized, or optimized, but it's more than just "these young'uns being too lazy to learn a new language".
The CPU and memory overhead isn't wasted; it's a tradeoff of computational resources for development resources.
So the users are using more electricity and creating more carbon emissions so the development team can do more with fewer people. In a way, it's a way for a company to outsource a part of its development expense to its users and the environment.
So the users are using more electricity and creating more carbon emissions so the development team can do more with fewer people. In a way, it's a way for a company to outsource a part of its development expense to its users and the environment.
My Slack instance is averaging 0.5% CPU usage at the moment. If you consider the 15 W TDP of this CPU we assume that Slack is using no more than .075 Watts of power. Probably much less, since there's no way a nearly-idle 15W TDP CPU is using 15W of energy.
How much extra energy does allocated RAM use vs. unallocated RAM? RAM has to be powered as long as your computer is on. I don't think there's any difference.
It's fine to be passionate about the environment but it's also important to be realistic and fact-driven. It really doesn't make sense to be telling people to make the most minuscule adjustments to carbon footprint instead of the easy low-hanging fruit (eating less red meat, buying fewer disposable products, being mindful of unneeded purchases, reusing and repairing possessions and purchasing them pre-owned).
Turning your screen brightness down, banning Electron, or running Lynx instead of Chrome isn't going to save the planet, even if all 7 billion people in the world did it.
How much extra energy does allocated RAM use vs. unallocated RAM? RAM has to be powered as long as your computer is on. I don't think there's any difference.
It's fine to be passionate about the environment but it's also important to be realistic and fact-driven. It really doesn't make sense to be telling people to make the most minuscule adjustments to carbon footprint instead of the easy low-hanging fruit (eating less red meat, buying fewer disposable products, being mindful of unneeded purchases, reusing and repairing possessions and purchasing them pre-owned).
Turning your screen brightness down, banning Electron, or running Lynx instead of Chrome isn't going to save the planet, even if all 7 billion people in the world did it.
If you consider the 15 W TDP of this CPU we assume that Slack is using no more than .075 Watts of power.
I'll accept that. You've conceded that it's a "tax" of about a tenth of a watt from the entire user base. It's not about saving the planet. It's about the fact that one kind of expense is being saved while another kind of expense is being shifted to the user base. Some people might well find it a worthwhile tradeoff. The market certainly has spoken on this matter.
How much extra energy does allocated RAM use vs. unallocated RAM?
That's the wrong question with regards to RAM. With regards to RAM, it's more about about a kind of opportunity cost. (Capacity cost?) It's not relevant to casual users who have a top of the line machine just to run their web browser and email. However, it is very relevant for someone with any kind of intensive use case. "Ounces add up to pounds, which add up to pain." It's just much more convenient for the user if their machine stays responsive even when you're doing something intensive.
Turning your screen brightness down, banning Electron, or running Lynx instead of Chrome isn't going to save the planet, even if all 7 billion people in the world did it.
It's not about saving the planet. It's about following the "money," even if the amounts are minuscule. That said, if the Electron community got together and put together some technology that reduced their collective footprint, that could only benefit them and their users.
I'll accept that. You've conceded that it's a "tax" of about a tenth of a watt from the entire user base. It's not about saving the planet. It's about the fact that one kind of expense is being saved while another kind of expense is being shifted to the user base. Some people might well find it a worthwhile tradeoff. The market certainly has spoken on this matter.
How much extra energy does allocated RAM use vs. unallocated RAM?
That's the wrong question with regards to RAM. With regards to RAM, it's more about about a kind of opportunity cost. (Capacity cost?) It's not relevant to casual users who have a top of the line machine just to run their web browser and email. However, it is very relevant for someone with any kind of intensive use case. "Ounces add up to pounds, which add up to pain." It's just much more convenient for the user if their machine stays responsive even when you're doing something intensive.
Turning your screen brightness down, banning Electron, or running Lynx instead of Chrome isn't going to save the planet, even if all 7 billion people in the world did it.
It's not about saving the planet. It's about following the "money," even if the amounts are minuscule. That said, if the Electron community got together and put together some technology that reduced their collective footprint, that could only benefit them and their users.
Literally every layer on top of raw machine code adds overhead. Whether that's the JVM, garbage collection, shared libraries that aren't specialized for your application, VMs running on a shared server, even operating systems themselves. All of these layers trade computational work for developer work. By doing so, they reduce code complexity and allow much more advanced software to be written and distributed to more platforms with less friction. Time that isn't spent debugging an application on the Nth platform can be spent improving features.
We can debate whether an individual one of these tradeoffs is a good one, but layering is a fundamental aspect of software engineering and it's hilariously misguided to suggest that it's an inherently bad thing to do.
We can debate whether an individual one of these tradeoffs is a good one, but layering is a fundamental aspect of software engineering and it's hilariously misguided to suggest that it's an inherently bad thing to do.
Who said it's a bad thing to do? I've literally been paid to advocate for VM managed languages starting in the late 90's.
No, the primary issue with flash was that people used it to make unmutable autoplaying music and unskippable splash screens that took 10x longer to load than the actual page.
Every technical complaint was trivial compared to that.
Every technical complaint was trivial compared to that.
Linux user here - Im glad electron exists, even if it is incredibly resource hungry and inefficient.
Rarely software is targeted for Linux, which means there are less mainstream apps than windows or OSX, which means less people using Linux.
I want more people to use Linux, electron has been great at helping build that userbase, so despite its flaws, I welcome it.
Rarely software is targeted for Linux, which means there are less mainstream apps than windows or OSX, which means less people using Linux.
I want more people to use Linux, electron has been great at helping build that userbase, so despite its flaws, I welcome it.
Can we label this as 2016
In addition, has Slack performance improved since this post was written?
In addition, has Slack performance improved since this post was written?
It got much worse.
Slack is a poorly-written Electron app, and unfortunately it's the poster child for it.
Discord does more with a fraction of the resources, and is also Electron. Atom is a giant editor framework, and is still less heavy than Slack in normal use.
Electron can run quite reasonably when you aren't an idiot/under complex enterprise requirements which probably explains Slack's load.
Discord does more with a fraction of the resources, and is also Electron. Atom is a giant editor framework, and is still less heavy than Slack in normal use.
Electron can run quite reasonably when you aren't an idiot/under complex enterprise requirements which probably explains Slack's load.
It makes me a little sad that JavaFX never really caught on. I thought that Swing was horrible for cross-platform development, but the little I've done with JavaFX is pretty pleasant, and seems to perform at least as well as Electron, if not better.
I recently tried to use Swing (for compat. and interop. reasons). While it was obviously "quirky" (partly just from it's age - some of those "quirks" were expected behavior at the time), it appeared to at least be functional. I have very simple GUI needs for this project, slapping a basic UI onto the project shouldn't be that hard, right?
Then I discovered the multiple layers of hell of Swing's various layout managers. I never thought I'd actually find something worse than packing GTK+ {h,v}boxes. I think I might end up retreating back to Tk...
Then I discovered the multiple layers of hell of Swing's various layout managers. I never thought I'd actually find something worse than packing GTK+ {h,v}boxes. I think I might end up retreating back to Tk...
Tcl/Tk interfaces look goofy, but they're very easy to build. You can even build them on a REPL. It's also very easy to understand what they do when you resize.
That's going back quite awhile. Why is it that later layout managers just seemed to get a bit worse then stay that way?
That's going back quite awhile. Why is it that later layout managers just seemed to get a bit worse then stay that way?
> might end up retreating back to Tk
You could cross over to the dark side and embrace the Microsoft Heresy. C#/.net
Upside: Just works Downside: Other programmers will hate you.
You could cross over to the dark side and embrace the Microsoft Heresy. C#/.net
Upside: Just works Downside: Other programmers will hate you.
How well does the .NET stuff work across platforms nowadays? Can I conceivably have a "write once, compile anywhere" mentality?
Conceivably if it is any good, you could get programmers to hate you a little more or less by using F#.
Conceivably if it is any good, you could get programmers to hate you a little more or less by using F#.
There is .net Core, but that doesn't currently have any GUI frameworks.
My rough impression is cross platform you have three options, web crappy, full native, and non-native. The last you may be native on one platform and look/act weird everywhere else.
That said I like stuff built on wxWidgets. There are bindings for other languages, never used them tho.
My rough impression is cross platform you have three options, web crappy, full native, and non-native. The last you may be native on one platform and look/act weird everywhere else.
That said I like stuff built on wxWidgets. There are bindings for other languages, never used them tho.
I have a visceral (possibly undeserved) hatred of C++, so WxWidgets and Qt are out; as it stands it looks like for what I need I'm stuck with Electron for my GUI stuff, since I don't want the JVM dependency.
There are wrappers for python, again never used either.
There is always Tk. It's a very friendly (no sudden unexpected behavior), easy to use toolkit.
https://tkdocs.com/tutorial/index.html
Tk works more or less everywhere and sometimes already installed: https://tkdocs.com/tutorial/install.html
and you don't need to use tcl: https://tkdocs.com/resources/languages.html
If you don't like Python, Ruby, Perl, or Tcl, other bindings are available: https://wiki.tcl-lang.org/page/Languages+with+a+Tk+binding https://en.wikipedia.org/wiki/Tk_%28software%29#Language_bin...
While the stock look-and-feel is functional-but-bland on all platforms, modern Tk is completely customizable and can approximate native widgets: https://tkdocs.com/tutorial/windows.html#dialogs
https://tkdocs.com/tutorial/index.html
Tk works more or less everywhere and sometimes already installed: https://tkdocs.com/tutorial/install.html
and you don't need to use tcl: https://tkdocs.com/resources/languages.html
If you don't like Python, Ruby, Perl, or Tcl, other bindings are available: https://wiki.tcl-lang.org/page/Languages+with+a+Tk+binding https://en.wikipedia.org/wiki/Tk_%28software%29#Language_bin...
While the stock look-and-feel is functional-but-bland on all platforms, modern Tk is completely customizable and can approximate native widgets: https://tkdocs.com/tutorial/windows.html#dialogs
One victim of Electron and the whole web-app economy is right-click context menus. Actions that would previously be doable by right clicking often require selecting, and going to a hamburger menu within electron apps or apps with a "modern" design.
Steve Jobs' insistence on one-button mice was an idea too brilliant for its time... /s
I get how Electron is useful. What I don't get is the why of it. Why should I have open another browser engine when I could just access it on my browser that I already have running.
Writable file access, ability to use ES6 and beyond without compatibility issues, media keys, etc.
But really I think that filesystem access is probably the main one, at least for me.
But really I think that filesystem access is probably the main one, at least for me.
Ah yes, but I was speaking more about apps that uses Electron to view their web page like Spotify or Discord
Shameless plug for my library [1] that makes PyQt a very viable alternative to Electron.
[1]: https://github.com/mherrmann/fbs
[1]: https://github.com/mherrmann/fbs
Flash isn't necessary today because HTML 5 is a shared platform that all modern browsers have in common. HTML and javascript as native as anything else in the browser and they're cross platform. This is critical. The criticisms about Electron's memory and CPU usage are legitimate, but it should not be understated how important it is to have a target for both web and desktops.
Maybe WebAssembly will get us there with decent performance.
Maybe WebAssembly will get us there with decent performance.
At some point in my country for some state fundings the only way to apply was via a windows app. The company I worked at the time, bought a pc just to apply. Sure they would have loved a crappy electron app instead.
Electron is not a problem is a symptom. People/companies want to write apps that run everywhere and that is actually a great thing. The problem is OS people not having their own little w3c to fix the problem.
Its starting to look pretty clear that sooner or latter all native apps will be coded in html css and some programing language (js or not) for the sake of being easy to port, so please OS people, get us a better solution than electron.
Electron is not a problem is a symptom. People/companies want to write apps that run everywhere and that is actually a great thing. The problem is OS people not having their own little w3c to fix the problem.
Its starting to look pretty clear that sooner or latter all native apps will be coded in html css and some programing language (js or not) for the sake of being easy to port, so please OS people, get us a better solution than electron.
Java runs everywhere and is at least an order of magnitude more efficient than Electron. If it was really about WORE then these developers would be using Java, a language and runtime actually designed for applications instead of being shoehorned into that role.
>> Java runs everywhere and is at least an order of magnitude more efficient than Electron.
I don't think people are choosing Electron for efficiency. They're choosing it for getting results sooner.
Electron lets you pump out a reasonably nice looking cross-platform app that does what it's supposed to do, using a lot of your existing code, in a short period of time.
That convenience to developers can easily outweigh the trade-offs related to Electron's many flaws, especially when time and resources are very limited.
I don't think people are choosing Electron for efficiency. They're choosing it for getting results sooner.
Electron lets you pump out a reasonably nice looking cross-platform app that does what it's supposed to do, using a lot of your existing code, in a short period of time.
That convenience to developers can easily outweigh the trade-offs related to Electron's many flaws, especially when time and resources are very limited.
Except, you know, for the users who's time and resources are the ones being wasted. But who cares about them, right?
Building GUIs in Java is a massive pain in the butt. Building GUIs with HTML and CSS is a breeze. That's a major difference.
Only if you've never built a GUI in anything other than a web stack (which is about the most awful environment for GUI I've ever had to deal with). Java GUIs can be done with WYSIWYG designers FFS.
I started out making GUIs in Java. It was definitely harder to make reasonable, good looking, UIs in it than it is in a web stack. There are WYSIWYGs for the web too. Doesn't mean they're good to use. I guess it all comes down to opinion. Clearly the Java model of GUIs maps better to your mind and the web model of GUIs maps better to mine.
Electron is the only decent solution for building a cross OS app in 2019. I challenge you to give me a stack that It's fairly simple to maintain on multiple desktop platforms, build UIs, has plugins to support most of the feature we're used today in a browser, etc. Don't forget that javascript now runs on the server, having a single language for everything is amazing.
The browser just became the best ecosystem for build apps and the native development frameworks are years behind the browser. The default set of Widgets available will make you waste months building your own widgets versus downloading a js plugin and it's done in 30 minutes.
Electron just gets things done, period.
There are examples of fast Electron apps like Realm Browser. You can also build the UI with Electron and Javascript while you do some IPC with smaller binaries written in C++, Go lang, C#, etc. to try to improve the performance of some operations. It is possible to write good and fast Electron apps.
Don't forget that many js developers came from jQuery and other backgrounds and might not have the best ideas when it comes to build desktop apps and even understanding an OS architecture. I don't mean to be mean with these developers, we need to acknowledge that these days lots of companies just want Javascript developers and any cost.
Another major benefit of Electron is that platforms like Linux do get some support which is really great.
Without electron, I could not use Linux to work on projects that use Slack for example.
Without electron, many developer tools wouldn't exist at all and most likely they would be tied to windows and/or mac. Linux would be the biggest looser for sure.
Don't think it's fair to shit on Electron, I love fast apps but, sometimes, buying more RAM and a faster CPU just solves the damn problem. I'm not saying people should write slow apps but at the end of the day I've stuff to get done.
I would rather see a better collaboration to try to improve Electron because... we need it. Either this or the native development tools need to wake up to 2019.
The browser just became the best ecosystem for build apps and the native development frameworks are years behind the browser. The default set of Widgets available will make you waste months building your own widgets versus downloading a js plugin and it's done in 30 minutes.
Electron just gets things done, period.
There are examples of fast Electron apps like Realm Browser. You can also build the UI with Electron and Javascript while you do some IPC with smaller binaries written in C++, Go lang, C#, etc. to try to improve the performance of some operations. It is possible to write good and fast Electron apps.
Don't forget that many js developers came from jQuery and other backgrounds and might not have the best ideas when it comes to build desktop apps and even understanding an OS architecture. I don't mean to be mean with these developers, we need to acknowledge that these days lots of companies just want Javascript developers and any cost.
Another major benefit of Electron is that platforms like Linux do get some support which is really great.
Without electron, I could not use Linux to work on projects that use Slack for example.
Without electron, many developer tools wouldn't exist at all and most likely they would be tied to windows and/or mac. Linux would be the biggest looser for sure.
Don't think it's fair to shit on Electron, I love fast apps but, sometimes, buying more RAM and a faster CPU just solves the damn problem. I'm not saying people should write slow apps but at the end of the day I've stuff to get done.
I would rather see a better collaboration to try to improve Electron because... we need it. Either this or the native development tools need to wake up to 2019.
> Electron is the only decent solution for building a cross OS app in 2019.
It's not decent.
> I challenge you to give me a stack that It's fairly simple to maintain on multiple desktop platforms
C++ core library, thin UI layer on each platform.
> The default set of Widgets available will make you waste months building your own widgets versus downloading a js plugin and it's done in 30 minutes.
Why would you build your own widgets? The ones the OS provided have had years put into them.
It's not decent.
> I challenge you to give me a stack that It's fairly simple to maintain on multiple desktop platforms
C++ core library, thin UI layer on each platform.
> The default set of Widgets available will make you waste months building your own widgets versus downloading a js plugin and it's done in 30 minutes.
Why would you build your own widgets? The ones the OS provided have had years put into them.
> C++ core library, thin UI layer on each platform.
The time required for coding in C++ is much more higher than javascript, just this point alone requires a bigger budget, time and a HR problem: hiring C++ developers vs javascript. You'll also spend more time configure each build for each platform, Electron has this automate for you already.
Web technologies are easier to learn: A designer can write CSS for your Electron desktop app but can not code the style in C++. It's just easier to add more people to the project. I'm aware than native tools do have IDE for designing UIs and easier markup languages like QML. Guess what, html and css are the true winners for the majority of developers/designers. The IDEs for native development are targets for developers, they don't account for designers. I've worked with several some years ago for windows, mac and linux.
> Why would you build your own widgets? The ones the OS provided have had years put into them.
The widget provided by the OS are basic. If you try to recreate a modern web interface you've to build each components by yourself. On the web you've plenty of option to quickly assemble a GUI. On Elementary OS, the OS style is done in CSS even though they use Vala/GTK+ to code the UI.
Also a cross platform GUI is a promise that is never delivered properly. With Electron apps can deliver a consistent UI: Slack looks the same regardless of the platform. With native, the UI looks good on one OS and like crap on others.
When Electron allows you to build a fairly complex app in 3 months, it's hard to sell native development due to the massive time you'll need. Just look at the React Native, it exists because it is a lot cheaper and faster than writing individual native iOS and Android apps.
The time required for coding in C++ is much more higher than javascript, just this point alone requires a bigger budget, time and a HR problem: hiring C++ developers vs javascript. You'll also spend more time configure each build for each platform, Electron has this automate for you already.
Web technologies are easier to learn: A designer can write CSS for your Electron desktop app but can not code the style in C++. It's just easier to add more people to the project. I'm aware than native tools do have IDE for designing UIs and easier markup languages like QML. Guess what, html and css are the true winners for the majority of developers/designers. The IDEs for native development are targets for developers, they don't account for designers. I've worked with several some years ago for windows, mac and linux.
> Why would you build your own widgets? The ones the OS provided have had years put into them.
The widget provided by the OS are basic. If you try to recreate a modern web interface you've to build each components by yourself. On the web you've plenty of option to quickly assemble a GUI. On Elementary OS, the OS style is done in CSS even though they use Vala/GTK+ to code the UI.
Also a cross platform GUI is a promise that is never delivered properly. With Electron apps can deliver a consistent UI: Slack looks the same regardless of the platform. With native, the UI looks good on one OS and like crap on others.
When Electron allows you to build a fairly complex app in 3 months, it's hard to sell native development due to the massive time you'll need. Just look at the React Native, it exists because it is a lot cheaper and faster than writing individual native iOS and Android apps.
> The time required for coding in C++ is much more higher than javascript
I'm not convinced that this is true.
> The widget provided by the OS are basic.
Not really. I am yet to see an Electron widget that does drag-and-drop, accessibility, theming, keyboard control, etc. right. OS widgets are by no means "basic".
> Also a cross platform GUI is a promise that is never delivered properly. With Electron apps can deliver a consistent UI: Slack looks the same regardless of the platform. With native, the UI looks good on one OS
That's the whole point: I don't want my apps to look dumbed down to the lowest common denominator. Each native app looks good and fits in on its platform.
> Just look at the React Native, it exists because it is a lot cheaper and faster than writing individual native iOS and Android apps.
React Native is much nicer than Electron in this respect, because it doesn't package then entire Chromium engine and uses native controls to a limited extent.
I'm not convinced that this is true.
> The widget provided by the OS are basic.
Not really. I am yet to see an Electron widget that does drag-and-drop, accessibility, theming, keyboard control, etc. right. OS widgets are by no means "basic".
> Also a cross platform GUI is a promise that is never delivered properly. With Electron apps can deliver a consistent UI: Slack looks the same regardless of the platform. With native, the UI looks good on one OS
That's the whole point: I don't want my apps to look dumbed down to the lowest common denominator. Each native app looks good and fits in on its platform.
> Just look at the React Native, it exists because it is a lot cheaper and faster than writing individual native iOS and Android apps.
React Native is much nicer than Electron in this respect, because it doesn't package then entire Chromium engine and uses native controls to a limited extent.
[deleted]
Tab in browser provides way better user experience than electron app (or native android/ios app). With website you can to mind-blowing things like:
* Open other part of your app in new tab.
* Open other part of your app in new widow, and have time side by side.
* Open external link in new tab, in the same window (OMG!!!).
* I can send link from the web app to someone else.
* Consistent back button.
* Use browser extensions.
* Have cookies (i.e. I am logged out of most of the things in your in-app browser).
Composers are generally thing that are better in apps, but as long as I don't need to compose complex stuff, web app always wins. And if I do, I'll prefer to use native/electron app only for composing, not for consumption.
* Open other part of your app in new tab.
* Open other part of your app in new widow, and have time side by side.
* Open external link in new tab, in the same window (OMG!!!).
* I can send link from the web app to someone else.
* Consistent back button.
* Use browser extensions.
* Have cookies (i.e. I am logged out of most of the things in your in-app browser).
Composers are generally thing that are better in apps, but as long as I don't need to compose complex stuff, web app always wins. And if I do, I'll prefer to use native/electron app only for composing, not for consumption.
> Open other part of your app in new tab.
Unless the developers forbid it... and always finding new ways to forbid it...
Man I hate the new web.
Man I hate the new web.
This is more of an old web, and because of bad design: keeping state of the app on server, rather than in the browser (or are you referring to limiting open in new tab?).
But yes, I hate the new web too (sometimes).
But yes, I hate the new web too (sometimes).
I was thinking of web apps like MS Teams that just simply do not allow to open a new tab on click for whatever reason. I can open the app in two windows just fine, but I can't right/middle click on something to tell it to open in new tab. Why would I not want be able to open a Word Online document in a new tab directly?
There are other apps, that are even worse. Allowing something to open in a new tab/window but identifying that there are multiple windows open and just disabling all but the main window...
I don't understand developers that do this. I always felt that multiple tabs is a strength of the web. They worsen it somehow.
There are other apps, that are even worse. Allowing something to open in a new tab/window but identifying that there are multiple windows open and just disabling all but the main window...
I don't understand developers that do this. I always felt that multiple tabs is a strength of the web. They worsen it somehow.
Revery UI[1] framework is like Electron but without a browser.
[1] https://github.com/revery-ui/revery
[1] https://github.com/revery-ui/revery
Its built on top of electron, so when you download slack you're actually downloading a complete copy of Google Chrome. Chrome, at the time of writing is 15 million non-comment lines. When you download slack, 99% of the code is 'below the water'.
And chrome is a hog. Its huge and complicated. It uses ram and CPU like nobody's business, and it totally thrashes your battery life.
I remember when Chrome was the shiny, nimbler, new kid on the block.
And chrome is a hog. Its huge and complicated. It uses ram and CPU like nobody's business, and it totally thrashes your battery life.
I remember when Chrome was the shiny, nimbler, new kid on the block.
Reminds me of a nerd friends comment about why Eclipse exists, because in the late 90's some people thought Emac's was a bloated pig.
Actually, Eclipse was a port of the "Visual Age" family of IDEs which started out implemented in Smalltalk. Smalltalk started out as something like Lisp, without the insanity of coding in your data representation. (Unfortunately, it means you don't have the insanely great benefits of coding in your data representation.)
Emacs was actually a great way to do work over a slow modem connection back in the late 90's.
Emacs was actually a great way to do work over a slow modem connection back in the late 90's.
Like Flash was replaced with web technologies, Electron soon will be replaced by Progressive Web Apps. Just have to wait a bit longer for browsers to securely implement missing functionality, like access to file system. Although for most apps that doesn't need any advanced APIs we can use PWAs today.
For people who don't like Electron, but still need it's features, I recommend Revery.
https://www.outrunlabs.com/revery
It's build with Reason/OCaml and builds native self-contained binaries (~3MB for simple apps).
https://www.outrunlabs.com/revery
It's build with Reason/OCaml and builds native self-contained binaries (~3MB for simple apps).
I hate Electron too, but the bi-monthly hour of Electron hate on here is a little tiresome. It's clear that it solves some major issues from a development standpoint for a lot of organizations, and it's here to stay. Slack isn't going to rewrite their app (hell they can't even implement dark mode). It's just another thing we have to get used to.
why can't all Electron apps use same chrome base like a lib?
Silly post. Visual Studio Code also uses Electron, and has yet to spin up fans on my machine. I use it every day, all day, on a variety of platforms. There seems to always be someone who thinks there clever complaining about bloat and then pointing to C or now trendy Go and/or Rust. It rarely is. Perhaps Slack was doing some sort of internal auto-update when the CPU started thrashing. Of course figuring that would kill a good blog rant about bloat. I sure hope the author doesn't run Windows.
[deleted]