7 ms·

I have a hard time understanding why platforms like electron are so popular. The predictions from Gary Bernhardt seem to really be true, in the future everythi

by jokoon 5y ago

I have a hard time understanding why platforms like electron are so popular. The predictions from Gary Bernhardt seem to really be true, in the future everything will be javascript. I wonder if somebody actually tried to make an OS that only has a browser, that's what Chrome OS actually is, after all.

fastball 5y ago
We built our product for the web. People wanted our product as a desktop app. So we wrapped it in Electron and now we have 3 desktop apps. People wanted our product as a mobile app. So we wrapped it in Capacitor and now we have two mobile apps. There are just two of us building this product.
- AtlasBarfed 5y ago
  So efficient for you, but 1000x more resources everywhere it runs. I wonder if someone can quantify the carbon impact of Electron just from Slack.
  - adwn 5y ago
    > So efficient for you, but 1000x more resources everywhere it runs. And yet, to the people who do use their app on the desktop, this is obviously a preferable situation to not using the app – which would probably be the case had the developers decided against Electron.
    - microtonal 5y ago
      And yet, we have single indie developers writing multiplatform Qt [1] and macOS native [2] Slack apps. Last time I checked, Ripcord used 30-40MiB RAM, a small fraction of the official Slack client. Writing native apps (or a Qt app) would well be in reach of Slack. In fact, they already have native apps. E.g. Slack for iOS/iPadOS is native [3], just allowing M1 Mac users to use the iPadOS version would most likely be a large net improvement in resource use for those who'd choose to install the iPadOS version. Unfortunately, they disallow iPadOS installs on macOS to force people to use the terrible Electron version. [1] https://cancel.fm/ripcord/ https://cancel.fm/ripcord/ [2] https://shrugs.app https://shrugs.app [3] https://twitter.com/slackhq/status/931599784137363459?lang=en https://twitter.com/slackhq/status/931599784137363459?lang=e...
      - kaba0 5y ago
        Exactly this is what I don’t get. Huge corporations are so hard for cross-platform development while Facebook, Google, Microsoft et alia could just spawn as many developer for a new platform as they can. I know that management is trying to cut back on every single penny, but is financing React Native really that much cheaper than just writing that tiny amount of code for each platform that will call into that single native library/web API used everywhere? Especially when you have to have a native dev either way because bugs will happen that will need platform-specific knowledge as well. Because I can honestly understand going cross-platform by a small startup that can’t finance n*numOfPlatforms devs, but for Slack and the like it makes zero sense to me.
      - fastball 5y ago
        Ripcord/Shrugs don't have mobile apps, don't run on the web, and do not need to maintain a backend.
