6 ms·

Electron is both an amazing enabling technology, and also an artifact of the sad state of affairs for computing platforms. One could imagine a world where stro

by skohan 4y ago

Electron is both an amazing enabling technology, and also an artifact of the sad state of affairs for computing platforms. One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms. Instead we ended up in this bizzare world where if you want to maintain a desktop GUI app, you either need a large team to support multiple platforms, or you need to target minified javascript of all things, and run your software on top of a large, arcane compatibility layer.

dijit 4y ago
I still think of these inefficient things as being great multipliers of potential, even if wasteful. FWIW: I'm probably one of the most "IT Conservative" people on this site, I still believe in sysadmins, dislike systemd, hate electron etc; But there is something to be said about developer productivity: if you can build a prototype in 10 days when it would have taken 10 weeks that can be a huge differentiator between companies; it means you can make 6x more prototypes in the same time window, or work through different iterations of the same idea. That's hugely beneficial. I think if you treat inefficient things this way (I consider Ruby/Python in the same way) then we all benefit, test your ideas then go for gold on a more efficient platform.
- skohan 4y ago
  Yeah I think I am in a similar camp. As a person involved in product development, I love the speed at which web technologies allow us to move. As a computer scientist, I can't help but cringe at the massive amount of collective inefficiency in the current state of computing. But don't get me wrong, I'd rather have the inefficient thing which creates value than nothing at all.
vdnkh 4y ago
> One could imagine a world where strong standards have been established w And yet this didn't happen and Electron did. The "free market" of FOSS development settled on Electron as the winner for cross-platform development.
- skohan 4y ago
  Yeah but that's not the whole picture - it's not just FOSS choosing Electron so much as platform holders being hostile to cross-platform development. For instance, if Apple had actually kept pace with OpenGL standards, and had embraced Vulkan, it would have been fairly straightforward to to build a native GUI framework which works across platforms. Electron won because all the platform owners basically had to embrace the implementation of web standards on their platforms. So they couldn't prevent those tools from being used to deploy local software as well.
  - matthewmacleod 4y ago
    The absence of Vulkan on Apple platforms—something that it’s worth noting was developed after Apple’s Metal equivalent—is in absolutely no way even approaching a barrier to building a “native GUI framework”. There literally are cross-platform native GUI frameworks. Even Electron itself is a third-party implementation of a GUI framework - it doesn’t use the platform’s web tech implementation and bundles its own.
    - skohan 4y ago
      It's just one example of an impediment. If all the major platforms used a consistent standards-based graphics API, you could have one implementation of the drawing layer shared between all platforms. All these little wedges add up.
- toyg 4y ago
  It wasn't FOSS that settled on Electron - it was businesses and corporations. Decisions were taken with an eye to balance sheets and P&L reports; Electron remains the cheapest option of them all, because the supply of moderately-skilled HTML/JS labor is naturally larger than for any other language - all thanks to choices the Netscape Corporation made in 1995, when they needed interactivity in their product and they needed it quick.
  - Drew_ 4y ago
matthewmacleod 4y ago
This is the most sensible take in my mind too. Electron clearly means that we end up with a bunch of apps that would be otherwise unavailable, while at the same time meaning that we have a bunch of embarrassingly bad GUI experiences from companies who can afford to deliver better.
zackmorris 4y ago
I feel that we were well on our way to a cross-platform, web-based future before mobile smartphones arrived around 2007. Also CSS and frameworks like Angular and React really derailed browser progress because they convinced everyone to use recycler views by hand instead of just making tables and the DOM itself more performant and memory-efficient in the browser itself. I may be wrong in the moment, but I base my arguments on trends. Processing power, storage costs and bandwidth are always improving. So human productivity should always take priority over efficiency as time progresses. I'd vote for a real Web 3.0 based on first principles like declarative and data-driven programming, idempotence, immutability, one-shot scripting (perhaps even a Turing-INcomplete DSL) for initial render without side effects (like CSS variables but for HTML), dynamic element loading with something like HTMX, secure server-side includes, distributed databases using Paxos/Raft, even distributed computing with a real Docker that provides an actual secure sandbox and repeatable builds of untrusted secure/private code (maybe with something like homomorphic encryption). I can go on and on about what real (not phantom) tech looks like. And it looks nothing like SPAs. Also I think a lot of people recognize the need for this stuff, so ideas aren't the problem. The problem is, always has been, and always will be funding. In fact, my single greatest disappointment about the modern web is that stuff like advertising and eBay got coopted so there was never a viable way to make enough residual income to live on after the Dot Bomb around 2000/2001. The closest things we have are Uber and donating plasma. So we have a generation of highly-effective programmers spending the most productive years of their lives at a day job making rent, which is why rent increases. Hustling without understanding that the hustle itself is the failure when viewed through this lens. Blah I dunno why I write this obvious stuff anymore. It just ain't never gonna happen. It may as well be impossible. Or I should say, it may take another 20 years to get here, and I just don't think we have that long anymore.
- granshaw 4y ago
  > there was never a viable way to make enough residual income to live on after the Dot Bomb around 2000/2001 Disagree with this. As a dev you have a huge advantage in that you can bootstrap a Saas or similar business cheaply. With the tooling and services available today you can launch quicker than ever before If you can get a semblance of product market fit you can generate enough income to live off of. It’s not easy but it’s definitely possible.
