Essential Electron(jlord.us)
jlord.us
Essential Electron
http://jlord.us/essential-electron/
115 comments
Remember when people used to complain about minor desktop UI inconsistencies like submenu activation, button frames and default icons? Thanks to years getting people accustomed to the usability nightmare that is the web, this doesn't seem to be an issue anymore.
Meh.
After all, the dominant OS before mobile was Windows. Remember Winamp skins? Skins for every possible app on the face of the Earth? Opening up Skype, which had its own theming, Yahoo Messenger, which had its own theming, Office 2003, which had its own theming, etc., etc., etc.
Except for Mac OS fans, most of the world didn't really care.
After all, the dominant OS before mobile was Windows. Remember Winamp skins? Skins for every possible app on the face of the Earth? Opening up Skype, which had its own theming, Yahoo Messenger, which had its own theming, Office 2003, which had its own theming, etc., etc., etc.
Except for Mac OS fans, most of the world didn't really care.
I remember quite a lot of complaints about those Office changes, or different styles that came from using Borland C++, Delphi or even cross-platform tools. If you were doing commercial development, that mattered. End users don't exactly complain about specifics, they just ditched your program because it was "odd".
Let's not even mention Unix.
But yeah, Mac OS users were particularly obnoxious there, as usual.
Let's not even mention Unix.
But yeah, Mac OS users were particularly obnoxious there, as usual.
> End users don't exactly complain about specifics, they just ditched your program because it was "odd".
Except that they don't. If that were true then we would see a lot more consistency in desktop app styles.
The typical desktop computer experience hasn't been visually consistent since the mid 90's. Most young people have never used a computer where most of the apps had the same style.
Except that they don't. If that were true then we would see a lot more consistency in desktop app styles.
The typical desktop computer experience hasn't been visually consistent since the mid 90's. Most young people have never used a computer where most of the apps had the same style.
HCI people complained about those when they were happening, too. The default controls of Windows 95 (and later, Windows 2000) were held up as great usability; the apps that ignored them, not so much.
True. I was just pointing out the disconnect between the market and the experts on this one :)
> Except for Mac OS fans, most of the world didn't really care.
Just because it was used does not mean people didn't care. They had no say or choice in the matter.
Just because it was used does not mean people didn't care. They had no say or choice in the matter.
I still care. That's why I'm so in love with the terminal.
One interface to rule them all.
One interface to rule them all.
> One interface to rule them all.
What does that even mean?
GUIs have quite obviously commanded a vast lead in popularity over terminals ever since they were invented. So, they don't "rule" in that sense.
Do you mean to say that you somehow "rule over the GUI using peoples of the world" because you use a terminal and maybe you write code or do sysadmin work that all the GUI users have to report to? I doubt that's actually the case because your boss is probably a GUI user who tells you what to do.
I don't think the terminal is ruling anything. I think some people are just fond of trite sayings that seem to enhance their own stature.
What does that even mean?
GUIs have quite obviously commanded a vast lead in popularity over terminals ever since they were invented. So, they don't "rule" in that sense.
Do you mean to say that you somehow "rule over the GUI using peoples of the world" because you use a terminal and maybe you write code or do sysadmin work that all the GUI users have to report to? I doubt that's actually the case because your boss is probably a GUI user who tells you what to do.
I don't think the terminal is ruling anything. I think some people are just fond of trite sayings that seem to enhance their own stature.
I think it's just a playful reference to Lord of the Rings.
> Thanks to years getting people accustomed to the usability nightmare that is the web
You mean the nightmare that is typing an address into a input (or just searching on Google) and being able to near-instantly use an app, even really bad applications that we all complain about?
That nightmare? I'll take it over per-platform applications that have different UI paradigms and that I must install/support manually myself.
You mean the nightmare that is typing an address into a input (or just searching on Google) and being able to near-instantly use an app, even really bad applications that we all complain about?
That nightmare? I'll take it over per-platform applications that have different UI paradigms and that I must install/support manually myself.
Usability and accessibility are separate, though related. Yes, websites are easy to get to and start using, but that won't help a badly designed web app be less bad or mitigate the impact of weird, non standard conventions and interactions. A well designed desktop app will be more pleasant to use than a badly designed web app despite the added overhead of installation.
And of course, things can be done to cut the friction of installation down to a minimum, e.g. using fully self contained binaries, distributing zipped executables instead of installers, and including robust self update capabilities (on platforms without package management).
And of course, things can be done to cut the friction of installation down to a minimum, e.g. using fully self contained binaries, distributing zipped executables instead of installers, and including robust self update capabilities (on platforms without package management).
Yes, that nightmare.
What would be interesting to reduce the memory footprint is to split Chromium and only include stuff you actually need in your app. For instance, Chromium comes with backwards-compatibility code for websites of the 90s (that use tables and old CSS). Perhaps there can be a stripped down version that only supports HTML5. Even cooler would be to simply just include in the final package only the things you're using. So if I don't need localStorage, I don't include it in my app.
I've investigated this lightly. The bulk of the weight of electron is actually in the media stuff. Dropping video support would reduce the storage footprint by around 50%.
Maybe that's something a newer engine like Servo can just build in. Allow everything to be configurable in the build. Don't need float: left? Just use --no-floats.
There has to be a more efficient way of writing cross-platform code than bundling Chrome and NodeJS with your app.
"There has to be a more efficient way of writing cross-platform code"
Yes, it's called Freepascal using the Lazarus IDE. Native, cross-platform self-contained binaries that run fast and don't using oodles of memory or require massively-sized binaries.
Why is it not more widely used? Because of that word Pascal. That's enough to dismiss it in the minds of many developers. Modern Pascal has many of the features we associate with modern languages e.g OOP and generics. But Pascal's syntax, age and verbosity mean many developers will never give it a second look.
Yes, it's called Freepascal using the Lazarus IDE. Native, cross-platform self-contained binaries that run fast and don't using oodles of memory or require massively-sized binaries.
Why is it not more widely used? Because of that word Pascal. That's enough to dismiss it in the minds of many developers. Modern Pascal has many of the features we associate with modern languages e.g OOP and generics. But Pascal's syntax, age and verbosity mean many developers will never give it a second look.
Does freepascal come with UI components? If not the same can be said about C C++ Haskell etc.
What I'm really confused about is why Electron is set up such that each app ships the whole runtime, rather than there being something like the JRE or CLR (or Silverlight, or Adobe Air, or...) where each app that wants to use it, prompts for its installation.
Better yet, why not make the architecture into a single shared "Electron windowing server" process that all Electron apps run "on", such that I don't end up running 7 different copies of Chrome?
(Honestly, Chrome itself could have become said runtime with its packaged apps, plus the (only ever experimental) standalone App Launcher install mode. I guess that's not the path they wanted to go down.)
Better yet, why not make the architecture into a single shared "Electron windowing server" process that all Electron apps run "on", such that I don't end up running 7 different copies of Chrome?
(Honestly, Chrome itself could have become said runtime with its packaged apps, plus the (only ever experimental) standalone App Launcher install mode. I guess that's not the path they wanted to go down.)
That approach is not without downsides. It requires strong compatibility guarantees and version management. That's not easy to achieve.
And traditionally, management of such shared runtimes on anything but Linux sucks a lot. Remember all those Windows apps that tell you "Java Runtime Environment 1.5 required" and then they kind of leave you to figure out how to install that? Not exactly user-friendly.
And at the end of the day, regardless of your OS, you end up with 4-5 different JRE versions installed because compatibility is not perfect, so each app locks down to a specific version instead of accepting a newer JRE.
.NET isn't any better. I have 5-6 different .NET runtime versions installed and I can't remove any of them because each app requires a different version.
The method of vendoring all your dependencies may not be the most efficient, but it's certainly the most convenient one. It seems users these days care more about how much hassle it is to install than how long the download takes or how much RAM it uses.
And traditionally, management of such shared runtimes on anything but Linux sucks a lot. Remember all those Windows apps that tell you "Java Runtime Environment 1.5 required" and then they kind of leave you to figure out how to install that? Not exactly user-friendly.
And at the end of the day, regardless of your OS, you end up with 4-5 different JRE versions installed because compatibility is not perfect, so each app locks down to a specific version instead of accepting a newer JRE.
.NET isn't any better. I have 5-6 different .NET runtime versions installed and I can't remove any of them because each app requires a different version.
The method of vendoring all your dependencies may not be the most efficient, but it's certainly the most convenient one. It seems users these days care more about how much hassle it is to install than how long the download takes or how much RAM it uses.
> That approach is not without downsides. It requires strong compatibility guarantees and version management.
Static linking the runtime also has significant downsides. One of the worst is how it puts the burden of pushing runtime security updates on the app. Frequent JRE downloads because of security patches is annoying, but downloading N copies of chrome every for all of your apps is insane.
Of course, this also requires that each app update itself to be compatible with the new versions every time there is a security patch. The entire point of including a specific version of chrome is to avoid these updates, so the very idea of Electron implies the app is not designed for security.
Static linking the runtime also has significant downsides. One of the worst is how it puts the burden of pushing runtime security updates on the app. Frequent JRE downloads because of security patches is annoying, but downloading N copies of chrome every for all of your apps is insane.
Of course, this also requires that each app update itself to be compatible with the new versions every time there is a security patch. The entire point of including a specific version of chrome is to avoid these updates, so the very idea of Electron implies the app is not designed for security.
Because an electron JRE will run into the same versioning issues that the JRE has.
Not to mention the additional headache of having to install dependencies which can be an annoyance on some platforms.
At this point in 2016 the number of people that are negatively affected by an electron app's size on disk is significantly less than would be negatively affected by having to muck with installing "Electron Runtime version 52" for app A but need to lock it to "Electron Runtime version 50" for app B.
Not to mention the additional headache of having to install dependencies which can be an annoyance on some platforms.
At this point in 2016 the number of people that are negatively affected by an electron app's size on disk is significantly less than would be negatively affected by having to muck with installing "Electron Runtime version 52" for app A but need to lock it to "Electron Runtime version 50" for app B.
Is there really anything in your average Electron app that breaks when Electron is upgraded? I assumed that Electron apps would inherit implicit forward-compatibility from web-apps, allowing "Electron" to just always mean "the latest Electron" in the same way that "Chrome" means "the latest Chrome."
Also, I'm not so much concerned with size-on-disk as I am with
1. redundant versioning leading to redundant network bandwidth costs (e.g. I don't want to find out that I have 20 different apps that want to download a 100MB update—99MB of which is the same Electron binary—every time Electron itself updates.)
2. memory usage (30 versions of the Electron runtime means 30 copies of Electron taking physical memory. 30 apps using the same Electron runtime means 30 copies of Electron in virtual memory sharing the same physical pages.)
Also, I'm not so much concerned with size-on-disk as I am with
1. redundant versioning leading to redundant network bandwidth costs (e.g. I don't want to find out that I have 20 different apps that want to download a 100MB update—99MB of which is the same Electron binary—every time Electron itself updates.)
2. memory usage (30 versions of the Electron runtime means 30 copies of Electron taking physical memory. 30 apps using the same Electron runtime means 30 copies of Electron in virtual memory sharing the same physical pages.)
Sadly that's not the case. Many electron apps are written with a single version in mind and that version needs to be treated like any other dependency. Knowing you are targeting a single platform lets devs aggressively optimized that platform.
Also, some electron apps will modify the "browser" part.
As for download sizes, aside from the first download all updates can use Delta update packages and I believe this is built in.
Re memory usage, with sandboxing the way it is today I'm not convinced you would save all that much memory unless you were running over 10 different electron apps, and even then compared to the total memory usage I feel it would be insignificant enough to not warrant the "JRE architecture". I don't really have anything to back this up, its just a hunch.
Also, some electron apps will modify the "browser" part.
As for download sizes, aside from the first download all updates can use Delta update packages and I believe this is built in.
Re memory usage, with sandboxing the way it is today I'm not convinced you would save all that much memory unless you were running over 10 different electron apps, and even then compared to the total memory usage I feel it would be insignificant enough to not warrant the "JRE architecture". I don't really have anything to back this up, its just a hunch.
It seems to exist like a runtime (https://www.npmjs.com/package/electron), but I have not tried it for now and I can't judge the usability in production.
An NPM package does not a runtime make. By "runtime", I'm referring to something that exists, at least, as an .msi on Windows and a .pkg on macOS, such that Electron can generate a "launcher wrapper" binary that will download and execute those in silent-install mode, then unpack and execute your app using the now-installed runtime.
Because the node.js cult have lost their minds, only knowing how to bring the kitchen sink with everything they do, and only knowing javascript.
Is this really necessary? It's a language/runtime, not a sports team.
You throwing everyone that uses node.js into a big bin labeled "only knows javascript cult" is childish at best.
There are obviously trade offs going with a "globally installed runtime" vs "including the runtime with each application". JRE takes the former, electron the latter. Each with their own set of problems, each providing different solutions, each with their own reasons, applications, and "target audience".
You throwing everyone that uses node.js into a big bin labeled "only knows javascript cult" is childish at best.
There are obviously trade offs going with a "globally installed runtime" vs "including the runtime with each application". JRE takes the former, electron the latter. Each with their own set of problems, each providing different solutions, each with their own reasons, applications, and "target audience".
There's plenty of cross-platform UI kits for a wide range of languages.
The thing that's big about Electron is it allows web developers to use their existing skills to create desktop apps.
A lot of web developers would like to make desktop apps, but aren't willing to learn a new systems language to do that, especially when there's a solution that lets them use the JS + HTML + CSS they already know.
The thing that's big about Electron is it allows web developers to use their existing skills to create desktop apps.
A lot of web developers would like to make desktop apps, but aren't willing to learn a new systems language to do that, especially when there's a solution that lets them use the JS + HTML + CSS they already know.
> The thing that's big about Electron is it allows web developers to use their existing skills to create desktop apps.
Also it lets you reuse parts of your web app (or build part of your web app while building your desktop app). For something like Slack, or if Google were to make a desktop version of Docs, it makes a lot of sense to use Electron because you already have your web app and you want your desktop app to be consistent with it.
I've used Ionic with a very small team to make a web app and mobile app from the same codebase. The client asked if we could also make a desktop version for them, and instead of taking months to build one and make it consistent with the web/mobile apps, it was just a few days of learning to wrap it up with Electron. That was really neat!
Also it lets you reuse parts of your web app (or build part of your web app while building your desktop app). For something like Slack, or if Google were to make a desktop version of Docs, it makes a lot of sense to use Electron because you already have your web app and you want your desktop app to be consistent with it.
I've used Ionic with a very small team to make a web app and mobile app from the same codebase. The client asked if we could also make a desktop version for them, and instead of taking months to build one and make it consistent with the web/mobile apps, it was just a few days of learning to wrap it up with Electron. That was really neat!
Actually, not that plenty, if you consider only those that have good DPI scaling support and are cross-platform (at least between Windows and Mac).
If JS + HTML + CSS is all they know then I really don't want their software running on my machine.
For me, JS+HTML+CSS isn't (I had to outsource most of the UI code to our webdevs), but Qt or GTK (or, god forbid, Cocoa and whatever is Microsoft's newest fetish) are so much less productive that I just cannot justify writing in it any more. If you want a smooth UX with things like animated scene transitions (people scoff at animations, but if used sparingly and at the right places, they improve usability), or just any non-standard widgets, it's far, far easier to do everything in HTML.
And the beauty of Electron is that you can still write all your actual logic in C/C++ and use Node's FFI to bind it to your UI.
(Qt is transitioning to the same model with its HTML+JS based Qt Quick orchestrated from native code; but it's far less production ready than Electron right now.)
And the beauty of Electron is that you can still write all your actual logic in C/C++ and use Node's FFI to bind it to your UI.
(Qt is transitioning to the same model with its HTML+JS based Qt Quick orchestrated from native code; but it's far less production ready than Electron right now.)
My comment wasn't so much about the quality of the tools (I'm currently learning react native), but the type of developer that only knows js.
A developer that only knows js is unlikely to be competent (beginners aside).
A developer that only knows js is unlikely to be competent (beginners aside).
The type of developer that only knows one language of any kind is in the same boat. Electron is popular because folks can write products at a faster pace than they could in other toolkits and languages. Being unproductive and fighting your tooling is not a sign of competency, nor is it a rite of passage. If folks can write apps faster in Java or Rust (which I love writing, by the way), I'm sure Electron would not have the adoption curve it does. Nothing to do with only knowing one language.
> A developer that only knows js is unlikely to be competent (beginners aside).
Oh, don't get me started…
Yes, that's a problem. But Electron can hardly be blamed for it. They'd use XULRunner if it didn't.
Oh, don't get me started…
Yes, that's a problem. But Electron can hardly be blamed for it. They'd use XULRunner if it didn't.
I also know Python, Go and Rust, but I only use them for tinkering and experiments. I'd still use JS+CSS+HTML via Electron for a GUI app over traditional systems languages any day of the week.
Let me know it if you find one. Of all the cross-platform UI toolkits, only Qt is both stable and doesn't look like crap (sorry, WxWidgets)… and with Qt Quick it's also bundling Chrome, just binding it to C++ instead of NodeJS.
It's really hard to beat HTML in terms of flexibility.
It's really hard to beat HTML in terms of flexibility.
Qt does look like crap on OSX unless you reskin all of the widgets like QtCreator does.
AFAIK Qt is still the least crap-looking cross-platform toolkit. GTK et al. are all even worse.
Even Qt Creator sticks out. OS X/macOS users (disclaimer: like me) are really, really nit-picking when it comes to minor UI inconsistencies.
Yes it does (I use it on OSX every day). But maybe it is because it has grown on me, but I find it less distracting that other Qt applications that try to look like OSX.
Qt > 5.5 looks good on OS X, although some interactions are slightly off.
There is: I chose (Py)Qt for my desktop app https://fman.io for precisely this reason.
Note that unlike Qt itself, PyQt is only freely available under the GPL. Riverbank Computing also sells a commercial license.
https://www.riverbankcomputing.com/commercial/license-faq
https://www.riverbankcomputing.com/commercial/license-faq
I've been very impressed with the few Electron apps I've seen out in the wild. Obviously the main one is Atom (as I believe this is what gave rise to Electron). But others include Kitematic and VS Code, the latter of which convinced me such an approach could produce a smooth UI.
Generally, I find the way these apps look very attractive, much more so than any other cross-platform apps I've seen before (Swing, AWT, QT etc).
While I agree the download size is less than ideal, I can't argue against it being a good compromise at the moment.
Generally, I find the way these apps look very attractive, much more so than any other cross-platform apps I've seen before (Swing, AWT, QT etc).
While I agree the download size is less than ideal, I can't argue against it being a good compromise at the moment.
Atom is a pretty neat editor as long as you are only using it on small files.
Try opening a 20MB SQL Dump. Fortunately, Atom will show a warning. If you click past that, everything will freeze while Atom eats up more than a Gigabyte of memory. Don't turn on syntax highlighting, or Atom will lock up and eat all your CPU.
When you are done listening to your computer's fan, quit Atom. Then kill the "Atom Helper" process, which for some reason keeps on eating CPU even after you quit Atom.
Now open the same file in BBEdit, or any other native Text Editor... and the file will open instantly, the app will be responsive, and syntax highlighting will work, because 20MB really isn't a file size that should be an issue for a text editor.
Try opening a 20MB SQL Dump. Fortunately, Atom will show a warning. If you click past that, everything will freeze while Atom eats up more than a Gigabyte of memory. Don't turn on syntax highlighting, or Atom will lock up and eat all your CPU.
When you are done listening to your computer's fan, quit Atom. Then kill the "Atom Helper" process, which for some reason keeps on eating CPU even after you quit Atom.
Now open the same file in BBEdit, or any other native Text Editor... and the file will open instantly, the app will be responsive, and syntax highlighting will work, because 20MB really isn't a file size that should be an issue for a text editor.
I've tested opening a few ~15MB log files (no syntax highlighting) with VS Code and Atom... I'm amazed that one editor will load within 2-3s and the other will take 15s (or more!) when they are both built on Electron.
Postman app (http://blog.getpostman.com/2016/08/02/introducing-postman-fo...) was released few days ago, too
The slack desktop app is another one, and it's not good.
What do you find is bad about it?
It's VERY memory heavy. When I open 4 channels it could eat as much as 4GB, comparing to 300MB per card when it's open in Chrome. That's why I started writing Chrome App which will simulate native Slack client and be much more memory efficient.
> writing Chrome app
Note that Google will stop supporting Chrome Apps in 1 year or so.
http://blog.chromium.org/2016/08/from-chrome-apps-to-web.htm...
Note that Google will stop supporting Chrome Apps in 1 year or so.
http://blog.chromium.org/2016/08/from-chrome-apps-to-web.htm...
This is too bad :(
Writing a chrome app to save you from chrome's bloat seems like a dead end. Just write a native client, or at least java/c#.
It's not chrome's bloat, it's Slack that's for some reason broken. I don't have such problems with VSCode for example. Also it's reusing already opened Chrome instance which should make memory usage more optimized.
Slack might be making it worse, but come on. Chrome is huge. Check out the memory and cpu usage of VS Code, and compare that to any other text editor. An instance of chrome just for text editing blows my mind.
As another commenter mentioned, it's extremely memory hungry. Right now, it's got 6 processes running, and it's chewing through a little over a gig of ram. I frequently (roughly once a week or so?) check process explorer and find slack hung and sitting on 3+GB.
Performance is sluggish on both the high end machines I use regularly (Dual xeon workstation, and an i7 6700k with 32GB/16GB ram respectively). The search functionality brings the UI to a halt, and scrolling through the message history isn't remotely close to smooth. Startup times are also quite long. I closed the app, and re-ran it. it was 5 seconds before the window appeared, and another 5 before my chat window was populated.
Performance is sluggish on both the high end machines I use regularly (Dual xeon workstation, and an i7 6700k with 32GB/16GB ram respectively). The search functionality brings the UI to a halt, and scrolling through the message history isn't remotely close to smooth. Startup times are also quite long. I closed the app, and re-ran it. it was 5 seconds before the window appeared, and another 5 before my chat window was populated.
Slack is pretty good for a web app. You can tell they really worked hard to make it feel native.
But there are just some fundamental differences between desktop apps and web apps.
Just like a website, the Slack desktop app is slow. Open Apple Messages, and you'll see all your messages instantly. Open Slack, and you'll be greeted by a loading screen, followed by a loading screen with an insightful quip. Click on a different channel, and you'll see another loading screen, followed by another loading screen with a different funny message.
And then there are all these inonsistencies... Holding down the mouse on a popup menu doesn't work; you need to click to open, then click again to select. Resizing the sidebar is not possible.
But there are just some fundamental differences between desktop apps and web apps.
Just like a website, the Slack desktop app is slow. Open Apple Messages, and you'll see all your messages instantly. Open Slack, and you'll be greeted by a loading screen, followed by a loading screen with an insightful quip. Click on a different channel, and you'll see another loading screen, followed by another loading screen with a different funny message.
And then there are all these inonsistencies... Holding down the mouse on a popup menu doesn't work; you need to click to open, then click again to select. Resizing the sidebar is not possible.
I can't find a source for this right now, I've been searching, but I remember reading something about the Messages app (I can't remember if it was iOS or MacOs/OSX) is actually a webview app! Would love it if someone could find a source proving/disproving it.
This made me curious, and I checked by attaching a debugger to Messages.
The content view with the bubbles is a web view. All the other views (sidebar, input field, etc.) are native controls.
I guess this is a sort of "best of both worlds" approach. You have all the flexibility of HTML & CSS for complex content layout, and you get performance and usability of native sidebars and text fields.
The content view with the bubbles is a web view. All the other views (sidebar, input field, etc.) are native controls.
I guess this is a sort of "best of both worlds" approach. You have all the flexibility of HTML & CSS for complex content layout, and you get performance and usability of native sidebars and text fields.
Interesting to know, thanks for checking!
All those Electron apps are extremely slow on my mac (Intel Core 2 Duo mid 2010, 4Gb RAM). I am using Slack web version (in Chrome also) and can't find any difference, except it is just a tab among others.
Atom and Spotify are pretty fast for me on OS X, but slack is both CPU and memory heavy. It idles at between 10 and 30% CPU usage, which is unacceptable.
Electron is potentially a game changing product but very little thought has been given to a smooth on boarding process.
I have had very little problems with the actual coding part, but installing, especially on Windows, and updating for new versions is voodoo. Every time I think I have it all figured out it breaks.
I have had very little problems with the actual coding part, but installing, especially on Windows, and updating for new versions is voodoo. Every time I think I have it all figured out it breaks.
I can't speak for Windows but on both OSX and Linux, upgrading Electron versions is as simple as upgrading the version number of the `electron-prebuilt` dependency of your project and running `npm update`. You can also use the `npm-check-updates` package to upgrade to the latest version automatically.
Electron's build process on Windows is somewhere between byzantine and arcane, especially when native dependencies are involved. You do exactly the same steps three times, twice it works, the third time you will have to gouge your eyes out and draw blood pentagrams onto your hard disk.
To make things even gentler `electron-prebuilt` is now called just `electron` (yay!).
That said, the problem right now is still if you ever need any node native dependencies because electron because building those seems to be complicated on every platform. Right now my quest is to avoid native dependencies that aren't in the prebuilt electron.
It's interesting because Cordova is a tiny bit better at handling native plugins. Unicorn dream is that I'd really love so see some sort of convergence in Cordova and Electron plugin approaches, especially when it comes to native dependencies. (For various reasons several major projects I'm working on need to target both Cordova and Electron; it would be nice if it were a more seamless experience.)
That said, the problem right now is still if you ever need any node native dependencies because electron because building those seems to be complicated on every platform. Right now my quest is to avoid native dependencies that aren't in the prebuilt electron.
It's interesting because Cordova is a tiny bit better at handling native plugins. Unicorn dream is that I'd really love so see some sort of convergence in Cordova and Electron plugin approaches, especially when it comes to native dependencies. (For various reasons several major projects I'm working on need to target both Cordova and Electron; it would be nice if it were a more seamless experience.)
Interesting that you mention npm-check because that was recommended to me. The web page explaining it looked fabulous and I thought it would solve all my problems.
But running it took six hours and it crashed. Found online somewhere that it can't handle the size of electron, too many nested directories I guess.
Tried just updating and it appears to have worked, but now everything crashes and the error message isn't very helpful.
But running it took six hours and it crashed. Found online somewhere that it can't handle the size of electron, too many nested directories I guess.
Tried just updating and it appears to have worked, but now everything crashes and the error message isn't very helpful.
If you just jumped up some major versions it's likely that you've upgraded to a version with breaking API changes. I'd suggest reading the changelogs between your old and new versions.
Assuming you're using the prebuilt version (which you should be unless you're hacking on Electron itself) there shouldn't be any issues upgrading - it just downloads the latest prebuilt binary, there really aren't many files.
Assuming you're using the prebuilt version (which you should be unless you're hacking on Electron itself) there shouldn't be any issues upgrading - it just downloads the latest prebuilt binary, there really aren't many files.
I know a few people who did Qt wrappers for their websites and sold them as native apps, because some big enterprises only installed old IE versions.
Installing a new browser wasn't allowed, but installing these wrappers that prevented the use of any other website and most other browser features, was okay.
With Electron this is even easier.
Also the "Web-Platform" can now do most of the things others can do too.
90% of all things people want to do with apps (mobile or desktop) is already possible with a web-app. If you need more, you can do a browser extension or an Electron app.
Installing a new browser wasn't allowed, but installing these wrappers that prevented the use of any other website and most other browser features, was okay.
With Electron this is even easier.
Also the "Web-Platform" can now do most of the things others can do too.
90% of all things people want to do with apps (mobile or desktop) is already possible with a web-app. If you need more, you can do a browser extension or an Electron app.
Thank you for having a readable font size and thank you for actually explaining ideas in ways that the layperson can learn from. We need more of this, not elitist jargon that is all too common.
Yeah, I really liked this format as well. Simple language and easy to read. Wish there were more articles out there like this.
Well, I do need to put my 16GB of RAM to good use.
It's not that bad, depending on what you're doing inside of it. My password manager clocks in at ~150 MiB RAM usage with a few thousand passwords. Could be better, but it's not as bad as, say, Mozilla products written in XUL.
A password manager shouldn't even need a tenth of that.
A decade ago you would have been shot for suggesting to run every (web-)app in this own 50MB+ browser environment/jail.
Times are a-changing and memory is cheap these days.
Times are a-changing and memory is cheap these days.
A decade ago Mozilla's XUL-based HTML+JS interfaces, and the programs built in it – Firefox and Thunderbird – were all the rage.
And the concept of 'web apps' barely existed.
I can understand why small teams with a web background might pick Electron instead of going native but I don't understand why the larger companies like Slack don't write a native app when they have the resources to hire the talent.
What advantage would that introduce? Slack seems to work just fine on each available OS. Being able to write once in JavaScript/CSS/HTML seems a lot more appealing than writing and testing three apps separately, regardless of your company size.
1) Native L&F
2) More responsive UI
3) Lower memory footprint
As a dev I'm biased of course and this might not matter to most people. One thing though, you don't have to write the full app three times. For example all the business logic can be in C++ and write a native UI on top of it.
As a dev I'm biased of course and this might not matter to most people. One thing though, you don't have to write the full app three times. For example all the business logic can be in C++ and write a native UI on top of it.
I think it might matter to non-devs but the tradeoff has to be pretty compelling and in Slack's case I don't see it. Like, there's still dev work happening to make these apps, so it's not like you're shutting out a whole group just because it's a web stack and not C++.
[deleted]
"Typically, desktop applications for each operating system are written in each's native language. That can mean having three teams writing three versions of your app. Electron enables you to write your app once and with web languages."
I stopped reading there. If you have total ignorance of how native applications work, maybe fill that hole before trying to evangelize that everything should be written in JS...
I stopped reading there. If you have total ignorance of how native applications work, maybe fill that hole before trying to evangelize that everything should be written in JS...
Well, you are getting cross platform almost for free. It is a pain with other such frameworks.
Spotify, steam , brackets use these kind of tech, and I personally like them. somehow I find them fast, more stable( probably due to chromes multiprocess architecture).
Spotify, steam , brackets use these kind of tech, and I personally like them. somehow I find them fast, more stable( probably due to chromes multiprocess architecture).
Agreed. Main issue is everyone's downloading Electron over and over to run the apps. Would be nice to have an EVM or something so that Slack could just be the ~1 meg or so of actual app-dependent code.
Windows 10 (actually, 8+, but never mind) has its own platform for "native" HTML apps. One more abstraction layer, and your app can run both there and in Electron.
Yes desirable, but I find most of these apps, modify the chrome code for their own needs. you can find their modified code , differs vastly from what electron/CEF offers. and example would be
https://developer.valvesoftware.com/wiki/Chromium_Embedded_F...
https://developer.valvesoftware.com/wiki/Chromium_Embedded_F...
Not sure how well it'd work out in the wild, even if an app doesn't modify electron, Electron's native plugin ABI is rather aggressively versioned and you'd break them between every upgrade.
Maybe eventually the web hipsters discover what stable releases are and give us an electron branch that doesn't break everything every week, then it'd be more feasible.
Maybe eventually the web hipsters discover what stable releases are and give us an electron branch that doesn't break everything every week, then it'd be more feasible.
If I remember correctly, Steam uses Chromium to render web pages and nothing else. And it does a shitty job of it, at least in supporting HiDPI screens.
Very nice introduction with relevant links. However, I feel the 'Think of it like this' section is strictly for MacOS (and Linux?) users as it doesn't behave that way in Windows and can confuse the reader.
What's the key differences between Electron and Chromium Embedded Framework?
It is nodejs vs c++.
Also, everything works out of the box in Electron case. In CEF, instead you have to study examples and dive into Win32 API/GTK/cocoa samples to find out how to run and extend basic "hello world".
Does anybody have experience with both Electron and nwjs? How do they compare?
Electron seems to have more mindshare, nwjs has some nice features like the ability to open multiple windows from the same renderer thread. In Electron, each window you open has its own renderer thread with no JS state shared between windows.
Long time ago, I used nw.js (back then, node-webkit) but too long ago to remember. However, there is bunch of posts about the subject, here is one of them: http://tangiblejs.com/posts/nw-js-and-electron-compared-2016...
Electron is really awesome. I wrote a rest client¹ a few weeks ago for my personal use, and it worked out really well. I saw that even the auto update² use case is taken care of.
Really awesome to make a quick app for someone who is already good in making webapps and needs the power/access/network rights of a desktop app.
¹https://github.com/S2-/http-client
²https://github.com/electron/electron/blob/master/docs/api/au...
Really awesome to make a quick app for someone who is already good in making webapps and needs the power/access/network rights of a desktop app.
¹https://github.com/S2-/http-client
²https://github.com/electron/electron/blob/master/docs/api/au...
I like electron very much, yet, how come i'm feeling to be the only one to like & miss the nw.js mixed context mode ? This is so much more confortable ...
Do you also get a website? given that you program using JS + HTML + CSS.
You can spin up a http server from the Main process (we do spin up websockets on our app) if you need to, and if you're writing a single page app using angular for example then you can just specify the .html page using loadURL()
Whats the security update plan for Electron?
There's an Electron auto-updater module, and an example update server implementation, so you just push updates (of any kind, including security updates that fix Electron itself) to your users (supports Windows and macOS) using that.
That only works if the apps are compatible with future releases of Chrome. If that was acceptable, there would be no reason to bundle a specific version of the runtime with each app. As several people in this thread have already pointed out, apps break between versions; this implies that the "security update plan" in practice will be to ignore security updates.
I'm so confused.
The app author controls the update channel. At their own pace, they'll bump up their Electron dependency to a newer version and make sure their app is still compatible with the latest Electron. When they're ready to release that new combination of app and Electron, they can push out the new version to everyone as an auto-update.
Where does Chrome come into it? Who will be ignoring security updates?
The app author controls the update channel. At their own pace, they'll bump up their Electron dependency to a newer version and make sure their app is still compatible with the latest Electron. When they're ready to release that new combination of app and Electron, they can push out the new version to everyone as an auto-update.
Where does Chrome come into it? Who will be ignoring security updates?
Consider the next time there is a serious vulnerability in Chrome. Maybe it's a TLS problem and network requests cannot be authenticated. Maybe it's a buffer overflow in something that renders data from a remote source. Chrome needs to be updated to a newer version immediately.
Is every app author going to push out an update that includes the latest Chrome with the relevant security fixes? Or are they going to irresponsibly leave the vulnerability unpatched until their app is updated to support the new version of Chrome?
The very idea of using old versions of Chrome (via Electron) - which is the stated reason for bundling Chrome with each app - tautologically means at least some apps will be using vulnerable versions of Chrome.
> At their own pace
That's the point; browser bugs don't happen at the app author's pace.
Is every app author going to push out an update that includes the latest Chrome with the relevant security fixes? Or are they going to irresponsibly leave the vulnerability unpatched until their app is updated to support the new version of Chrome?
The very idea of using old versions of Chrome (via Electron) - which is the stated reason for bundling Chrome with each app - tautologically means at least some apps will be using vulnerable versions of Chrome.
> At their own pace
That's the point; browser bugs don't happen at the app author's pace.
Jeez, I guess. In practice the Electron authors would presumably issue point releases for critical security vulnerabilities. If so, this is no different from shipping OpenSSL with your app and needing to get an update out for that.
We provide a B2B service that relies on communication with a locally installed service running on the users machine. This kind of approach is one that has been heavily bombarded with new features and deprecations leaning towards a more secure web by most browser vendors, which is actually very justifiable.
The most recent one was Chrome targeting to restrict app cache usage, which we rely on currently, only to documents served through HTTPS. Given that we have an app that uses a local service that needs to work offline, we cannot use HTTPS for that without messing with stuff that needs Administrator privileges, which we really want to avoid because headaches.
So we figured we need a more flexible approach that is not so restricted as a web app living on the browser, but we already have a product. Here comes Electron, and in a couple weeks work, mostly testing things, we have it. We now deploy both to the web (just in case) and are rolling customers to the desktop.
Other features that added a lot of value where:
- No localStorage limit, was starting to become an issue, now we have breathing room to migrate to other storage
- Auto Update, actually took care a long time complaint for the necessity to keep downloading new versions of the local running server, which we now package alongside the app
- node process running directly on the client opens up a lot of new possibilities