4 ms·

I think using Electron is excusable if you are a startup, like you said your time is limited. It's much less acceptable if you are Slack and still ship a slow

by remram 3y ago

I think using Electron is excusable if you are a startup, like you said your time is limited. It's much less acceptable if you are Slack and still ship a slow bloated Electron app 10 years in.

nine_k 3y ago
The truth us that once you have shipped Electron, there's no way back, the cost of switching is too high. This is not specific to Electron, it's a similar effect with every core technology, all the way to COBOL.
- dathinab 3y ago
  Most electron apps are (mostly but not solely) a bundling of the web-app. So the cost is less the cost of "switching" and more the cost of initially writing a native app. In turn the actual question is how to reuse as much code as possible between the web-app and native apps without it introducing a lot of friction. And one of the few reliable, nicely (developer) usable answers for this is currently electron. For "business logic" there somewhat are already other answers, some languages run on most targets reliable and there is also wasm which often still needs a bit more tooling but has a lot of potential for such use cases (e.g. see Disney which AFIK does have their core business logic compiled to a wasm blob and then "only" provide UI/system glue to bundle it in on all platforms their streaming app runs on). The problem is UI, you really don't want to reimplement UI and the mapping of non HTML/CSS producing UI to a mix of HTML/CSS on some platforms and native components on other often doesn't work grate so it's not surprising people decided to "just go with HTML/CSS everywhere". And if you are already there going with electron isn't "that" much more overhead.
- theappsecguy 3y ago
  This right here. Something monumental would have to happen for senior leadership to green light a rewrite, because that’s a massive project that will bring in no additional revenue.
  - remram 3y ago
    That they are content with mediocrity, I have observed, but they deserve to be called mediocre. "It's Electron" is not an excuse.
tylercrompton 3y ago
What exactly makes Electron better for speed than say popular cross-platform GUI library X?
- friendzis 3y ago
  Webviews are built on weakly, dynamically typed languages, which naturally have development speed advantage over statically typed languages in the happy path. On top of that you have multitude of frameworks even more optimized for the happy path. It is much faster to create an MVP of a GUI with web technologies.
  - tomkarho 3y ago
    Also the same GUI code translates (kind of) to more platforms easier than writing it all from scratch. Web, desktop, mobile. Almost one codebase can be used for all three. Could you do the same with say, Java (and maybe soon with .NET)? Maybe. But web has a lower barrier for entry and faster speed of development cycle. Not to mention larger pool of developers available. All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost. And once you get going, it is really hard to pivot your technology stack to something else.
    - friendzis 3y ago
      > Also the same GUI code translates (kind of) to more platforms easier than writing it all from scratch. With an exception of web there are very solid GUI cross-platform (linux, windows, mac) frameworks out there. Qt is even pretty good at targeting native look. > All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost. Yes, web technologies let you build MVPs faster, that's literally in my original comment. However, in order to provide quick MVPs these technologies inherently sacrifice long term maintainability.
      - Capricorn2481 3y ago
        QT is just gonna be untenable for most people. Learning C++ is hard enough, but learning QT is basically a different dialect of C++, and I can't even say it's worth the investment.

by remram 3y ago

I think using Electron is excusable if you are a startup, like you said your time is limited. It's much less acceptable if you are Slack and still ship a slow bloated Electron app 10 years in.

nine_k 3y ago

The truth us that once you have shipped Electron, there's no way back, the cost of switching is too high. This is not specific to Electron, it's a similar effect with every core technology, all the way to COBOL.

dathinab 3y ago
Most electron apps are (mostly but not solely) a bundling of the web-app. So the cost is less the cost of "switching" and more the cost of initially writing a native app. In turn the actual question is how to reuse as much code as possible between the web-app and native apps without it introducing a lot of friction. And one of the few reliable, nicely (developer) usable answers for this is currently electron. For "business logic" there somewhat are already other answers, some languages run on most targets reliable and there is also wasm which often still needs a bit more tooling but has a lot of potential for such use cases (e.g. see Disney which AFIK does have their core business logic compiled to a wasm blob and then "only" provide UI/system glue to bundle it in on all platforms their streaming app runs on). The problem is UI, you really don't want to reimplement UI and the mapping of non HTML/CSS producing UI to a mix of HTML/CSS on some platforms and native components on other often doesn't work grate so it's not surprising people decided to "just go with HTML/CSS everywhere". And if you are already there going with electron isn't "that" much more overhead.
theappsecguy 3y ago
This right here. Something monumental would have to happen for senior leadership to green light a rewrite, because that’s a massive project that will bring in no additional revenue.
- remram 3y ago
  That they are content with mediocrity, I have observed, but they deserve to be called mediocre. "It's Electron" is not an excuse.

tylercrompton 3y ago

What exactly makes Electron better for speed than say popular cross-platform GUI library X?

friendzis 3y ago
Webviews are built on weakly, dynamically typed languages, which naturally have development speed advantage over statically typed languages in the happy path. On top of that you have multitude of frameworks even more optimized for the happy path. It is much faster to create an MVP of a GUI with web technologies.
- tomkarho 3y ago
  Also the same GUI code translates (kind of) to more platforms easier than writing it all from scratch. Web, desktop, mobile. Almost one codebase can be used for all three. Could you do the same with say, Java (and maybe soon with .NET)? Maybe. But web has a lower barrier for entry and faster speed of development cycle. Not to mention larger pool of developers available. All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost. And once you get going, it is really hard to pivot your technology stack to something else.
  - friendzis 3y ago
    > Also the same GUI code translates (kind of) to more platforms easier than writing it all from scratch. With an exception of web there are very solid GUI cross-platform (linux, windows, mac) frameworks out there. Qt is even pretty good at targeting native look. > All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost. Yes, web technologies let you build MVPs faster, that's literally in my original comment. However, in order to provide quick MVPs these technologies inherently sacrifice long term maintainability.
    - Capricorn2481 3y ago
      QT is just gonna be untenable for most people. Learning C++ is hard enough, but learning QT is basically a different dialect of C++, and I can't even say it's worth the investment.