danuker 4y ago
> One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms. Here is a unified binary format that can run on Linux, MacOS, Windows, FreeBSD, OpenBSD, and NetBSD too. They also boot from the BIOS. But it doesn't support GUIs (yet?). https://justine.lol/ape.html https://justine.lol/ape.html
- shp0ngle 4y ago
  That’s more of a hack than anything actually serious.
  - cxr 4y ago
    Category error. The creator certainly seems to be committed to putting this hack towards serious use.
  - cxr 4y ago
    Redbean 2.0: "more than a hobby project" <https://justine.lol/redbean2/ https://justine.lol/redbean2/> <https://news.ycombinator.com/item?id=31764521 https://news.ycombinator.com/item?id=31764521>
llllllllllll9 4y ago
one could imagine many things ...
shp0ngle 4y ago
I am honestly not sure why do people minify javascript in electron apps. It doesn’t really bring any advantage? You need to package whole Chrome with your app, the few MB you save with minification does not matter?? But people here can enlighten me.
- jakear 4y ago
  Minification helps the parser too, try running VS Code from sources and you’ll notice startup is significantly slower.
  - shp0ngle 4y ago
    huh I would think there is no measurable difference there. However I honestly have no idea how much time does JS parser spends on what exactly. Are longer variable names and less tabs that big of a deal? It’s all in memory anyway, no… the lexer or tokenizer or whatever (…I never finished my compiler course…) just goes through that
    - skohan 4y ago
      My best guess is maybe faster hash-map lookups on variable names?
    - jakear 4y ago
      Without nonlinearities like optimization/type checking/etc, the runtime is basically just the time to loop through the bytes. Make the input a quarter the size and you have a quarter the bytes to loop through. College classes will say “oh it’s all O(N) anyways, no big deal”. Industry on the other hand says “why make tens of millions of people wait 4 seconds for this to start when we could make them wait 1 second just as easily”. The product’s source maps are publicly available in a way the debugger understands and the original code is freely accessible so there’s no real downside.
- cellis 4y ago
  Minification also does some tree-shaking, which results in unused branches and libraries being pruned ( and therefore not needing to be loaded into memory ) and a smaller source size. Some constants can be inlined, which leads to faster execution times as there is no need to wait for a variable to be bound as its value is just written directly into the source everywhere it appears.
shp0ngle 4y ago
By the way “write once, run anywhere” was the original promise of Java. Back in the 90s! Before JavaScript was even a thing!!! People wrote Java applets that were supposed to be same everywhere. It even had GUI. Nobody expected that not Java, but _JavaScript_ will be the actual write once-run everywhere.
- bornfreddy 4y ago
  Yes. But in reality it was more "write once, debug everywhere". It was actually quite a nice concept, but the resulting UIs were inevitably clumsy and had that distinctive (ugly to me) look, no matter what the platform promised. If it doesn't look good out of the box, it won't look good later either.
vlunkr 4y ago
Agreed. I know Electron isn't ideal, but as a Linux user, I have a pretty hard time complaining. In the pre-electron world, something like Slack for linux either wouldn't exist, or would be several versions behind other platforms and have some goofy UI that didn't match the rest of your desktop. At least we have it and it works.
- exyi 4y ago
  This so much. I'm not fan of electron apps, but it's 1000x better to accept the chromium memory usage than a Windows VM memory usage. And I think that sharing the code between web and desktop also gives us very usable web apps (at least in case of Slack).
- mixmastamyk 4y ago
  Are you kidding? It’s a chat client that works in a browser. About as Linux friendly as it gets.
  - vlunkr 4y ago
    That's just an example. You want some more? https://www.electronjs.org/apps https://www.electronjs.org/apps
    - digisign 4y ago
      Not a very good one then, and never heard of any of those. The big ones like Slack do run in a browser because the whole point is to access an online service.
      - quixoticelixer- 4y ago
        You haven't heard of Discord or Visual Studio Code?
        deleted 4y ago
        [deleted]
