Electron is flash for the desktop (2016)
josephg.com
josephg.com
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.
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.
From most people's perspective, that "intrusiveness" is the reason they're using a desktop OS with desktop apps, rather than e.g. ChromeOS.
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, 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.)
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.
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?
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".
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.
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.
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.
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.
Every technical complaint was trivial compared to that.
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.
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.
You "can" write a proprietary app with Qt and you wouldn't have to pay for it.
But if you dynamically link your app with Qt you're fine; you don't have to open source anything.
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 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)
With most software developers and most managers not moonlighting as lawyers, misunderstandings are to be expected.
They may have solved this since by using a custom allocator on windows for Qt types.
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.
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...
What are you trying to show here?
That just shows how little you know. One style in one configuration looks like that.
Doing web apps without CSS skills won't look much better.
huh!? When did this happen?
Spoiler Alert: It didn't.
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 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.
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.
Because it's absolutely true. You'll know it once you watch a web dev try and work on desktop app.
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?
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.
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.
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 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.
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!
What toolkit or library would you propose instead? Seriously, what are these great alternatives? Doesn't necessarily have to support JS.
* 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
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?)
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 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.
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.
This is why I hate this industry.
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.
Well, there's one exception - it sure is more productive if you already have a webapp to reuse.
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
> 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.
The new thing that people hate because it makes their work life bad? That is harsh criticism indeed.
>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.
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—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.)
* 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
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.
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...
That's going back quite awhile. Why is it that later layout managers just seemed to get a bit worse then stay that way?
You could cross over to the dark side and embrace the Microsoft Heresy. C#/.net
Upside: Just works Downside: Other programmers will hate you.
Conceivably if it is any good, you could get programmers to hate you a little more or less by using F#.
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.
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
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.
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.
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.
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.
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.
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.
For most desktop apps the central "core" is tiny but the UI layer is very thick.
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.
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.
Emacs was actually a great way to do work over a slow modem connection back in the late 90's.
Maybe WebAssembly will get us there with decent performance.
* 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.
Man I hate the new web.
But yes, I hate the new web too (sometimes).
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.
In addition, has Slack performance improved since this post was written?
But really I think that filesystem access is probably the main one, at least for me.
https://www.outrunlabs.com/revery
It's build with Reason/OCaml and builds native self-contained binaries (~3MB for simple apps).