15 ms·

Electron 7.0

227 points by ausjke 7y ago

headcanon 7y ago
Every time Electron is mentioned I bust out the popcorn for the inevitable hate spewed towards it: "Javascript is a terrible language and no one should use it" "Separate instances of chrome for every app is dumb and consumes too much memory" "Qt is amazing and elegant and desktop-native. Why isn't everyone just using Qt?"
- YesSureThing 7y ago
  I would use Uno.platform . C++ is also a terrible language.
- Hendrikto 7y ago
  > "Separate instances of chrome for every app is dumb and consumes too much memory" That one is true though. Different Electron apps could at least share the runtime.
  - judge2020 7y ago
    I imagine the different electron versions and different Chrome versions would make this hard without breaking things. Maybe a config option for "allow chromium between versions x and y" would solve this.
    - Hendrikto 7y ago
      Shouldn‘t Chrome be backwards compatible? I would hope so at least.
      - judge2020 7y ago
        Most electron projects I've seen have used webpack targeting ES2017 or earlier anyways which makes this unlikely, but if you compile for ESnext (or don't compile at all) and use a new V8 feature, you wouldn't want Chrome 69 running your app and getting stuck on old V8 not being able to use the new feature.
      - pawelk 7y ago
        Maybe it should, but it's not always the case. As a front end dev I have to fix issues related to bugs introduced by browser uptades every now and then and usually it's Chrome. On the web it's easy, deploy a fix and it's live. With a desktop app I can't even imagine the logistics involved.
  - mikepurvis 7y ago
    Is that really possible? I feel like it would only work with considerable engineering effort, and even then, probably only if the bundled Chrome instances were all exactly the same version.
    - michaelmrose 7y ago
      This is literally how every gui library on planet earth works. Developers all build against a particular recent released version with all apps in the system expected to build against a small number of recent versions. If this is hard maybe its because the browser isn't a very good runtime to build against.
      - mikepurvis 7y ago
        Right, but those systems are set up from the get-go with that usage pattern in mind, where you have an expectation of ABI compatibility and the underlying libraries as a shared resource. The expectation with Electron has always been that you bundle a copy of it with your app, so that you're always targeting exactly that version.
  - paulryanrogers 7y ago
    Except they cannot, Chromium (or is it Blink?) changes too frequently to reliably code for one version and expect backward compatibility of future releases. Electron versions could be shared libraries... except again BC breaking releases proliferate.
    - shaki-dora 7y ago
      Websites manage to target different versions, and browsers, and even device classes just fine.
    - hanniabu 7y ago
      Why can't it be based of Chrome's version number? If you know the version number at the time of release then you can say only use the same runtime if there's only a revision version difference, else you can use it's own run time. That packaged with auto-updates for the app to that developers can push updated builds every month or so should be fine.
    - diffeomorphism 7y ago
      Except they chose not to, preferring to allow for frequent breaking changes. This makes it easier for devs to make these rapid changes with all the cost/overhead payed by you.
  - kodablah 7y ago
    With their multi-process approach, you'd have separate processes even when sharing the runtime to the point that sharing the DLLs likely has minimal benefit. It's the equivalent of running firing up Chrome twice w/ two different user profile dirs...shared libs, but no obvious perf advantage over two separate Chrome installs.
  - pmarreck 7y ago
    1) Log into Slack in Chrome 2) Log into Discord in Chrome 3) Log into <insert application here> in Chrome Problem solved?
    - bhhaskin 7y ago
      Swap Firefox for Chrome and you are golden.
- rafaelvasco 7y ago
  Only second one is a really valid point;
- mikepurvis 7y ago
  The people complaining are not the customers, they're the product. Electron isn't sold to the users running Slack and Spotify and Atom, it's sold to the developers of those things with the promise of a low-friction path for existing web devs to deploy a native-ish application on multiple platforms.