santiagobasulto 4y ago
I'm wondering how viable a for-profit electron replacement (with native support) would be? Like Unity (similar business model), but exclusively thought for apps.
doliveira 4y ago
I'd describe it, together with Docker, as good solutions for problems we shouldn't have anymore
- donatj 4y ago
  Replace "good" with "mostly workable" and I'm on board
  - doliveira 4y ago
    I was trying to be more agreeable but yeah, "mostly workable" is a better description.

by skohan 4y ago

dijit 4y ago

I still think of these inefficient things as being great multipliers of potential, even if wasteful. FWIW: I'm probably one of the most "IT Conservative" people on this site, I still believe in sysadmins, dislike systemd, hate electron etc; But there is something to be said about developer productivity: if you can build a prototype in 10 days when it would have taken 10 weeks that can be a huge differentiator between companies; it means you can make 6x more prototypes in the same time window, or work through different iterations of the same idea. That's hugely beneficial. I think if you treat inefficient things this way (I consider Ruby/Python in the same way) then we all benefit, test your ideas then go for gold on a more efficient platform.

skohan 4y ago
Yeah I think I am in a similar camp. As a person involved in product development, I love the speed at which web technologies allow us to move. As a computer scientist, I can't help but cringe at the massive amount of collective inefficiency in the current state of computing. But don't get me wrong, I'd rather have the inefficient thing which creates value than nothing at all.

vdnkh 4y ago

> One could imagine a world where strong standards have been established w And yet this didn't happen and Electron did. The "free market" of FOSS development settled on Electron as the winner for cross-platform development.

skohan 4y ago
Yeah but that's not the whole picture - it's not just FOSS choosing Electron so much as platform holders being hostile to cross-platform development. For instance, if Apple had actually kept pace with OpenGL standards, and had embraced Vulkan, it would have been fairly straightforward to to build a native GUI framework which works across platforms. Electron won because all the platform owners basically had to embrace the implementation of web standards on their platforms. So they couldn't prevent those tools from being used to deploy local software as well.
- matthewmacleod 4y ago
  The absence of Vulkan on Apple platforms—something that it’s worth noting was developed after Apple’s Metal equivalent—is in absolutely no way even approaching a barrier to building a “native GUI framework”. There literally are cross-platform native GUI frameworks. Even Electron itself is a third-party implementation of a GUI framework - it doesn’t use the platform’s web tech implementation and bundles its own.
  - skohan 4y ago
    It's just one example of an impediment. If all the major platforms used a consistent standards-based graphics API, you could have one implementation of the drawing layer shared between all platforms. All these little wedges add up.
toyg 4y ago
It wasn't FOSS that settled on Electron - it was businesses and corporations. Decisions were taken with an eye to balance sheets and P&L reports; Electron remains the cheapest option of them all, because the supply of moderately-skilled HTML/JS labor is naturally larger than for any other language - all thanks to choices the Netscape Corporation made in 1995, when they needed interactivity in their product and they needed it quick.
- Drew_ 4y ago

matthewmacleod 4y ago

This is the most sensible take in my mind too. Electron clearly means that we end up with a bunch of apps that would be otherwise unavailable, while at the same time meaning that we have a bunch of embarrassingly bad GUI experiences from companies who can afford to deliver better.

zackmorris 4y ago

I feel that we were well on our way to a cross-platform, web-based future before mobile smartphones arrived around 2007. Also CSS and frameworks like Angular and React really derailed browser progress because they convinced everyone to use recycler views by hand instead of just making tables and the DOM itself more performant and memory-efficient in the browser itself. I may be wrong in the moment, but I base my arguments on trends. Processing power, storage costs and bandwidth are always improving. So human productivity should always take priority over efficiency as time progresses. I'd vote for a real Web 3.0 based on first principles like declarative and data-driven programming, idempotence, immutability, one-shot scripting (perhaps even a Turing-INcomplete DSL) for initial render without side effects (like CSS variables but for HTML), dynamic element loading with something like HTMX, secure server-side includes, distributed databases using Paxos/Raft, even distributed computing with a real Docker that provides an actual secure sandbox and repeatable builds of untrusted secure/private code (maybe with something like homomorphic encryption). I can go on and on about what real (not phantom) tech looks like. And it looks nothing like SPAs. Also I think a lot of people recognize the need for this stuff, so ideas aren't the problem. The problem is, always has been, and always will be funding. In fact, my single greatest disappointment about the modern web is that stuff like advertising and eBay got coopted so there was never a viable way to make enough residual income to live on after the Dot Bomb around 2000/2001. The closest things we have are Uber and donating plasma. So we have a generation of highly-effective programmers spending the most productive years of their lives at a day job making rent, which is why rent increases. Hustling without understanding that the hustle itself is the failure when viewed through this lens. Blah I dunno why I write this obvious stuff anymore. It just ain't never gonna happen. It may as well be impossible. Or I should say, it may take another 20 years to get here, and I just don't think we have that long anymore.

