3 ms·

> People hate on Electron because they have bad experiences with many Electron apps, but that's not because Electron is inherently terrible, it's because most d

by Gormo 3y ago

> People hate on Electron because they have bad experiences with many Electron apps, but that's not because Electron is inherently terrible, it's because most developers choose Electron because it requires the lowest amount of effort. When you start with that as your single reason for choosing a tech stack, it's unsurprising that optimizing performance never happens. Which amounts to a strong argument in favor of using a tech stack that has superior default performance, and therefore requires less dev effort for optimization.

whstl 3y ago
The problem is that Electron is superior to something like a Godot UI in absolutely everything else. Sure Godot can be ok for trivial apps, but extracting performance out of Electron is also not that difficult for trivial apps in the first place.
- forrestthewoods 3y ago
  > The problem is that Electron is superior to something like a Godot UI in absolutely everything else. Why? What capabilities does Electron provide that Godot doesn’t and can’t? I’m genuinely asking. I don’t know.
  - homarp 3y ago
    Electron allows you can do webdev stuff, so you don't need custom knowledge of anything special. That's the 'superiority'. Doing UI in Godot means either their pythonish custom language or C# (and via GDExtension technology, C and C++ ).
  - whstl 3y ago
    Electron has literally thousands and thousands of very, very complex UI/UX features offered by the OS, plus thousands and thousands of very, very complex UI/UX features offered by a browser engine. Godot has barely nothing compared to that, as it's not an UI toolkit and never tried to be. Even basic things like "rendering text correctly in multiple languages, with emojis, while making it selectable with the mouse or with the keyboard" are super hard to get right, but it's a problem already solved by your OS, in a way that is not only better optimized and has less unseen bugs than a hypothetical bespoke implementation: it also looks and feels more familiar. Then there's the whole accessibility part, which has different native APIs depending on the OS. Some other people have written detailed answers: https://news.ycombinator.com/item?id=38953558 https://news.ycombinator.com/item?id=38953558 https://news.ycombinator.com/item?id=38954455 https://news.ycombinator.com/item?id=38954455 https://news.ycombinator.com/item?id=38954087 https://news.ycombinator.com/item?id=38954087 EDIT: You asked "doesn't and can't". Here's something: there is no can't if you have a turing complete language. But you need a large team to re-do it from scratch, as you're throwing away 40 years of work.
    - forrestthewoods 3y ago
      Video game engines absolutely handle text rendering across a wide range of languages. Not all games involve complex text input, but it’s a sufficiently common need that’d I’d expect a generic engine to support robustly. Accessibility is often language in game technology. That should be better. To be honest my first reaction was negative to this idea. But if your comments and links have done anything it’s convince me that maybe this isn’t a bad idea after all!
      - whstl 3y ago
        I never said it was impossible, I just said that a lot of what's currently possible in game engines is absolutely dogshit compared to even Electron. This is not really an opinion, the features just aren't implemented yet, and UX is not a concern. And I never said video games can't handle text. I said it currently can't do it at the same level as the OS or browser, with all the features. Implementing is of course possible. But unlike something like React Native, or Electron, if you want to keep the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch. The ceiling here is something like Flutter, which cost Google millions of dollars. It even remains to be seen if performance will be even comparable to Electron if someone implement all the missing features. > "Accessibility is often language in game technology. That should be better." There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch.
        forrestthewoods 3y ago
        > And I never said video games can't handle text. I said it can't handle at the same level as the OS or browser. The actual metric is “can they handle text at a sufficient level”. I’m inclined to say yes. > Due to the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch. Oh baby don’t threaten me with a good time. Web browsers are kinda terrible at UX. Native mobile apps are sooo much better than web. > There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch. It’s weird that you say “nothing to level of electron and therefore must start from scratch”. As if there aren’t already libraries and utilities to build off of. At the end of the day electron “just” uses the documented Windows API! It’s not a trivial project. But it’s hardly insurmountable.
  - johnnyanmac 3y ago
    I mean, I've never used Godot, but from my usage of Unreal, Unity, and a couple of proprietary engines: while I hate webdev and the way Javascript evolved, every game engine's UI solution has shown me that the US workflow is still way ahead of games'. Maybe Scaleform or other flash based UI frameworks solved this problem elegantly for games, but it died ahead of my time.