- throw10920 5y ago
  What prevents you from using Qt to do almost exactly the same thing?
  - iterati 5y ago
    2 developers. Also, "almost exactly" is a funny oxymoron.
    - throw10920 5y ago
      Qt is just as easy for 2 devs are webtech is? (that's a rhetorical question - it is.)
      - iterati 5y ago
        Qt + Webtech is twice as hard, though.
  - kristiandupont 5y ago
    They built their product for the web.
  - fastball 5y ago
    Our platform[1] needs to run on web/mobile, so... Qt would not allow us to do even close to the exact same thing. [1] To help provide more context: https://supernotes.app/ https://supernotes.app/
surajs 5y ago
fn-mote 5y ago
> I have a hard time understanding why platforms like electron are so popular. To what extent is Electron's popularity due to getting cross-platform availability without writing your code 3x? The advantages of a native app have to be worth the costs... and I'm seeing plenty of Electron apps so there's a lot of people making that cost-benefit tradeoff. I share the dislike for bloated apps... but every time my stuff takes 10 seconds to start up I think more about keeping it running the whole day than submitting a PR to remove cruft.
sbarre 5y ago
Aside from the improvements to project timelines, Electron and similar products are popular because they improve the developer experience, and in 2022 the developer experience is what matters the most to many software companies (yes, in many cases ahead of the customer experience). DX directly drives engagement and retention, and good developers are hard to find (and keep!). And like it or not, there are more and more developers entering the industry with web-only training, so we have products that reflect the stack and tooling those developers are most proficient with.
- formerly_proven 5y ago
  JS DX always seemed really quite bad whenever I looked. A constantly shifting landscape of frameworks and packages where nothing will stand for long before being eroded away.
  - yayr 5y ago
    let's see - language: ES / Typescript are quite established - CSS: also quite established - Frameworks: there is still a lot of innovation here, but also React / Vue / Angular are quite established. on that latter part I prefer the innovation. Let's just imagine for a while what UI would look like if we only had Swing (Java) or QT (C++)
    - blub 5y ago
      At least for Qt, the answer's quite simple: you'd have KDE and the associated apps. As for the stability of the front-end ecosystem, it doesn't exist. The many articles that were posted on HN over the years complaining about the endless quagmire of front-end frameworks, libraries and technologies explain this better than I could.
    - jcelerier 5y ago
      > Let's just imagine for a while what UI would look like if we only had Swing (Java) or QT (C++) yes, Telegram looks so bad right ?
OJFord 5y ago
> I wonder if somebody actually tried to make an OS that only has a browser, that's what Chrome OS actually is, after all. What do you mean then, how does the hypothetical OS differ from ChromeOS?
rk06 5y ago
would you rather have three teams developing one app on three platforms (windows, mac, linux) or one team developing one app for all platforms? It makes perfect business sense to use electron. It opens paths which otherwise would be very costly and hence infeasible.
- azangru 5y ago
  > It makes perfect business sense to use electron. In many cases, it should also make perfect business sense to use PWAs. I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps.
  - MontagFTB 5y ago
    > I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps. This is true. We managed to wrap a very large portion of the desktop code base into a “portable” library (with some customization at the point the library hits the OS, e.g., file IO.) This library is compiled specifically for the OS it’s going to run on (iOS, Web) to give us the best performance we can muster. The UI for each implementation is bespoke. This lets us build native interactions on the platforms we ship to, giving the end user the best look-and-feel for the platform they’re on. The flip side to this is development cost and time. In the long run, we believe it is worth it. Rewriting Photoshop in Electron would have been infeasible and the performance hit a non-starter. The path we’ve taken has some trade offs to it, but is the right one given the legacy tech we have and what we want to do with it.
    - maxerickson 5y ago
      There's a terrible performance regression in Illustrator 26 when working with files with many objects. Works fine in 25, UI freezes for several seconds in 26. Windows 10, pulling in part of an engineering drawing from a PDF (so many thousands of objects).
      - MontagFTB 5y ago
SavantIdiot 5y ago
Because it saves my company 66% in development costs.
- throw10920 5y ago
  It takes 3x as much effort to write an application in Qt than using web technologies?
  - SavantIdiot 5y ago
    I wasn't even talking about the penalty of writing a Qt application in C++. That's a different penalty. Qt doesn't really compare with what can be done with a good UX/UI dev on the team, and in much less time. And there are far more front-end devs than Qt experts.
    - throw10920 5y ago
      > Qt doesn't really compare with what can be done with a good UX/UI dev on the team Those are orthogonal. UI/UX is platform-agnostic - if you're only developing Electron UIs, you're not actually good at UI/UX. > in much less time Are you telling me that an Electron developer will be able to implement a system significantly faster than an equally-experienced Qt developer? > there are far more front-end devs than Qt experts You don't need to be an "expert" to use Qt - it has a relatively simple API for simple use-cases - it's not rocket science or distributed computing.
      - SavantIdiot 5y ago
        > Are you telling me that an Electron developer will be able to implement a system significantly faster than an equally-experienced Qt developer? Yes. Hands down. I'm actually saying two things: there are far fewer Qt developers, and the learning curve is much steeper. This has huge impact on maintaining and improving the code. We started with Qt and abandoned it because it is way easier to bring someone new in and get them started than having someone climb the curve to learn Qt and C++. Plus spinning up new features in Qt is laughably slow compared to how quickly a frontend dev can do the same in Electron: the former takes days, the latter is practically interactive. It was such a clear choice to abandon Qt. I was primarily worried Electron wouldn't last long, but we wrote our first app with it 6 years ago and it has remained completely stable. The biggest dev hits have been in Node peripheral support as they get better, like BLE and serial port interfaces.
yboris 5y ago
I chose Electron for the app I was building because it would make sure the app I create (1 code base with Angular) would perform exactly the same way on Mac, Windows, and Linux. It required virtually no learning of anything new (just look up some Electron API like "minimize window") and I was done. https://videohubapp.com/ https://videohubapp.com/ & https://github.com/whyboris/Video-Hub-App https://github.com/whyboris/Video-Hub-App As a single developer, I was able to get an app out in a few months and have been improving it for 4 years now. I love it (enough to create a Renamer app too: https://yboris.dev/renamer/ https://yboris.dev/renamer/ ).
lijogdfljk 5y ago
> I have a hard time understanding why platforms like electron are so popular. For an example. I'm writing a FOSS app mainly for myself, but i am publishing it for everyone of course. I want to support Browsers, but also "Apps" in OSs. I'm on Linux, MacOS, Windows and iOS every day. I do not, by a large margin, have the time to write my application in 3 or 4 different native UI toolkits. Furthermore, my application has a lot of text editing and rendering functionality, one i'd have to then reinvent in various UI toolkits, unless i used something that crossed all OSs above perfectly. Finally, my app has WASM plugins, similar to Obsidian.md, to allow the user to easily extend the application. All together i will not, by a large margin, use anything Native. I barely have enough time _(don't, honestly lol)_ to write the app once - let alone supporting all the above platforms. I'm targeting the web. As an aside, i'm writing this in 100% Rust lol. No JS, because i prefer Rust.
throw10920 5y ago
Here are the reasons, bad as they might be: (1) Branding. Businesses want their app to be thoroughly branded, so they'd rather have a canvas where they can invent their own buttons than use something cross-platform native like Qt. (2) Hiring. Existing developer base trained on webtech. Qt is a C++ thing - there's a far greater hiring pool for webdevs than C++ devs. (3) Ignorance. Some developers don't really know that Qt exists, or want to go through the trouble of learning it. None of these reasons benefit the user - but Electron isn't chosen by those who want to benefit the user in the first place.
didip 5y ago
It is not hard for me to understand that even though I am not a client-side engineer. Web tech (HTML, JS & CSS) are widely understood with millions of tutorial reference. On top of that, you get a cross OS build that looks the same everywhere. If all you are paying are just CPU and RAM, then that is a great tradeoff.
- worik 5y ago
  The bits that face the user are an important part of, but only a part of, all the gears and wheels that make a computer programme useful
