5 ms·

> 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

> 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.
      - whstl 3y ago
        Hmmm, I don't know what's this about "actual metric". Is it "sufficient" for simple projects? Sure. Is it as good as Electron in terms of UX, and look/feel? No, it's not even close. Because Electron is doing native rendering. Let me try to explain a different way: - You are saying that native is better. Sure. UX is better, look and feel is better, rendering, accessibility (in most cases), consistency, configurability. - Electron leverages native for a lot of functionality, so it is able to provide good quality. With light styling and semantic tags, it will use a lot of native functionality and will look exactly like the OS. - Game engines can't use native to the extent that Electron does, because the rendering model is fundamentally different (as explained in one of the links), so it must use libraries that don't exactly have the look/feel/quality of native and must simulate it. It doesn't get as far from native than that. > It’s weird that you say “nothing to level of electron and therefore must start from scratch”. But this is true. There is currently nothing close to Electron accessibility in the game world. I'm not talking about base-level accessibility. Check the kind of accessibility provided by browser engines and operating systems, and you'll see it is a lot of work already cut out for developers. Are there libraries? Of course there are, I never disputed that. I actually managed to sneak a few commits and opened a few issues in AccessKit, which is a Rust accessibility library that can be integrated with game engines. But it's still early days compared to what Electron can do. Browser accessibility is actually really great, and it's virtually automatic for developers. I would say that only Apple has as good/simple accessibility as browsers. Check these posts to see the opinion of a Microsoft alumnus that specializes in accessibility: https://news.ycombinator.com/item?id=27338151 https://news.ycombinator.com/item?id=27338151 https://news.ycombinator.com/item?id=24188387 https://news.ycombinator.com/item?id=24188387
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.

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.
    - whstl 3y ago
      Hmmm, I don't know what's this about "actual metric". Is it "sufficient" for simple projects? Sure. Is it as good as Electron in terms of UX, and look/feel? No, it's not even close. Because Electron is doing native rendering. Let me try to explain a different way: - You are saying that native is better. Sure. UX is better, look and feel is better, rendering, accessibility (in most cases), consistency, configurability. - Electron leverages native for a lot of functionality, so it is able to provide good quality. With light styling and semantic tags, it will use a lot of native functionality and will look exactly like the OS. - Game engines can't use native to the extent that Electron does, because the rendering model is fundamentally different (as explained in one of the links), so it must use libraries that don't exactly have the look/feel/quality of native and must simulate it. It doesn't get as far from native than that. > It’s weird that you say “nothing to level of electron and therefore must start from scratch”. But this is true. There is currently nothing close to Electron accessibility in the game world. I'm not talking about base-level accessibility. Check the kind of accessibility provided by browser engines and operating systems, and you'll see it is a lot of work already cut out for developers. Are there libraries? Of course there are, I never disputed that. I actually managed to sneak a few commits and opened a few issues in AccessKit, which is a Rust accessibility library that can be integrated with game engines. But it's still early days compared to what Electron can do. Browser accessibility is actually really great, and it's virtually automatic for developers. I would say that only Apple has as good/simple accessibility as browsers. Check these posts to see the opinion of a Microsoft alumnus that specializes in accessibility: https://news.ycombinator.com/item?id=27338151 https://news.ycombinator.com/item?id=27338151 https://news.ycombinator.com/item?id=24188387 https://news.ycombinator.com/item?id=24188387

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.