I agree one would have a similar experience as the author when learning Flutter, but it is because on mobile you need to have all these shiny things so it's no wonder that documentation covers it in detail. However, you can perfectly write Flutter apps without animations, transitions and the like.
Or GDScript, Godot’s language, which nobody knows. This is my major barrier to even considering Godot right now. Perhaps once their Kotlin bindings are ready for production…
In my experience Darti s not a problem at all. It's a simple boring javaesque language you can learn relatively quickly if are already proficient in other languages, plus you don't really need to use all features of Dart to create multiplatform apps.
What if more difficult is Flutter itself: you basically need to learn everything from scratch: the architecture, they way to write apps, plus all the library functions you may need. My experience is that this particular aspect took me much longer than learning Dart itself.
I think that’s the present (electron apps have been all the rage for the last few years), but maybe not the future. There’s much effort being put into native-ish GUI programming in recent years such as Godot and Druid.
For an OS most of us would consider useless that's been around for maybe a quarter of the time desktop Linux has been and half the time OSX has 2% is pretty impressive.
As to the pricing, it's not like Desktop Linux doesn't work very well on cheap hardware either. OS popularity comes down to social things like PR (especially with children) and has little to do with merit.
I tried using Godot at work and got turned down. They wouldn't even allow a demo or the "IDE" to be installed. Must use our licensed contract junk from leaches on government dole, because those are what's approved by cybersecurity.
I now have a few more interview questions to ask of future employers and things to look out for during interview tours.
I've seen a lot of applications posted to Godot subreddits, so it's clearly a thing. Godot has some clear shortcomings when it comes to application development, particularly with layout and text rendering, but it's not at all infeasible. I wouldn't do anything important with Godot at this point, though, at least not without C#. GDScript ... is better than GML and Dark Basic but worse than any language you would actually want to use.
I think the important takeaway from reading the article is how crucial editor design is.
Am I weird that I enjoy HTML/CSS for GUI and Layout? With CSS grid of course. Hell I love Godot, but the fact that you can't do something as simple as give a component a max width is so annoying.
Browsers are fantastic cross-platform UI frameworks. Writing a local page is a great way to start prototyping. The problem is that they are very slow and resource-hungry. All those dynamic styling and DOM niceties come with a significant cost.
WASM can help, but the webdev ecosystem encourages developers to use fat JS libraries for most tasks.
Your browser prototype will probably start to chug once it grows to the point that it needs to juggle >1000s of objects. Native apps have the potential to be much more efficient and responsive.
They also tend to work better and more consistently on older/cheaper hardware. I think that every website developer should use a $200 Chromebook for development at least a few weeks out of the year. Most of the world is not using a new M2 macbook, and it's easy to lose sight of that when you spend your time working on new features.
Yeah, Godot has no concept of a flow layout because for games it doesn't matter, all layouts are fixed anyway. That's definitely something the box model of HTML and CSS do better.
My usual solution for that problem is parent the control to a HboxContainer with a set width, buts it by no means ideal. Is there a working proposal to add max width? 4.0 would be a good time to add it.
Making GUIs with game engines is the future not because they are easy to develop with, but because the moment AR and VR become common we already have tools to make 3D interfaces
I don't think 3D interfaces really offer anything of value beyond 2D interfaces. I've never once in my life been using software and thought the GUI would be much better rendered onto the inside of a cube or something.
I did read your post, and I include AR and VR in my assessment. Even in a virtual 3D environment, adding a third dimension to a user interface just makes it less convenient.
But you guys, this software isn't practicing good Design. None of those UI elements provide me with any _satisfaction_. I don't care how efficient it is if it doesn't follow solid Design principles (like massive checkboxes that take seconds to activate).
>It is not made for reusable components, like real GUI toolkits.
The latter needs some explanation. The web way of creating reusable components is through some kind of templating. You are basically just copy pasting a chunk of HTML several times representing your new custom component.
That's not true since HTML allows custom elements.
Godot has those features because game devs often need to make UIs for the game e.g. menus, etc. A decent game engine has to have that kind of functionality. Godot dogfooding is not a good indicator of it's potential as a ui toolkit. It's probably easier for them since they might need specialized components and because they're already familiar with the tools. There's a very strong advantage unique to them.
There are alot of edge cases and broader applications that the right tool for the job like Qt and even electron cover because that's what they're specialized for.
The expectation that godot will cover two major disciplines is possible... but unlikely.
You can't make the argument that people only use Godot for application development because it's what they're familiar with, and then bring up Electron as a countercase. Electron literally only exists because of existing familiarity with web tech.
> … "and web applications and desktop applications are closer than applications and games."
I'm not really sure how that logic follows, as games are also just applications, and although the web was not designed as an application platform, but rather as a hypertext document browsing / delivery platform, yet people managed to wrangle it into performing fairly decently as an application platform, so why not game engines for application development? (I've actually seen more than a few really interesting and useful applications built in Godot and other game engines already, and I'm quite sure more are coming.)
The problem with Qt and Electron is that there is no GUI editor worth its salt right now.
C#+WPF/UWP had Expression Blend since the mid 2000s and it's only been getting worse ever since (and MS said they have no interest in bringing MAUI support to Blend which is probably their biggest foot-gun yet).
Godot has the same sweet features that Blend had but in a modern platform and with cross-platform export, yes it has many many rough edges, but it's been getting visibly better year after year and it shows no sign of stopping.
Anyone who thinks building UIs in Electron today is peak developer UX should just check out what it was like to build on WPF in 2009. They had all the shiny of today plus sane ways to do things eg. keyframe animations with custom easing etc without having to resort to insane workaround like importing them from After Effect with custom libraries.
And yes I know about Qt Design Studio, but my experience with it was AWFUL, from being an absolute minefield in the installation experience due to how Qt tries to upsell you on their commercial offering, to having a UI flow that looks like Blend if you took out most of its features out, to having to deal with QML (which honestly feels like a downgrade coming from XAML) and then you have to tie everything with C++?
It wasn't appealing back then and honestly it still feels like an alpha today.
Inasmuch as desktop applications continue to exist, the future is Electron. The only applications for which there is still demand for traditional GUI apps are military and medical device applications.
Electron is literally write once, run anywhere. It's leaps and bounds beyond anything else in this regard. RAM is cheap, and a few hundred megabytes per installation are a small price to pay for increased productivity and accelerated time to market.
Inasmuch as desktop applications continue to exist, the future is Electron. The only applications for which there is still demand for traditional GUI apps are military and medical device applications.
Oddly specific, and definitely authoritative-sounding. You might be correct but it's the sort of wording that demands evidence in support to differentiate it from pure partisanism.
Game engines have a lot of nice tech and maybe one will get popular for apps one day. The major issue I see is that they're simply tuned for a different UX. They're usually very power hungry (both amps and CPU cycles) and designed to push as many pixels as possible.
It's the exact opposite of the modern view layouts that try to cache view images to reduce the draw work.
I really appreciate how Godot is the only one of the 3D engines that not only offers good 2D support as well (like say Unity) but really treats 2D as a first class citizen. I also REALLY appreciate how it's the only one that has decent built-in support for vector drawing.
That said, so does Canvas, and HTML & CSS are a tried and true portable powerhouse UI combo, and JS/TS are infinitely more relevant than GDScript, so I am camp Electron. Especially now that web 3D is also better than it's ever been. I would rather see more work to make Electron gamedev-friendly than work to make Godot appdev-friendly
I personally prefer not designing my gui but coding it.
I met a guy who said he wanted to write whatever documentation, essentially a gui in Godot and I was like, why not use the proper tool for the job.
Well he said he's familiar with Godot so he'd write it in Godot.
And now this.
I was learning about Android development, jetpack compose, the new thing where you essentially write components in code, I prefer it over the old way, gui design with Android Studio in xml files. I guess I can get used to both but would prefer jetpack compose because it's so similar to "the web wayTM".
I'm guessing if you're used to graphical layout and design you'd disagree so TL;DR it isn't for me, but I've had Godot on the list of things to get into or at least try to scratch the surface and create a test project with it.
I'm looking at moving my desktop application(s) from Microsoft WinForms to Godot, but its worrying that no one else is doing it yet. It certainly seems appealing, especially compared to the other options, but its not at all clear what the limitations and risks are without investing a lot of time/money into it.
Because none of us knows Dart, nor are any contractors likely to know it. Also, based on research I did before starting a cross-platform project, you still end up writing a lot of native code on each platform when using Dart. At that point, you might as well just write native apps.
62 comments
[ 4.8 ms ] story [ 133 ms ] threadGodot is changing their plugin system in a future version, which hopefully will make language support much easier.
[0].https://github.com/Vivraan/godot-lang-support
What if more difficult is Flutter itself: you basically need to learn everything from scratch: the architecture, they way to write apps, plus all the library functions you may need. My experience is that this particular aspect took me much longer than learning Dart itself.
As to the pricing, it's not like Desktop Linux doesn't work very well on cheap hardware either. OS popularity comes down to social things like PR (especially with children) and has little to do with merit.
It's almost as if readers of HackerNews aren't the target audience of ChromeOS.
> As to the pricing, it's not like Desktop Linux doesn't work very well on cheap hardware either.
It's almost as if potential Linux users aren't the target audience of ChromeOS.
Godot can export to web.
https://docs.godotengine.org/en/stable/tutorials/export/expo...
I tried using Godot at work and got turned down. They wouldn't even allow a demo or the "IDE" to be installed. Must use our licensed contract junk from leaches on government dole, because those are what's approved by cybersecurity.
I now have a few more interview questions to ask of future employers and things to look out for during interview tours.
You might want to give that a look :)
I think the important takeaway from reading the article is how crucial editor design is.
WASM can help, but the webdev ecosystem encourages developers to use fat JS libraries for most tasks.
Your browser prototype will probably start to chug once it grows to the point that it needs to juggle >1000s of objects. Native apps have the potential to be much more efficient and responsive.
They also tend to work better and more consistently on older/cheaper hardware. I think that every website developer should use a $200 Chromebook for development at least a few weeks out of the year. Most of the world is not using a new M2 macbook, and it's easy to lose sight of that when you spend your time working on new features.
[1] https://coherent-labs.com/products/coherent-gameface/
/s
That's not true since HTML allows custom elements.
Godot has those features because game devs often need to make UIs for the game e.g. menus, etc. A decent game engine has to have that kind of functionality. Godot dogfooding is not a good indicator of it's potential as a ui toolkit. It's probably easier for them since they might need specialized components and because they're already familiar with the tools. There's a very strong advantage unique to them.
There are alot of edge cases and broader applications that the right tool for the job like Qt and even electron cover because that's what they're specialized for.
The expectation that godot will cover two major disciplines is possible... but unlikely.
I'm not really sure how that logic follows, as games are also just applications, and although the web was not designed as an application platform, but rather as a hypertext document browsing / delivery platform, yet people managed to wrangle it into performing fairly decently as an application platform, so why not game engines for application development? (I've actually seen more than a few really interesting and useful applications built in Godot and other game engines already, and I'm quite sure more are coming.)
C#+WPF/UWP had Expression Blend since the mid 2000s and it's only been getting worse ever since (and MS said they have no interest in bringing MAUI support to Blend which is probably their biggest foot-gun yet).
Godot has the same sweet features that Blend had but in a modern platform and with cross-platform export, yes it has many many rough edges, but it's been getting visibly better year after year and it shows no sign of stopping.
Anyone who thinks building UIs in Electron today is peak developer UX should just check out what it was like to build on WPF in 2009. They had all the shiny of today plus sane ways to do things eg. keyframe animations with custom easing etc without having to resort to insane workaround like importing them from After Effect with custom libraries.
And yes I know about Qt Design Studio, but my experience with it was AWFUL, from being an absolute minefield in the installation experience due to how Qt tries to upsell you on their commercial offering, to having a UI flow that looks like Blend if you took out most of its features out, to having to deal with QML (which honestly feels like a downgrade coming from XAML) and then you have to tie everything with C++? It wasn't appealing back then and honestly it still feels like an alpha today.
I disagree. I think it's just a matter of time. I think Godot isn't ready yet, but will be soon. Just got to wait a little longer.
Inasmuch as desktop applications continue to exist, the future is Electron. The only applications for which there is still demand for traditional GUI apps are military and medical device applications.
Electron is literally write once, run anywhere. It's leaps and bounds beyond anything else in this regard. RAM is cheap, and a few hundred megabytes per installation are a small price to pay for increased productivity and accelerated time to market.
Oddly specific, and definitely authoritative-sounding. You might be correct but it's the sort of wording that demands evidence in support to differentiate it from pure partisanism.
It's the exact opposite of the modern view layouts that try to cache view images to reduce the draw work.
That said, so does Canvas, and HTML & CSS are a tried and true portable powerhouse UI combo, and JS/TS are infinitely more relevant than GDScript, so I am camp Electron. Especially now that web 3D is also better than it's ever been. I would rather see more work to make Electron gamedev-friendly than work to make Godot appdev-friendly
I met a guy who said he wanted to write whatever documentation, essentially a gui in Godot and I was like, why not use the proper tool for the job. Well he said he's familiar with Godot so he'd write it in Godot.
And now this.
I was learning about Android development, jetpack compose, the new thing where you essentially write components in code, I prefer it over the old way, gui design with Android Studio in xml files. I guess I can get used to both but would prefer jetpack compose because it's so similar to "the web wayTM".
I'm guessing if you're used to graphical layout and design you'd disagree so TL;DR it isn't for me, but I've had Godot on the list of things to get into or at least try to scratch the surface and create a test project with it.
We need desktop and mobile, making Qt/QML our only apparent practical choice.
BTW, we built a desktop app in QML and the GUI performs great. The resizing is smooth and elegant.
Why not Flutter?