bluesroo 3y ago
I think that it instead amounts to a strong argument that many apps simply wouldn't exist if Electron didn't lower the barrier of entry.
rtpg 3y ago
I think that you might find that Electron has perfectly fine default performance! Think about filling out an <input> field in your browser that doesn't have any weird magic on it. It's basically instant right? The issues come from stuff like autocompletion tricks etc leading to weird lagginess. People get a first version of a thing working, and then it just kind of exists in that state forever.

by Gormo 3y ago

whstl 3y ago

The problem is that Electron is superior to something like a Godot UI in absolutely everything else. Sure Godot can be ok for trivial apps, but extracting performance out of Electron is also not that difficult for trivial apps in the first place.

forrestthewoods 3y ago
> The problem is that Electron is superior to something like a Godot UI in absolutely everything else. Why? What capabilities does Electron provide that Godot doesn’t and can’t? I’m genuinely asking. I don’t know.
- homarp 3y ago
  Electron allows you can do webdev stuff, so you don't need custom knowledge of anything special. That's the 'superiority'. Doing UI in Godot means either their pythonish custom language or C# (and via GDExtension technology, C and C++ ).
- whstl 3y ago
  Electron has literally thousands and thousands of very, very complex UI/UX features offered by the OS, plus thousands and thousands of very, very complex UI/UX features offered by a browser engine. Godot has barely nothing compared to that, as it's not an UI toolkit and never tried to be. Even basic things like "rendering text correctly in multiple languages, with emojis, while making it selectable with the mouse or with the keyboard" are super hard to get right, but it's a problem already solved by your OS, in a way that is not only better optimized and has less unseen bugs than a hypothetical bespoke implementation: it also looks and feels more familiar. Then there's the whole accessibility part, which has different native APIs depending on the OS. Some other people have written detailed answers: https://news.ycombinator.com/item?id=38953558 https://news.ycombinator.com/item?id=38953558 https://news.ycombinator.com/item?id=38954455 https://news.ycombinator.com/item?id=38954455 https://news.ycombinator.com/item?id=38954087 https://news.ycombinator.com/item?id=38954087 EDIT: You asked "doesn't and can't". Here's something: there is no can't if you have a turing complete language. But you need a large team to re-do it from scratch, as you're throwing away 40 years of work.
  - forrestthewoods 3y ago
    Video game engines absolutely handle text rendering across a wide range of languages. Not all games involve complex text input, but it’s a sufficiently common need that’d I’d expect a generic engine to support robustly. Accessibility is often language in game technology. That should be better. To be honest my first reaction was negative to this idea. But if your comments and links have done anything it’s convince me that maybe this isn’t a bad idea after all!
    - whstl 3y ago
      I never said it was impossible, I just said that a lot of what's currently possible in game engines is absolutely dogshit compared to even Electron. This is not really an opinion, the features just aren't implemented yet, and UX is not a concern. And I never said video games can't handle text. I said it currently can't do it at the same level as the OS or browser, with all the features. Implementing is of course possible. But unlike something like React Native, or Electron, if you want to keep the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch. The ceiling here is something like Flutter, which cost Google millions of dollars. It even remains to be seen if performance will be even comparable to Electron if someone implement all the missing features. > "Accessibility is often language in game technology. That should be better." There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch.
      - forrestthewoods 3y ago
        > And I never said video games can't handle text. I said it can't handle at the same level as the OS or browser. The actual metric is “can they handle text at a sufficient level”. I’m inclined to say yes. > Due to the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch. Oh baby don’t threaten me with a good time. Web browsers are kinda terrible at UX. Native mobile apps are sooo much better than web. > There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch. It’s weird that you say “nothing to level of electron and therefore must start from scratch”. As if there aren’t already libraries and utilities to build off of. At the end of the day electron “just” uses the documented Windows API! It’s not a trivial project. But it’s hardly insurmountable.
- johnnyanmac 3y ago
  I mean, I've never used Godot, but from my usage of Unreal, Unity, and a couple of proprietary engines: while I hate webdev and the way Javascript evolved, every game engine's UI solution has shown me that the US workflow is still way ahead of games'. Maybe Scaleform or other flash based UI frameworks solved this problem elegantly for games, but it died ahead of my time.

bluesroo 3y ago

I think that it instead amounts to a strong argument that many apps simply wouldn't exist if Electron didn't lower the barrier of entry.

rtpg 3y ago

I think that you might find that Electron has perfectly fine default performance! Think about filling out an <input> field in your browser that doesn't have any weird magic on it. It's basically instant right? The issues come from stuff like autocompletion tricks etc leading to weird lagginess. People get a first version of a thing working, and then it just kind of exists in that state forever.