- rosybox 7y ago
  The problem with Qt I have is how incredibly expensive it is. Sure it's free if you want to build something open source, but you know some of us have to also make money to pay for being alive and it's hard to bootstrap an application if you have to pay $5,508 up front, per developer, and then again on an annual basis.
  - pritambaral 7y ago
    You can use Qt with closed source software, under the LGPL license that you don't have to pay for. Only the binaries that have Qt code need to be open. Don't statically link Qt libs into your closed-source code and you're good.
    - sroussey 7y ago
      And put that in an app store?
      - hellofunk 7y ago
        Yes, even on iOS.
        kej 7y ago
        The LGPL requires end users to be able to view and modify the LGPL portion of the derivative work. Does iOS give end users that level of access to apps? (honest question, my outsider's impression of Apple is that they have stuff locked down more than that)
        jcelerier 7y ago
        the problem with iOS was that you had to pay 99$ a year to upload apps to your own phone, which prevent use of GPL code since it removes your right to do stuff on your own hardware. Fortunately this restriction was lifted since Xcode 7 a few years ago and it's nowadays not a problem at all - there are plenty of GPL / LGPL apps on the app store. Just put the code and build instructions on github, what matters is that users can patch, rebuild and upload the patched version to their phone.
- draw_down 7y ago
  I know, it’s amazing! Nice to see someone else here gets a kick out of it. Electron absolutely makes HNers lose their minds.
Razengan 7y ago
Since this is inevitably going to generate some discussion over native apps vs. Electron (ah there's already a fellow comment about it), I'd like to point out an example that is important to me of why Electron is an inferior experience for users: In the GitHub Desktop client, which is an Electron app, I can't spell check my commit messages, something that every text field in every native macOS app gets for free.
- _bxg1 7y ago
  Web text fields should also support that functionality, so it may be a question of GitHub breaking/disabling it in some way.
  - judge2020 7y ago
    Kind of odd, is doesn't look like there's a built-in spell checker available in Chromium since you need a spell check provider[0]. I imagine Google injects it into their Chrome when deploying. 0: https://github.com/electron/electron/blob/master/docs/api/web-frame.md#webframesetspellcheckproviderlanguage-provider https://github.com/electron/electron/blob/master/docs/api/we...
    - _bxg1 7y ago
      That is interesting; I assumed it hooked into the OS-level functionality but it doesn't appear to. Hmm.
  - bitwize 7y ago
    It's probably a question of the 2010s equivalent of Windows custom control masturbation ("look mom, I can create my own buttons!"): replacing perfectly good HTML elements with ground-up reimplementations written in DIV soup with JavaScript event handlers.
  - Razengan 7y ago
    You're right; I just tested it in Discord, which does have a spell checker, and it seems to use the system dictionary (but it seems one way when teaching it new words), but it's still missing other global text field functionality: https://i.imgur.com/qpOU9dz.png https://i.imgur.com/qpOU9dz.png The point remains: Electron apps generally lose many of the features that the host OS gives native apps for free.
scrollaway 7y ago
I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit. For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as a user. But Electron has brought true cross-platform development to all platforms (Including Linux!). If it weren't for Electron, I wouldn't even have a bunch of the apps I use today. Hell, I wouldn't have a good IDE, and I don't think I'd be as good in Typescript had I not been a day-1 VS Code user. I think the main thing preventing it from "feeling" good to most users is the most common complaint on HN about how each individual app is its own version of Chrome. This sucks; it's heavy, it's laggy, and users feel it even instinctively. OSes and frameworks have tried to solve this a bazillion ways. Edge WebView, Android WebView, Qt WebView, QtWebkit, whatever the iexplore stuff was in XP, …. Electron might have the opportunity to actually solve this. If it does, honestly, to hell with anything else. I'm sure over time the web world will gravitate towards a fairly common set of widgets that will, at one point or another be standardized. We'll reinvent UI frameworks under a different name, except this time they'll be running under the ultimate cross-platform framework.
- _bxg1 7y ago
  Agreed. We need a cross-OS definition of "web views" and a standard way to say, "use my default browser for all web views, including Electron".
  - skybrian 7y ago
    It seems like that's not really going to work for the developers of these apps due to browser variation and version skew? (If it were okay, why aren't they supporting web browsers already?) But maybe apps on the same version of Electron could share a runtime?
    - _bxg1 7y ago
      Web developers are already accustomed to supporting much more widely-varying browser versions, and web standards are expressly designed to be backwards-compatible basically forever. I don't think it would be a major problem.
brylie 7y ago
Is there ongoing work to reduce the memory footprint of Electron apps? I'm genuinely curious.
- rafaelvasco 7y ago
  I hope so;
- YesIndeedSir 7y ago
  Yes - WebAssembly. It would hopefully kill the whole thing as an end game.
  - _bxg1 7y ago
    It really wouldn't. WebAssembly has nothing to do with the rendering engine, which is the bulk of Electron's footprint (and also the bulk of its apps' processing overhead). The latter can only be improved by Chromium devs (and is being improved constantly). The former requires that we come up with a way to share a single Chromium copy across apps. There's really no other way around it.
    - martin1975 7y ago
      ironically, java applets provided via the JVM a way to run multiplatform, perhaps not all applets off a single JVM - I don't remember exactly if each java applet used its own JVM, but it wouldn't be a radical departure to have the JVM run multiple applets, cross platform, which is the entire reason the JVM was invented. Now instead of the JVM, we've these rather beefy runtimes due to Chrome, Node.JS, Javascript (v8)... which if you look at it, do the same things applets did, except different. I think the problem w/cross platform is that we want to have everything look 'native' for the platform.. and when you demand that, hooking into the native APIs is sort of inevitable. Instead, I believe rendering probably ought to be done by the runtimes themselves, sort of like JVM did w/AWT/Swing..or like Dart is doing right now. There's always going to be a trade off when wanting to have a single app that runs cross platform and maintain a native look/feel to it... Quite frankly, I'm not sure which is best, but I lean more toward 'do your own rendering' and port the runtime to run across platforms, kind of like the JVM ...except w/Chromium/V8/Node.JS. Sure it hogs memory and its slow... but I think most devs will take that over having to develop multiple apps doing the same thing per platform.
eicossa 7y ago
Wait ... let me see if I can anticipate the top comment "Electron consumes so many resources ... Why so resource hungry ... My workstation already runs Chrome, can't have electron apps bogging it down ... Slack runs on Electron ... VSCode is the only good Electron app ... Why are we doing this ... Dennis Ritchie would be turning in his grave" This topic could honestly trigger the "parse regex with html" kind of reply.
- windsurfer 7y ago
  Well, Slack is currently taking almost 3 GB of memory on my machine. Not entirely sure if that's due to Electron or Slack, but I have never found an Electron app that didn't consume vast swathes of memory. https://imgur.com/GscRFD7.png https://imgur.com/GscRFD7.png
  - 52-6F-62 7y ago
    I tend to get "helpers" that pile up that seem to consume the most. I developed an application with Electron (+ Vue + Node) for an internal tool used by non-technical staff at my work and I don't have nearly the consumption as some other applications, but there is a lot less occurring on the renderer process than it appears with other applications. I've added VSCode (with a large project), my application's usage (censored because it's proprietary, but it's a document-based application) and the worst memory offenders on my system (16GB 2015 MBP): https://imgur.com/a/9rs707J https://imgur.com/a/9rs707J I've heard of other similar strategies-- but the best one seems to be to offload as much of the work to the main process or talk to a binary wrapped up in the application and do as little lifting with the renderer (the Chromium portion) as possible. My results have been alright so far.
    - deleted 7y ago
      [deleted]
  - eicossa 7y ago
    Truth. When I first discovered Electron apps, i was amazed. Now i just walk away. I'm not saying any of these comments surrounding Electron are invalid, it's just that these things represent a kind of truthful circlejerk around the topic. I find it humanizes the HN crowd tbh. Otherwise most of the comments here are so aloof and definitive. Electron comments brings out all the normal folks :)
jszymborski 7y ago
I love HTML/JS as a desktop UI toolkit, but much prefer the approach Qt WebView approach where javascript callbacks hook directly to code as opposed to running an entire webserver/HTTP stack. If not for the performance, for the ability to skip the sort of security problems the Signal desktop app had run into at some point.
mangosherbet 7y ago
Is there a good introduction to starting development with Electron as someone who is a C++ developer? I find web development quite difficult to grok in general; lots of frameworks and technologies.
- crooked-v 7y ago
  Check out create-react-app: https://github.com/facebook/create-react-app https://github.com/facebook/create-react-app It sets up a 'modern' React-based web dev environment that can be used to immediately start experimenting with stuff. React acts as a view layer, so you can write views and components in HTML-ish declarative syntax while still getting live updates whenever data changes. Past that, it's common for people to add Redux or MobX, which both act as global data stores with good integration with React, and have lots of secondary libraries for transparently handling data persistence.
- crispinb 7y ago
  Quelle horreur - clearly web tech is the future of UI, and electron is a reasonable choice until a better solution comes along, but the ecosystem is a foul mess for developers. `npm [anything]` fills your hard drive with an astronomical tangle of hideous code. And there's webpack. You will end up wanting to strangle yourself. Avoid unless you really need it.
  - alyandon 7y ago
    I'm normally a backend developer but I was fooling around with using vue.js + jquery to build a simple SPA without the typical process of npm install <entire world>. When it came time to finally bundle my app into a single html + js file I settled on (well was forced to really) npm install rollup. After installing rollup, I had a package-lock.json file that was 1880 lines long with approximately 150 or so dependencies and a node_modules directory so huge that vscode choked trying to parse everything in it. To its credit, vscode asked me if I wanted to exclude node_modules from future consideration. All that from installing a single tool via npm. I just don't get modern web development.
- pjmlp 7y ago
choeger 7y ago
Hey, another electron thread. Wait a second, did someone already mention how horrible Javascript is? The memory consumption? The minimal integration into the OS/desktop (think accessibility)? Hmm ok, I need something new... Here it comes: chrome is inherently instable. The Google developers give a shit about their dependency management and have trillions of open source projects just literally copied into their trunk. They also don't provide any API to speak of, chromium as a library does not exist, and don't get me started about the arcane build process of chrome.
- marshallofsound 7y ago
  Disclaimer: Electron dev So few quick things, the projects that are copied are done so to guarantee deterministic builds in an isolated build environment (no dependencies on third party systems). The API you say they don't provide is literally the API that Electron uses. --> https://chromium.googlesource.com/chromium/src/+/HEAD/content/public/README.md https://chromium.googlesource.com/chromium/src/+/HEAD/conten... And as for the build process, eh, it's kinda slow but it's hardly arcane. On linux you can run like 4 commands and it'll build Chromeium.
  - choeger 7y ago
    Yeah. Four commands. The first one downloads binaries from the internet. If I was inclined to do so, I would not need to build in the first place ;). Give it a try with the current HEAD of their home-grown and undocumented build tool and see how far you get. And regarding the deterministic builds: I call bullshit. They just don't want to follow the different packaging guidelines from the different operating systems, so they repackage everything. Now I have to trust them to keep all these dependencies up-to-date and I have to accept the unecessary bloat? No way.
    - snek 7y ago
      > [build process] I agree, the chromium build tooling is unfriendly af. > I call bullshit Lot of works goes into deterministic builds, have fun going down this rabbit hole: https://bugs.chromium.org/p/chromium/issues/detail?id=314403 https://bugs.chromium.org/p/chromium/issues/detail?id=314403 > Now I have to trust them to keep all these dependencies up-to-date Looks like it rolls on average every 10-20 minutes: https://chromium.googlesource.com/chromium/src/+log/HEAD/DEPS https://chromium.googlesource.com/chromium/src/+log/HEAD/DEP... > and I have to accept the unecessary bloat? Ah yes, because all operating systems ship with a pristine installation of the latest pdfium.