pornel 5y ago
Right-click, Inspect Element. Web development tools have become fantastic UI debugging tools. You can inspect live running UI and tweak it in real time without a rebuild. CSS is very powerful, and it's relatively easy to build complex layouts with animations. People joke how it's impossible to center things, but CSS has matured beyond that (IE is dead).
- int_19h 5y ago
  WPF had the equivalent of "inspect element" 10 years ago. You don't need HTML for that, you just need good tooling.
  - pornel 5y ago
    I must admit, I haven't been following Windows toolkits since MFC. I've only heard about WPF in the context of dead Longhorn features. Isn't it deprecated in favor of WinUI or whatever replaced Metro?
    - int_19h 5y ago
      Officially, it isn't (e.g. it got ported to .NET Core). De facto, it is, but it still works just fine, as do WinForms, and all the tooling support is still there. That said, I've mentioned WPF mostly because that's what I'm personally familiar with. The same inspector-type tooling is available for newer XAML-based frameworks, as well: https://docs.microsoft.com/en-us/visualstudio/xaml-tools/inspect-xaml-properties-while-debugging https://docs.microsoft.com/en-us/visualstudio/xaml-tools/ins...

by jokoon 5y ago

fastball 5y ago

We built our product for the web. People wanted our product as a desktop app. So we wrapped it in Electron and now we have 3 desktop apps. People wanted our product as a mobile app. So we wrapped it in Capacitor and now we have two mobile apps. There are just two of us building this product.