granshaw 4y ago
> there was never a viable way to make enough residual income to live on after the Dot Bomb around 2000/2001 Disagree with this. As a dev you have a huge advantage in that you can bootstrap a Saas or similar business cheaply. With the tooling and services available today you can launch quicker than ever before If you can get a semblance of product market fit you can generate enough income to live off of. It’s not easy but it’s definitely possible.

danuker 4y ago

> One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms. Here is a unified binary format that can run on Linux, MacOS, Windows, FreeBSD, OpenBSD, and NetBSD too. They also boot from the BIOS. But it doesn't support GUIs (yet?). https://justine.lol/ape.html https://justine.lol/ape.html

shp0ngle 4y ago
That’s more of a hack than anything actually serious.
- cxr 4y ago
  Category error. The creator certainly seems to be committed to putting this hack towards serious use.
- cxr 4y ago
  Redbean 2.0: "more than a hobby project" <https://justine.lol/redbean2/ https://justine.lol/redbean2/> <https://news.ycombinator.com/item?id=31764521 https://news.ycombinator.com/item?id=31764521>

llllllllllll9 4y ago

one could imagine many things ...

shp0ngle 4y ago

I am honestly not sure why do people minify javascript in electron apps. It doesn’t really bring any advantage? You need to package whole Chrome with your app, the few MB you save with minification does not matter?? But people here can enlighten me.

jakear 4y ago
Minification helps the parser too, try running VS Code from sources and you’ll notice startup is significantly slower.
- shp0ngle 4y ago
  huh I would think there is no measurable difference there. However I honestly have no idea how much time does JS parser spends on what exactly. Are longer variable names and less tabs that big of a deal? It’s all in memory anyway, no… the lexer or tokenizer or whatever (…I never finished my compiler course…) just goes through that
  - skohan 4y ago
    My best guess is maybe faster hash-map lookups on variable names?
  - jakear 4y ago
    Without nonlinearities like optimization/type checking/etc, the runtime is basically just the time to loop through the bytes. Make the input a quarter the size and you have a quarter the bytes to loop through. College classes will say “oh it’s all O(N) anyways, no big deal”. Industry on the other hand says “why make tens of millions of people wait 4 seconds for this to start when we could make them wait 1 second just as easily”. The product’s source maps are publicly available in a way the debugger understands and the original code is freely accessible so there’s no real downside.
cellis 4y ago
Minification also does some tree-shaking, which results in unused branches and libraries being pruned ( and therefore not needing to be loaded into memory ) and a smaller source size. Some constants can be inlined, which leads to faster execution times as there is no need to wait for a variable to be bound as its value is just written directly into the source everywhere it appears.

shp0ngle 4y ago

By the way “write once, run anywhere” was the original promise of Java. Back in the 90s! Before JavaScript was even a thing!!! People wrote Java applets that were supposed to be same everywhere. It even had GUI. Nobody expected that not Java, but _JavaScript_ will be the actual write once-run everywhere.

bornfreddy 4y ago
Yes. But in reality it was more "write once, debug everywhere". It was actually quite a nice concept, but the resulting UIs were inevitably clumsy and had that distinctive (ugly to me) look, no matter what the platform promised. If it doesn't look good out of the box, it won't look good later either.

vlunkr 4y ago

Agreed. I know Electron isn't ideal, but as a Linux user, I have a pretty hard time complaining. In the pre-electron world, something like Slack for linux either wouldn't exist, or would be several versions behind other platforms and have some goofy UI that didn't match the rest of your desktop. At least we have it and it works.

exyi 4y ago
This so much. I'm not fan of electron apps, but it's 1000x better to accept the chromium memory usage than a Windows VM memory usage. And I think that sharing the code between web and desktop also gives us very usable web apps (at least in case of Slack).
mixmastamyk 4y ago
Are you kidding? It’s a chat client that works in a browser. About as Linux friendly as it gets.
- vlunkr 4y ago
  That's just an example. You want some more? https://www.electronjs.org/apps https://www.electronjs.org/apps
  - digisign 4y ago
    Not a very good one then, and never heard of any of those. The big ones like Slack do run in a browser because the whole point is to access an online service.
    - quixoticelixer- 4y ago
      You haven't heard of Discord or Visual Studio Code?
      - deleted 4y ago
        [deleted]

santiagobasulto 4y ago

I'm wondering how viable a for-profit electron replacement (with native support) would be? Like Unity (similar business model), but exclusively thought for apps.

doliveira 4y ago

I'd describe it, together with Docker, as good solutions for problems we shouldn't have anymore

donatj 4y ago
Replace "good" with "mostly workable" and I'm on board
- doliveira 4y ago
  I was trying to be more agreeable but yeah, "mostly workable" is a better description.