13 ms·
Essential Electron
- bananaoomarang 10y agoThere has to be a more efficient way of writing cross-platform code than bundling Chrome and NodeJS with your app.
- mherrmann 10y agoThere is: I chose (Py)Qt for my desktop app https://fman.io https://fman.io for precisely this reason.
- mintplant 10y agoNote 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
- wyqydsyq 10y agoThere'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.
- flukus 10y agoIf JS + HTML + CSS is all they know then I really don't want their software running on my machine.
- creshal 10y agoFor 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.)
- flukus 10y agoMy 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).
- creshal 10y ago> 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.
- krisdol 10y agoThe 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.
- wyqydsyq 10y agoI 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.
- kozak 10y agoActually, 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 10y 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!
- creshal 10y agoLet 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-y 10y agoQt does look like crap on OSX unless you reskin all of the widgets like QtCreator does.
- creshal 10y agoAFAIK Qt is still the least crap-looking cross-platform toolkit. GTK et al. are all even worse.
- Longhanks 10y agoEven Qt Creator sticks out. OS X/macOS users (disclaimer: like me) are really, really nit-picking when it comes to minor UI inconsistencies.
- yoz-y 10y agoYes 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.
- infinite8s 10y agoQt > 5.5 looks good on OS X, although some interactions are slightly off.
- open-source-ux 10y 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 10y agoDoes freepascal come with UI components? If not the same can be said about C C++ Haskell etc.
- derefr 10y agoWhat 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 10y agoIt seems to exist like a runtime (https://www.npmjs.com/package/electron https://www.npmjs.com/package/electron), but I have not tried it for now and I can't judge the usability in production.
- derefr 10y agoAn 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.
- lawnchair_larry 10y agoBecause the node.js cult have lost their minds, only knowing how to bring the kitchen sink with everything they do, and only knowing javascript.
- Klathmon 10y agoIs 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".
- rmason 10y agoElectron 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.
- wyqydsyq 10y agoI 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.
- rmason 10y agoInteresting 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.
- wyqydsyq 10y agoIf 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.
- creshal 10y agoElectron'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.
- dsincl12 10y agoThe font size is way too big on that page.
- reitoei 10y agoIf only there was some way to make it smaller.
- Ezhik 10y agoWell, I do need to put my 16GB of RAM to good use.
- creshal 10y agoIt'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 10y agoA password manager shouldn't even need a tenth of that.
- GoToRO 10y agoDo you also get a website? given that you program using JS + HTML + CSS.
- deejbee 10y agoYou 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()
- rv11 10y agoWell, 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 10y agoAgreed. 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.
- rv11 10y agoYes 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_Framework https://developer.valvesoftware.com/wiki/Chromium_Embedded_F...
- creshal 10y agoNot 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.
- kozak 10y agoWindows 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 10y agoIf 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.
- mhd 10y agoRemember 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.
- oblio 10y agoMeh. 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.
- derefr 10y agoHCI 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.
- oblio 10y agoTrue. I was just pointing out the disconnect between the market and the experts on this one :)
- biokoda 10y 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.
- mhd 10y agoI 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.
- okket 10y agoA 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.
- creshal 10y agoA decade ago Mozilla's XUL-based HTML+JS interfaces, and the programs built in it – Firefox and Thunderbird – were all the rage.
- NeutronBoy 10y agoAnd the concept of 'web apps' barely existed.
- marcosscriven 10y agoI'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.
- maccard 10y agoThe slack desktop app is another one, and it's not good.
- marcosscriven 10y agoWhat do you find is bad about it?
- methyl 10y agoIt'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.
- Furincer 10y agoThank 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 10y agoYeah, I really liked this format as well. Simple language and easy to read. Wish there were more articles out there like this.
- toomanybeersies 10y agoWhat's the key differences between Electron and Chromium Embedded Framework?
- tretiy3 10y agoIt 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__ 10y agoI 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 10y agoElectron 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/S2-/http-client ²https://github.com/electron/electron/blob/master/docs/api/auto-updater.md https://github.com/electron/electron/blob/master/docs/api/au...
- 131hn 10y agoI 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 ...
- therockhead 10y agoI 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.
- nkozyra 10y agoWhat 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.
- therockhead 10y ago1) 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.
- nkozyra 10y agoI 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 10y ago[deleted]
- Hurtak 10y agoDoes anybody have experience with both Electron and nwjs? How do they compare?
- diggan 10y agoLong 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-edition http://tangiblejs.com/posts/nw-js-and-electron-compared-2016...
- cjbprime 10y agoElectron 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 10y agoWhat 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.
- Touche 10y agoMaybe 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 10y agoI'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 10y agoWhats the security update plan for Electron?
- cjbprime 10y agoThere'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.
- pdkl95 10y agoThat 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.
- cjbprime 10y agoI'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?
- pdkl95 10y agoConsider 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.
- gldalmaso 10y agoI 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 10y agoVery 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 10y 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...