AtlasBarfed 5y ago
So efficient for you, but 1000x more resources everywhere it runs. I wonder if someone can quantify the carbon impact of Electron just from Slack.
- adwn 5y ago
  > So efficient for you, but 1000x more resources everywhere it runs. And yet, to the people who do use their app on the desktop, this is obviously a preferable situation to not using the app – which would probably be the case had the developers decided against Electron.
  - microtonal 5y ago
    And yet, we have single indie developers writing multiplatform Qt [1] and macOS native [2] Slack apps. Last time I checked, Ripcord used 30-40MiB RAM, a small fraction of the official Slack client. Writing native apps (or a Qt app) would well be in reach of Slack. In fact, they already have native apps. E.g. Slack for iOS/iPadOS is native [3], just allowing M1 Mac users to use the iPadOS version would most likely be a large net improvement in resource use for those who'd choose to install the iPadOS version. Unfortunately, they disallow iPadOS installs on macOS to force people to use the terrible Electron version. [1] https://cancel.fm/ripcord/ https://cancel.fm/ripcord/ [2] https://shrugs.app https://shrugs.app [3] https://twitter.com/slackhq/status/931599784137363459?lang=en https://twitter.com/slackhq/status/931599784137363459?lang=e...
    - kaba0 5y ago
      Exactly this is what I don’t get. Huge corporations are so hard for cross-platform development while Facebook, Google, Microsoft et alia could just spawn as many developer for a new platform as they can. I know that management is trying to cut back on every single penny, but is financing React Native really that much cheaper than just writing that tiny amount of code for each platform that will call into that single native library/web API used everywhere? Especially when you have to have a native dev either way because bugs will happen that will need platform-specific knowledge as well. Because I can honestly understand going cross-platform by a small startup that can’t finance n*numOfPlatforms devs, but for Slack and the like it makes zero sense to me.
    - fastball 5y ago
      Ripcord/Shrugs don't have mobile apps, don't run on the web, and do not need to maintain a backend.
