Essential Electron

http://jlord.us/essential-electron/

by kawera • 10 years ago

184 114 10 years ago

jlord.us

bananaoomarang• 10 years ago

There has to be a more efficient way of writing cross-platform code than bundling Chrome and NodeJS with your app.

mherrmann• 10 years ago

There is: I chose (Py)Qt for my desktop app https://fman.io for precisely this reason.

mintplant• 10 years ago

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

wyqydsyq4• 10 years ago

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.

flukus3• 10 years ago

If JS + HTML + CSS is all they know then I really don't want their software running on my machine.

kozak2• 10 years ago

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).

squeaky-clean• 10 years ago

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!

creshal9• 10 years ago

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.

yoz-y2• 10 years ago

Qt does look like crap on OSX unless you reskin all of the widgets like QtCreator does.

open-source-ux• 10 years ago

"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.

bbcbasic• 10 years ago

Does freepascal come with UI components? If not the same can be said about C C++ Haskell etc.

derefr4• 10 years ago

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.)

scriptproof• 10 years ago

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.

lawnchair_larry3• 10 years ago

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.

Klathmon3• 10 years ago

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.

FooBarWidget• 10 years ago

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.

rmason2• 10 years ago

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.

wyqydsyq4• 10 years ago

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.

rmason2• 10 years ago

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.

creshal9• 10 years ago

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.

WorldMaker• 10 years ago

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.)

dsincl12• 10 years ago

The font size is way too big on that page.

reitoei• 10 years ago

If only there was some way to make it smaller.

Ezhik• 10 years ago

Well, I do need to put my 16GB of RAM to good use.

creshal9• 10 years ago

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.

Narishma• 10 years ago

A password manager shouldn't even need a tenth of that.

GoToRO• 10 years ago

Do you also get a website? given that you program using JS + HTML + CSS.

deejbee• 10 years ago

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()

rv112• 10 years ago

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).

rtpg• 10 years ago

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.

rv112• 10 years ago

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...

creshal9• 10 years ago

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.

kozak2• 10 years ago

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.

elmigranto• 10 years ago

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.

mhd2• 10 years ago

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.

oblio3• 10 years ago

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.

derefr4• 10 years ago

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.

biokoda• 10 years ago

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.

mhd2• 10 years ago

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.

flukus3• 10 years ago

I remember bringing this up every time someone complained that java didn't look native.

ORioN63• 10 years ago

I still care. That's why I'm so in love with the terminal.

One interface to rule them all.

WayneBro• 10 years ago

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.

Touche2• 10 years ago

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.

nilved• 10 years ago

Yes, that nightmare.

kitsunesoba• 10 years ago

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).

okket• 10 years ago

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.

creshal9• 10 years ago

A decade ago Mozilla's XUL-based HTML+JS interfaces, and the programs built in it – Firefox and Thunderbird – were all the rage.

NeutronBoy• 10 years ago

And the concept of 'web apps' barely existed.

marcosscriven2• 10 years ago

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.

maccard4• 10 years ago

The slack desktop app is another one, and it's not good.

marcosscriven2• 10 years ago

What do you find is bad about it?

D_Guidi• 10 years ago

Postman app (http://blog.getpostman.com/2016/08/02/introducing-postman-fo...) was released few days ago, too

jakobegger3• 10 years ago

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.

tjalex• 10 years ago

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.

Furincer• 10 years ago

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.

strictnein• 10 years ago

Yeah, I really liked this format as well. Simple language and easy to read. Wish there were more articles out there like this.

toomanybeersies• 10 years ago

What's the key differences between Electron and Chromium Embedded Framework?

tretiy32• 10 years ago

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".

k__• 10 years ago

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.

y0ghur7_xxx• 10 years ago

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...

131hn• 10 years ago

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 ...

therockhead2• 10 years ago

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.

nkozyra2• 10 years ago

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.

therockhead2• 10 years ago

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.

Hurtak• 10 years ago

Does anybody have experience with both Electron and nwjs? How do they compare?

diggan• 10 years ago

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...

cjbprime4• 10 years ago

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.

sktrdie• 10 years ago

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.

Touche2• 10 years ago

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.

CGamesPlay• 10 years ago

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%.

0x006A• 10 years ago

Whats the security update plan for Electron?

cjbprime4• 10 years ago

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.

pdkl954• 10 years ago

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.

gldalmaso• 10 years ago

I don't see it being discussed much when Electron comes up, so I'll share some of the use cases that led our company to move at least one of our web apps to Electron.

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

srikz• 10 years ago

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.

jblow• 10 years ago

"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...

Essential Electron

Related Stories