millstone 7y ago
There's hate directed at performance, but Electron apps are just profoundly buggy. For example in Slack: 1. Non-functional items are routinely offered in the main menu and context menu. 2. The Undo and Redo menu items often just don't work. These do different things than the command key equivalents which should never happen. 3. It is easy to get into a state with multiple blinking insertion points. 4. The inactive appearance is identical to the active appearance. etc etc.
- scrollaway 7y ago
  None of these are innate to Electron. It's kinda like saying "Windows apps are just profoundly buggy", or "Telephone calls are just profoundly boring".
- inapis 7y ago
  That’s more of a fault on behalf of the devs though. You can pick any platform and you’ll find devs who’ll have something to complain about.
z3t4 7y ago
Electron (and also nw.js) are nice. But remember that when using a Electron app you are no longer sandboxed.
ethanpil 7y ago
A lot of the bloat complaints about Electron are addressed well in Sciter (https://sciter.com/ https://sciter.com/) although, Sciter has its own set of limitations. I have found Sciter a great option for many use cases. (I'm not affiliated with Sciter in any way).
- adev_ 7y ago
  Sciter and Ultralight are the way to go on paper. They address many of the issues of Electron and it does it in a very portable way. Instead of embedding the world in a giant toolkit, they give to you what you want as a library, easy to interface with native code. However they are proprietary, and this is a no go for me and many. There is no way I bind my software stack to an arbitrary unstable compiler ABI and its platforms. Nor I will bet on a toolkit that can disappear tomorrow if its only maintainer disappears or get hit by a bus. We need something like these projects, but OSS and still I would be happy to pay for that.
  - ethanpil 7y ago
    Ohh, never heard of Ultralight. Will check it out, thanks! I agree that licensing makes these products an issue for some, but they both seem to offer a very flexible free use option...
bnjmn 7y ago
Does anyone know why they chose Node.js 12.8.1 instead of 12.13.0, the first LTS release on the 12.x line?
The_rationalist 7y ago
As in every election threads, people will say "duh each electron has it's own instance of chromium" While you can trivially use solutions such as https://github.com/sentialx/electron-global https://github.com/sentialx/electron-global To fixe the issue. Moreover, Carlo solve this too. Ionic and Cordova (the electrons of the smartphones) already use locally installed browser.
chrisrickard 7y ago
I dig Electron, and had always assumed by now we would have a multi-OS CSS toolkit for "native looking" styles. I remember http://photonkit.com http://photonkit.com from back in the day, but I think there is room for something more comprehensive.
feross 7y ago
Duplicate: https://news.ycombinator.com/item?id=21338362 https://news.ycombinator.com/item?id=21338362
deleted 7y ago
[deleted]
semireg 7y ago
Electron 4 is end of life so that means many native node modules need a ton of rework to support node 10+. This is a pain point for electron app devs that rely on native modules for functionality. Time to roll up my C++ sleeves and spend weeks adding zero new features ... just trying to get my apps to build. Ugh. Any native node module gurus for hire? Totally serious here. App is https://label.live https://label.live

227 points by ausjke 7y ago

Every time Electron is mentioned I bust out the popcorn for the inevitable hate spewed towards it: "Javascript is a terrible language and no one should use it" "Separate instances of chrome for every app is dumb and consumes too much memory" "Qt is amazing and elegant and desktop-native. Why isn't everyone just using Qt?"

YesSureThing 7y ago
I would use Uno.platform . C++ is also a terrible language.
Hendrikto 7y ago
> "Separate instances of chrome for every app is dumb and consumes too much memory" That one is true though. Different Electron apps could at least share the runtime.
- judge2020 7y ago
  I imagine the different electron versions and different Chrome versions would make this hard without breaking things. Maybe a config option for "allow chromium between versions x and y" would solve this.
  - Hendrikto 7y ago
    Shouldn‘t Chrome be backwards compatible? I would hope so at least.
    - judge2020 7y ago
      Most electron projects I've seen have used webpack targeting ES2017 or earlier anyways which makes this unlikely, but if you compile for ESnext (or don't compile at all) and use a new V8 feature, you wouldn't want Chrome 69 running your app and getting stuck on old V8 not being able to use the new feature.
    - pawelk 7y ago
      Maybe it should, but it's not always the case. As a front end dev I have to fix issues related to bugs introduced by browser uptades every now and then and usually it's Chrome. On the web it's easy, deploy a fix and it's live. With a desktop app I can't even imagine the logistics involved.