throw10920 5y ago
What prevents you from using Qt to do almost exactly the same thing?
- iterati 5y ago
  2 developers. Also, "almost exactly" is a funny oxymoron.
  - throw10920 5y ago
    Qt is just as easy for 2 devs are webtech is? (that's a rhetorical question - it is.)
    - iterati 5y ago
      Qt + Webtech is twice as hard, though.
- kristiandupont 5y ago
  They built their product for the web.
- fastball 5y ago
  Our platform[1] needs to run on web/mobile, so... Qt would not allow us to do even close to the exact same thing. [1] To help provide more context: https://supernotes.app/ https://supernotes.app/

surajs 5y ago

fn-mote 5y ago

> I have a hard time understanding why platforms like electron are so popular. To what extent is Electron's popularity due to getting cross-platform availability without writing your code 3x? The advantages of a native app have to be worth the costs... and I'm seeing plenty of Electron apps so there's a lot of people making that cost-benefit tradeoff. I share the dislike for bloated apps... but every time my stuff takes 10 seconds to start up I think more about keeping it running the whole day than submitting a PR to remove cruft.

sbarre 5y ago

Aside from the improvements to project timelines, Electron and similar products are popular because they improve the developer experience, and in 2022 the developer experience is what matters the most to many software companies (yes, in many cases ahead of the customer experience). DX directly drives engagement and retention, and good developers are hard to find (and keep!). And like it or not, there are more and more developers entering the industry with web-only training, so we have products that reflect the stack and tooling those developers are most proficient with.

formerly_proven 5y ago
JS DX always seemed really quite bad whenever I looked. A constantly shifting landscape of frameworks and packages where nothing will stand for long before being eroded away.
- yayr 5y ago
  let's see - language: ES / Typescript are quite established - CSS: also quite established - Frameworks: there is still a lot of innovation here, but also React / Vue / Angular are quite established. on that latter part I prefer the innovation. Let's just imagine for a while what UI would look like if we only had Swing (Java) or QT (C++)
  - blub 5y ago
    At least for Qt, the answer's quite simple: you'd have KDE and the associated apps. As for the stability of the front-end ecosystem, it doesn't exist. The many articles that were posted on HN over the years complaining about the endless quagmire of front-end frameworks, libraries and technologies explain this better than I could.
  - jcelerier 5y ago
    > Let's just imagine for a while what UI would look like if we only had Swing (Java) or QT (C++) yes, Telegram looks so bad right ?

OJFord 5y ago

> I wonder if somebody actually tried to make an OS that only has a browser, that's what Chrome OS actually is, after all. What do you mean then, how does the hypothetical OS differ from ChromeOS?

rk06 5y ago

would you rather have three teams developing one app on three platforms (windows, mac, linux) or one team developing one app for all platforms? It makes perfect business sense to use electron. It opens paths which otherwise would be very costly and hence infeasible.

azangru 5y ago
> It makes perfect business sense to use electron. In many cases, it should also make perfect business sense to use PWAs. I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps.
- MontagFTB 5y ago
  > I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps. This is true. We managed to wrap a very large portion of the desktop code base into a “portable” library (with some customization at the point the library hits the OS, e.g., file IO.) This library is compiled specifically for the OS it’s going to run on (iOS, Web) to give us the best performance we can muster. The UI for each implementation is bespoke. This lets us build native interactions on the platforms we ship to, giving the end user the best look-and-feel for the platform they’re on. The flip side to this is development cost and time. In the long run, we believe it is worth it. Rewriting Photoshop in Electron would have been infeasible and the performance hit a non-starter. The path we’ve taken has some trade offs to it, but is the right one given the legacy tech we have and what we want to do with it.
  - maxerickson 5y ago
    There's a terrible performance regression in Illustrator 26 when working with files with many objects. Works fine in 25, UI freezes for several seconds in 26. Windows 10, pulling in part of an engineering drawing from a PDF (so many thousands of objects).
    - MontagFTB 5y ago

SavantIdiot 5y ago

Because it saves my company 66% in development costs.

throw10920 5y ago
It takes 3x as much effort to write an application in Qt than using web technologies?
- SavantIdiot 5y ago
  I wasn't even talking about the penalty of writing a Qt application in C++. That's a different penalty. Qt doesn't really compare with what can be done with a good UX/UI dev on the team, and in much less time. And there are far more front-end devs than Qt experts.
  - throw10920 5y ago
    > Qt doesn't really compare with what can be done with a good UX/UI dev on the team Those are orthogonal. UI/UX is platform-agnostic - if you're only developing Electron UIs, you're not actually good at UI/UX. > in much less time Are you telling me that an Electron developer will be able to implement a system significantly faster than an equally-experienced Qt developer? > there are far more front-end devs than Qt experts You don't need to be an "expert" to use Qt - it has a relatively simple API for simple use-cases - it's not rocket science or distributed computing.
    - SavantIdiot 5y ago
      > Are you telling me that an Electron developer will be able to implement a system significantly faster than an equally-experienced Qt developer? Yes. Hands down. I'm actually saying two things: there are far fewer Qt developers, and the learning curve is much steeper. This has huge impact on maintaining and improving the code. We started with Qt and abandoned it because it is way easier to bring someone new in and get them started than having someone climb the curve to learn Qt and C++. Plus spinning up new features in Qt is laughably slow compared to how quickly a frontend dev can do the same in Electron: the former takes days, the latter is practically interactive. It was such a clear choice to abandon Qt. I was primarily worried Electron wouldn't last long, but we wrote our first app with it 6 years ago and it has remained completely stable. The biggest dev hits have been in Node peripheral support as they get better, like BLE and serial port interfaces.

yboris 5y ago

I chose Electron for the app I was building because it would make sure the app I create (1 code base with Angular) would perform exactly the same way on Mac, Windows, and Linux. It required virtually no learning of anything new (just look up some Electron API like "minimize window") and I was done. https://videohubapp.com/ https://videohubapp.com/ & https://github.com/whyboris/Video-Hub-App https://github.com/whyboris/Video-Hub-App As a single developer, I was able to get an app out in a few months and have been improving it for 4 years now. I love it (enough to create a Renamer app too: https://yboris.dev/renamer/ https://yboris.dev/renamer/ ).

lijogdfljk 5y ago

> I have a hard time understanding why platforms like electron are so popular. For an example. I'm writing a FOSS app mainly for myself, but i am publishing it for everyone of course. I want to support Browsers, but also "Apps" in OSs. I'm on Linux, MacOS, Windows and iOS every day. I do not, by a large margin, have the time to write my application in 3 or 4 different native UI toolkits. Furthermore, my application has a lot of text editing and rendering functionality, one i'd have to then reinvent in various UI toolkits, unless i used something that crossed all OSs above perfectly. Finally, my app has WASM plugins, similar to Obsidian.md, to allow the user to easily extend the application. All together i will not, by a large margin, use anything Native. I barely have enough time _(don't, honestly lol)_ to write the app once - let alone supporting all the above platforms. I'm targeting the web. As an aside, i'm writing this in 100% Rust lol. No JS, because i prefer Rust.

