6 ms·

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"

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.

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.