- mikepurvis 7y ago
  Is that really possible? I feel like it would only work with considerable engineering effort, and even then, probably only if the bundled Chrome instances were all exactly the same version.
  - michaelmrose 7y ago
    This is literally how every gui library on planet earth works. Developers all build against a particular recent released version with all apps in the system expected to build against a small number of recent versions. If this is hard maybe its because the browser isn't a very good runtime to build against.
    - mikepurvis 7y ago
      Right, but those systems are set up from the get-go with that usage pattern in mind, where you have an expectation of ABI compatibility and the underlying libraries as a shared resource. The expectation with Electron has always been that you bundle a copy of it with your app, so that you're always targeting exactly that version.
- paulryanrogers 7y ago
  Except they cannot, Chromium (or is it Blink?) changes too frequently to reliably code for one version and expect backward compatibility of future releases. Electron versions could be shared libraries... except again BC breaking releases proliferate.
  - shaki-dora 7y ago
    Websites manage to target different versions, and browsers, and even device classes just fine.
  - hanniabu 7y ago
    Why can't it be based of Chrome's version number? If you know the version number at the time of release then you can say only use the same runtime if there's only a revision version difference, else you can use it's own run time. That packaged with auto-updates for the app to that developers can push updated builds every month or so should be fine.
  - diffeomorphism 7y ago
    Except they chose not to, preferring to allow for frequent breaking changes. This makes it easier for devs to make these rapid changes with all the cost/overhead payed by you.