throw10920 5y ago

Here are the reasons, bad as they might be: (1) Branding. Businesses want their app to be thoroughly branded, so they'd rather have a canvas where they can invent their own buttons than use something cross-platform native like Qt. (2) Hiring. Existing developer base trained on webtech. Qt is a C++ thing - there's a far greater hiring pool for webdevs than C++ devs. (3) Ignorance. Some developers don't really know that Qt exists, or want to go through the trouble of learning it. None of these reasons benefit the user - but Electron isn't chosen by those who want to benefit the user in the first place.

didip 5y ago

It is not hard for me to understand that even though I am not a client-side engineer. Web tech (HTML, JS & CSS) are widely understood with millions of tutorial reference. On top of that, you get a cross OS build that looks the same everywhere. If all you are paying are just CPU and RAM, then that is a great tradeoff.

worik 5y ago
The bits that face the user are an important part of, but only a part of, all the gears and wheels that make a computer programme useful

pornel 5y ago

Right-click, Inspect Element. Web development tools have become fantastic UI debugging tools. You can inspect live running UI and tweak it in real time without a rebuild. CSS is very powerful, and it's relatively easy to build complex layouts with animations. People joke how it's impossible to center things, but CSS has matured beyond that (IE is dead).

int_19h 5y ago
WPF had the equivalent of "inspect element" 10 years ago. You don't need HTML for that, you just need good tooling.
- pornel 5y ago
  I must admit, I haven't been following Windows toolkits since MFC. I've only heard about WPF in the context of dead Longhorn features. Isn't it deprecated in favor of WinUI or whatever replaced Metro?
  - int_19h 5y ago
    Officially, it isn't (e.g. it got ported to .NET Core). De facto, it is, but it still works just fine, as do WinForms, and all the tooling support is still there. That said, I've mentioned WPF mostly because that's what I'm personally familiar with. The same inspector-type tooling is available for newer XAML-based frameworks, as well: https://docs.microsoft.com/en-us/visualstudio/xaml-tools/inspect-xaml-properties-while-debugging https://docs.microsoft.com/en-us/visualstudio/xaml-tools/ins...