- kodablah 7y ago
  With their multi-process approach, you'd have separate processes even when sharing the runtime to the point that sharing the DLLs likely has minimal benefit. It's the equivalent of running firing up Chrome twice w/ two different user profile dirs...shared libs, but no obvious perf advantage over two separate Chrome installs.
- pmarreck 7y ago
  1) Log into Slack in Chrome 2) Log into Discord in Chrome 3) Log into <insert application here> in Chrome Problem solved?
  - bhhaskin 7y ago
    Swap Firefox for Chrome and you are golden.
rafaelvasco 7y ago
Only second one is a really valid point;
mikepurvis 7y ago
The people complaining are not the customers, they're the product. Electron isn't sold to the users running Slack and Spotify and Atom, it's sold to the developers of those things with the promise of a low-friction path for existing web devs to deploy a native-ish application on multiple platforms.
rosybox 7y ago
The problem with Qt I have is how incredibly expensive it is. Sure it's free if you want to build something open source, but you know some of us have to also make money to pay for being alive and it's hard to bootstrap an application if you have to pay $5,508 up front, per developer, and then again on an annual basis.
- pritambaral 7y ago
  You can use Qt with closed source software, under the LGPL license that you don't have to pay for. Only the binaries that have Qt code need to be open. Don't statically link Qt libs into your closed-source code and you're good.
  - sroussey 7y ago
    And put that in an app store?
    - hellofunk 7y ago
      Yes, even on iOS.
      - kej 7y ago
        The LGPL requires end users to be able to view and modify the LGPL portion of the derivative work. Does iOS give end users that level of access to apps? (honest question, my outsider's impression of Apple is that they have stuff locked down more than that)
        jcelerier 7y ago
        the problem with iOS was that you had to pay 99$ a year to upload apps to your own phone, which prevent use of GPL code since it removes your right to do stuff on your own hardware. Fortunately this restriction was lifted since Xcode 7 a few years ago and it's nowadays not a problem at all - there are plenty of GPL / LGPL apps on the app store. Just put the code and build instructions on github, what matters is that users can patch, rebuild and upload the patched version to their phone.
draw_down 7y ago
I know, it’s amazing! Nice to see someone else here gets a kick out of it. Electron absolutely makes HNers lose their minds.

Razengan 7y ago

Since this is inevitably going to generate some discussion over native apps vs. Electron (ah there's already a fellow comment about it), I'd like to point out an example that is important to me of why Electron is an inferior experience for users: In the GitHub Desktop client, which is an Electron app, I can't spell check my commit messages, something that every text field in every native macOS app gets for free.

_bxg1 7y ago
Web text fields should also support that functionality, so it may be a question of GitHub breaking/disabling it in some way.
- judge2020 7y ago
  Kind of odd, is doesn't look like there's a built-in spell checker available in Chromium since you need a spell check provider[0]. I imagine Google injects it into their Chrome when deploying. 0: https://github.com/electron/electron/blob/master/docs/api/web-frame.md#webframesetspellcheckproviderlanguage-provider https://github.com/electron/electron/blob/master/docs/api/we...
  - _bxg1 7y ago
    That is interesting; I assumed it hooked into the OS-level functionality but it doesn't appear to. Hmm.
- bitwize 7y ago
  It's probably a question of the 2010s equivalent of Windows custom control masturbation ("look mom, I can create my own buttons!"): replacing perfectly good HTML elements with ground-up reimplementations written in DIV soup with JavaScript event handlers.
- Razengan 7y ago
  You're right; I just tested it in Discord, which does have a spell checker, and it seems to use the system dictionary (but it seems one way when teaching it new words), but it's still missing other global text field functionality: https://i.imgur.com/qpOU9dz.png https://i.imgur.com/qpOU9dz.png The point remains: Electron apps generally lose many of the features that the host OS gives native apps for free.

scrollaway 7y ago

I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit. For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as a user. But Electron has brought true cross-platform development to all platforms (Including Linux!). If it weren't for Electron, I wouldn't even have a bunch of the apps I use today. Hell, I wouldn't have a good IDE, and I don't think I'd be as good in Typescript had I not been a day-1 VS Code user. I think the main thing preventing it from "feeling" good to most users is the most common complaint on HN about how each individual app is its own version of Chrome. This sucks; it's heavy, it's laggy, and users feel it even instinctively. OSes and frameworks have tried to solve this a bazillion ways. Edge WebView, Android WebView, Qt WebView, QtWebkit, whatever the iexplore stuff was in XP, …. Electron might have the opportunity to actually solve this. If it does, honestly, to hell with anything else. I'm sure over time the web world will gravitate towards a fairly common set of widgets that will, at one point or another be standardized. We'll reinvent UI frameworks under a different name, except this time they'll be running under the ultimate cross-platform framework.

_bxg1 7y ago
Agreed. We need a cross-OS definition of "web views" and a standard way to say, "use my default browser for all web views, including Electron".
- skybrian 7y ago
  It seems like that's not really going to work for the developers of these apps due to browser variation and version skew? (If it were okay, why aren't they supporting web browsers already?) But maybe apps on the same version of Electron could share a runtime?
  - _bxg1 7y ago
    Web developers are already accustomed to supporting much more widely-varying browser versions, and web standards are expressly designed to be backwards-compatible basically forever. I don't think it would be a major problem.

brylie 7y ago

Is there ongoing work to reduce the memory footprint of Electron apps? I'm genuinely curious.

rafaelvasco 7y ago
I hope so;
YesIndeedSir 7y ago
Yes - WebAssembly. It would hopefully kill the whole thing as an end game.
- _bxg1 7y ago
  It really wouldn't. WebAssembly has nothing to do with the rendering engine, which is the bulk of Electron's footprint (and also the bulk of its apps' processing overhead). The latter can only be improved by Chromium devs (and is being improved constantly). The former requires that we come up with a way to share a single Chromium copy across apps. There's really no other way around it.
  - martin1975 7y ago
    ironically, java applets provided via the JVM a way to run multiplatform, perhaps not all applets off a single JVM - I don't remember exactly if each java applet used its own JVM, but it wouldn't be a radical departure to have the JVM run multiple applets, cross platform, which is the entire reason the JVM was invented. Now instead of the JVM, we've these rather beefy runtimes due to Chrome, Node.JS, Javascript (v8)... which if you look at it, do the same things applets did, except different. I think the problem w/cross platform is that we want to have everything look 'native' for the platform.. and when you demand that, hooking into the native APIs is sort of inevitable. Instead, I believe rendering probably ought to be done by the runtimes themselves, sort of like JVM did w/AWT/Swing..or like Dart is doing right now. There's always going to be a trade off when wanting to have a single app that runs cross platform and maintain a native look/feel to it... Quite frankly, I'm not sure which is best, but I lean more toward 'do your own rendering' and port the runtime to run across platforms, kind of like the JVM ...except w/Chromium/V8/Node.JS. Sure it hogs memory and its slow... but I think most devs will take that over having to develop multiple apps doing the same thing per platform.

eicossa 7y ago

Wait ... let me see if I can anticipate the top comment "Electron consumes so many resources ... Why so resource hungry ... My workstation already runs Chrome, can't have electron apps bogging it down ... Slack runs on Electron ... VSCode is the only good Electron app ... Why are we doing this ... Dennis Ritchie would be turning in his grave" This topic could honestly trigger the "parse regex with html" kind of reply.

windsurfer 7y ago
Well, Slack is currently taking almost 3 GB of memory on my machine. Not entirely sure if that's due to Electron or Slack, but I have never found an Electron app that didn't consume vast swathes of memory. https://imgur.com/GscRFD7.png https://imgur.com/GscRFD7.png
- 52-6F-62 7y ago
  I tend to get "helpers" that pile up that seem to consume the most. I developed an application with Electron (+ Vue + Node) for an internal tool used by non-technical staff at my work and I don't have nearly the consumption as some other applications, but there is a lot less occurring on the renderer process than it appears with other applications. I've added VSCode (with a large project), my application's usage (censored because it's proprietary, but it's a document-based application) and the worst memory offenders on my system (16GB 2015 MBP): https://imgur.com/a/9rs707J https://imgur.com/a/9rs707J I've heard of other similar strategies-- but the best one seems to be to offload as much of the work to the main process or talk to a binary wrapped up in the application and do as little lifting with the renderer (the Chromium portion) as possible. My results have been alright so far.
  - deleted 7y ago
    [deleted]
- eicossa 7y ago
  Truth. When I first discovered Electron apps, i was amazed. Now i just walk away. I'm not saying any of these comments surrounding Electron are invalid, it's just that these things represent a kind of truthful circlejerk around the topic. I find it humanizes the HN crowd tbh. Otherwise most of the comments here are so aloof and definitive. Electron comments brings out all the normal folks :)

jszymborski 7y ago

I love HTML/JS as a desktop UI toolkit, but much prefer the approach Qt WebView approach where javascript callbacks hook directly to code as opposed to running an entire webserver/HTTP stack. If not for the performance, for the ability to skip the sort of security problems the Signal desktop app had run into at some point.

mangosherbet 7y ago

Is there a good introduction to starting development with Electron as someone who is a C++ developer? I find web development quite difficult to grok in general; lots of frameworks and technologies.

crooked-v 7y ago
Check out create-react-app: https://github.com/facebook/create-react-app https://github.com/facebook/create-react-app It sets up a 'modern' React-based web dev environment that can be used to immediately start experimenting with stuff. React acts as a view layer, so you can write views and components in HTML-ish declarative syntax while still getting live updates whenever data changes. Past that, it's common for people to add Redux or MobX, which both act as global data stores with good integration with React, and have lots of secondary libraries for transparently handling data persistence.
crispinb 7y ago
Quelle horreur - clearly web tech is the future of UI, and electron is a reasonable choice until a better solution comes along, but the ecosystem is a foul mess for developers. `npm [anything]` fills your hard drive with an astronomical tangle of hideous code. And there's webpack. You will end up wanting to strangle yourself. Avoid unless you really need it.
- alyandon 7y ago
  I'm normally a backend developer but I was fooling around with using vue.js + jquery to build a simple SPA without the typical process of npm install <entire world>. When it came time to finally bundle my app into a single html + js file I settled on (well was forced to really) npm install rollup. After installing rollup, I had a package-lock.json file that was 1880 lines long with approximately 150 or so dependencies and a node_modules directory so huge that vscode choked trying to parse everything in it. To its credit, vscode asked me if I wanted to exclude node_modules from future consideration. All that from installing a single tool via npm. I just don't get modern web development.
pjmlp 7y ago

choeger 7y ago

Hey, another electron thread. Wait a second, did someone already mention how horrible Javascript is? The memory consumption? The minimal integration into the OS/desktop (think accessibility)? Hmm ok, I need something new... Here it comes: chrome is inherently instable. The Google developers give a shit about their dependency management and have trillions of open source projects just literally copied into their trunk. They also don't provide any API to speak of, chromium as a library does not exist, and don't get me started about the arcane build process of chrome.

marshallofsound 7y ago
Disclaimer: Electron dev So few quick things, the projects that are copied are done so to guarantee deterministic builds in an isolated build environment (no dependencies on third party systems). The API you say they don't provide is literally the API that Electron uses. --> https://chromium.googlesource.com/chromium/src/+/HEAD/content/public/README.md https://chromium.googlesource.com/chromium/src/+/HEAD/conten... And as for the build process, eh, it's kinda slow but it's hardly arcane. On linux you can run like 4 commands and it'll build Chromeium.
- choeger 7y ago
  Yeah. Four commands. The first one downloads binaries from the internet. If I was inclined to do so, I would not need to build in the first place ;). Give it a try with the current HEAD of their home-grown and undocumented build tool and see how far you get. And regarding the deterministic builds: I call bullshit. They just don't want to follow the different packaging guidelines from the different operating systems, so they repackage everything. Now I have to trust them to keep all these dependencies up-to-date and I have to accept the unecessary bloat? No way.
  - snek 7y ago
    > [build process] I agree, the chromium build tooling is unfriendly af. > I call bullshit Lot of works goes into deterministic builds, have fun going down this rabbit hole: https://bugs.chromium.org/p/chromium/issues/detail?id=314403 https://bugs.chromium.org/p/chromium/issues/detail?id=314403 > Now I have to trust them to keep all these dependencies up-to-date Looks like it rolls on average every 10-20 minutes: https://chromium.googlesource.com/chromium/src/+log/HEAD/DEPS https://chromium.googlesource.com/chromium/src/+log/HEAD/DEP... > and I have to accept the unecessary bloat? Ah yes, because all operating systems ship with a pristine installation of the latest pdfium.

millstone 7y ago

There's hate directed at performance, but Electron apps are just profoundly buggy. For example in Slack: 1. Non-functional items are routinely offered in the main menu and context menu. 2. The Undo and Redo menu items often just don't work. These do different things than the command key equivalents which should never happen. 3. It is easy to get into a state with multiple blinking insertion points. 4. The inactive appearance is identical to the active appearance. etc etc.

scrollaway 7y ago
None of these are innate to Electron. It's kinda like saying "Windows apps are just profoundly buggy", or "Telephone calls are just profoundly boring".
inapis 7y ago
That’s more of a fault on behalf of the devs though. You can pick any platform and you’ll find devs who’ll have something to complain about.

z3t4 7y ago

Electron (and also nw.js) are nice. But remember that when using a Electron app you are no longer sandboxed.

ethanpil 7y ago

A lot of the bloat complaints about Electron are addressed well in Sciter (https://sciter.com/ https://sciter.com/) although, Sciter has its own set of limitations. I have found Sciter a great option for many use cases. (I'm not affiliated with Sciter in any way).

adev_ 7y ago
Sciter and Ultralight are the way to go on paper. They address many of the issues of Electron and it does it in a very portable way. Instead of embedding the world in a giant toolkit, they give to you what you want as a library, easy to interface with native code. However they are proprietary, and this is a no go for me and many. There is no way I bind my software stack to an arbitrary unstable compiler ABI and its platforms. Nor I will bet on a toolkit that can disappear tomorrow if its only maintainer disappears or get hit by a bus. We need something like these projects, but OSS and still I would be happy to pay for that.
- ethanpil 7y ago
  Ohh, never heard of Ultralight. Will check it out, thanks! I agree that licensing makes these products an issue for some, but they both seem to offer a very flexible free use option...

bnjmn 7y ago

Does anyone know why they chose Node.js 12.8.1 instead of 12.13.0, the first LTS release on the 12.x line?

The_rationalist 7y ago

As in every election threads, people will say "duh each electron has it's own instance of chromium" While you can trivially use solutions such as https://github.com/sentialx/electron-global https://github.com/sentialx/electron-global To fixe the issue. Moreover, Carlo solve this too. Ionic and Cordova (the electrons of the smartphones) already use locally installed browser.

chrisrickard 7y ago

I dig Electron, and had always assumed by now we would have a multi-OS CSS toolkit for "native looking" styles. I remember http://photonkit.com http://photonkit.com from back in the day, but I think there is room for something more comprehensive.

feross 7y ago

Duplicate: https://news.ycombinator.com/item?id=21338362 https://news.ycombinator.com/item?id=21338362

deleted 7y ago

[deleted]

semireg 7y ago

Electron 4 is end of life so that means many native node modules need a ton of rework to support node 10+. This is a pain point for electron app devs that rely on native modules for functionality. Time to roll up my C++ sleeves and spend weeks adding zero new features ... just trying to get my apps to build. Ugh. Any native node module gurus for hire? Totally serious here. App is https://label.live https://label.live