
Making Advanced GUI Applications with Godot - artemisart
https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b
======
miki123211
If you want to use this in a business, either for an internal tool or for an
application you sell, this is a horrible idea.

Godot doesn't display native widgets, so it has no support for accessibility,
for example to screen readers and blind users. Some people think blind people
bring too little profit to care, but this is wrong for one single reason.
There are some laws mandating accessibility, and more laws are being passed,
for example in the EU. Even if you don't really focus on accessibility at this
point, you always want to keep your options open, in case the law forces you
to. If you choose Electron, WX or even QT, some minor tweaks will usually be
enough to make it right. If you choose Godot, you will need to rewrite the
whole thing from the ground, which might kill your business, or risk fines and
litigation, which might also kill your business. This is even true about
internal tools, as there are laws mandating accessibility of the tools used at
the workplace, and you never know when a blind person gets hired for a job
they theoretically should be able to perform.

This might sound very harsh, but it's important to get this right early, as
one bad decision here is usually irreversible. Of course, this applies not
just to Godot, but to any GUI tool which doesn't implement accessibility
properly (including those that theoretically work on the web, but use canvas
instead of DOM rendering).

~~~
gridlockd
Are you speaking out of professional experience? Do you _know_ of cases where
not implementing accessibility really did become a big financial hazard?

Imagine the headline "company goes bust due to regulatory violations after
hiring blind person". That would basically be sending the message "never hire
a blind person", because no company can ever be sure to be in compliance.

~~~
shripadk
You don't need to hire a blind person to be compliant with regulations. What
if you are building consumer facing products? Can you pick who your consumer
will be? What stops a blind person from using your product? And what if the
user is suffering from another physical disability which doesn't let the user
operate a keyboard/mouse? What if the employee were a medically fit person but
met with an unfortunate accident and lost his/her eyesight/limb and have to
now continue job after recovery? How can s/he continue their job? Will you
fire the person? You never hired a physically challenged person but s/he can
always become physically challenged due to some accident later.

> Do you know of cases where not implementing accessibility really did become
> a big financial hazard?

"Jason Camacho, a blind resident of Brooklyn, N.Y., is suing 50 colleges over
the accessibility of their websites.

The 50 lawsuits, filed in November, say the colleges are in violation of the
Americans With Disabilities Act, as their websites are not accessible to
people with disabilities. Camacho uses a screen reader and said he experienced
barriers when trying to access the colleges' websites."

Source: [https://www.insidehighered.com/news/2018/12/10/fifty-
college...](https://www.insidehighered.com/news/2018/12/10/fifty-colleges-
sued-barrage-ada-lawsuits-over-web-accessibility)

~~~
gridlockd
> What if...

What if tomorrow some change of parameters makes my business impossible? I'll
go out of business. That's always an option.

Dealing with _every possible risk_ ahead of time generally isn't an option.

> "Jason Camacho, a blind resident of Brooklyn, N.Y., is suing 50 colleges
> over the accessibility of their websites.

This is referring to public websites, which arguably are covered by the ADA.

I'm looking more of a story like "We wrote all our software without regards to
accessibility. Then we got sued. It bankrupted us."

If this was a real problem for software in general, why is there no cottage
industry of shady lawyers using people with disabilities to sue software
vendors in particular? There's obviously lots of software that is not
accessible, or not accessible enough.

~~~
shripadk
> What if tomorrow some change of parameters makes my business impossible?
> I'll go out of business. That's always an option.

Yes and no one can sue you for going out of business. But you can be sued for
violating a law while your business is in operation.

> Dealing with every possible risk ahead of time generally isn't an option.

No you need not if you use standard software development tools that do it for
you. You would need to worry about it if you plan to implement everything on
your own.

> If this was a real problem for software in general, why is there no cottage
> industry of shady lawyers using people with disabilities to sue software
> vendors in particular? There's obviously lots of software that is not
> accessible, or not accessible enough.

When there is a clear law that states that you have to make your software
accessible you have no choice but to implement accessibility. For personal use
you need not. For open source projects, the implementation rests on the
shoulders of those using the project for end-user facing software. You can get
away with it for a while, just like you can get away with using pirated
software. But then law will catch up anyways. Just because there is no
precedent set doesn't mean that it is legally allowed. Would you want to be
the first test case? A scapegoat? I bet not!

As far as why there are no cottage industry of shady lawyers: Maybe those
shady lawyers have bigger fish to catch. Maybe there isn't much awareness
about it in the legal circles. Could be variety of reasons why.

~~~
gridlockd
> No you need not if you use standard software development tools that do it
> for you.

The belief that you just need to use "standard toolkits" and accessibility
"just works" is wrong.

> When there is a clear law that states that you have to make your software
> accessible you have no choice but to implement accessibility.

There is no law that mandates implementing accessibility for all commercial
software.

> As far as why there are no cottage industry of shady lawyers: Maybe those
> shady lawyers have bigger fish to catch. Maybe there isn't much awareness
> about it in the legal circles. Could be variety of reasons why.

...or maybe the law doesn't actually say what you think it says.

~~~
shripadk
> The belief that you just need to use "standard toolkits" and accessibility
> "just works" is wrong.

Toolkits provide you the tools to do accessibility right. Toolkits don't do
your accessibility for you. That is the biggest difference. You just
misunderstood what I said.

> There is no law that mandates implementing accessibility for all commercial
> software.

Wrong! It applies to all software. Period.

"The Department of Justice (DOJ) published the Americans with Disabilities Act
(ADA) Standards for Accessible Design in September 2010. These standards state
that all electronic and information technology must be accessible to people
with disabilities.

The ADA differs from Section 508 regulations, which are an amendment to the
Rehabilitation Act of 1973 and apply to all information technology, including
computer hardware, software and documentation."

In fact, the DOJ clarifies it further that accessibility is paramount and that
even though the regulatory process isn't complete on paper doesn't mean that
the software should remain inaccessible in the meantime.

'"The Department is currently developing regulations specifically addressing
the accessibility of goods and services offered via the web by entities
covered by the ADA. The fact that the regulatory process is not yet complete
in no way indicates that web services are not already covered by title III."'

Source: [https://www.interactiveaccessibility.com/services/ada-
compli...](https://www.interactiveaccessibility.com/services/ada-compliance)

> ...or maybe the law doesn't actually say what you think it says.

It does. Read it.

------
Shared404
I did an Ask HN [1] about this topic a little while ago.

Most relevant comment [2], from gunibert is here:

The problem in a framework like GoDot is, that it is meant for Games. A game
renders screens in 30/60 fps. A Desktop application like a Gtk application
does exactly nothing if you dont interact with the application. If you click a
button only the button gets re-rendered. This is more efficient then using
something like a game engine which has no concept about damaged regions and so
on.

Also, people like to have something like "native" look and feel. This would be
possible with Java-SWT as it abstracts away the toolkit. This is possible but
in the case of SWT it is just broken (think about margins, text, scroll
behaviour).

The other option is to use electron as it is just plain simple, works even in
the web (you can basically make a webapp and repackage that as an electron
app)

Or you package a toolkit with your application and avoid native libraries.
This happens in the world of Qt for example. Gtk is cross-platform too but not
statically linkable.

[1]
[https://news.ycombinator.com/item?id=23580213](https://news.ycombinator.com/item?id=23580213)
[2]
[https://news.ycombinator.com/item?id=23584258](https://news.ycombinator.com/item?id=23584258)

~~~
m3at
As mentioned in the article Godot has a low processor usage mode:

> If true, the engine optimizes for low processor usage by only refreshing the
> screen if needed

[https://docs.godotengine.org/en/stable/classes/class_os.html...](https://docs.godotengine.org/en/stable/classes/class_os.html?#class-
os-property-low-processor-usage-mode)

~~~
ladberg
Why would any engine re-render if it's not needed? It will still have benefits
even on desktops.

~~~
mrec
I think mostly because having scads of clever conditionals all over the place
_greatly_ increases the risk of subtle and hard-to-reproduce bugs. From a 2007
Carmack email [1] :

> _The way we have traditionally measured performance and optimized our games
> encouraged a lot of conditional operations -- recognizing that a particular
> operation doesn 't need to be done in some subset of the operating states,
> and skipping it. This gives better demo timing numbers, but a huge amount of
> bugs are generated because skipping the expensive operation also usually
> skips some other state updating that turns out to be needed elsewhere._

> _We definitely still have tasks that are performance intensive enough to
> need optimization, but the style gets applied as a matter of course in many
> cases where a performance benefit is negligible, but we still eat the bugs.
> Now that we are firmly decided on a 60hz game, worst case performance is
> more important than average case performance, so highly variable performance
> should be looked down on even more._

There was fascinating breakdown [2] of a single GTA V frame about five years
back. It was a real eye-opener for me - whole full-screen rendering passes for
things like water reflection and refraction when there isn't even any water
visible in the scene.

[1] [http://number-
none.com/blow/john_carmack_on_inlined_code.htm...](http://number-
none.com/blow/john_carmack_on_inlined_code.html)

[2] [http://www.adriancourreges.com/blog/2015/11/02/gta-v-
graphic...](http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-
study/)

~~~
z3t4
Also, modern processors might run the code anyway and trow away the path not
taken. Its better to optimize by generating a function that does not have
branches.

~~~
mrec
I don't think that applies to conditional rendering, does it? You can't
speculatively execute a graphics API command buffer submission and then dash
after it shouting "wait, come back, I didn't mean it". Same with any kind of
I/O, I'd think.

~~~
z3t4
You are correct. But the same strategy can be used for optimization. Eg. get
rid of the whole if block, and preferably dependencies to make it pure so that
it can be further optimized by caching the output. Although cpu can be faster
then cache so always measure.

------
kodablah
QtWidgets works really hard to try and remain native (both by reusing the
platform window pointers, and mimicking style and functionality). That for me
is worth it. While the article constantly complains about dev tooling size, a
reasonable complaint, my DLLs I ship w/ my Qt program are just 20MB (so I'd
suspect a similar size increase to a single binary were I to statically link).
If I didn't care about native look and feel I might have gone GTK3 (absent
from the comparison here).

Having said that, the other issues concerning Qt may be valid, but for a code-
only set of widgets, they work for me. For these kinds of comparisons to have
value, you have to list the pros and cons of all things, not just the pros of
what you like and cons of what you don't.

~~~
userbinator
It's odd to see the "just 20MB" phrasing. I guess even native applications
have expanded to the point where 20MB seems small, but in absolute terms I
still consider that quite large --- to put things into perspective, _a full
installation of Windows 3.11_ , the OS with all of its included applications,
is less than 20MB.

I wonder if, in another 20 years, we may see people speaking of "just 20GB"...

~~~
watermelon0
I think this is in comparison with 200M+ Electron executable, which is
nowadays bundled with almost every 'native' app.

Do you want to flash image to USB drive? There is Electron app (balenaEtcher)
for that.

Do you want to control your mouse/keyboard? There is Electron app for that
(Logitech GHub), which also includes many Qt libraries.

Do you want a terminal emulator? There is an Electron based app for that.

...

~~~
stu2b50
It's unfortunate that traditional desktop GUI frameworks are such an abysmal
developer experience that everything from FOSS made by 1 person in their spare
time to the cornerstone of multi-billion dollar companies choose to embed a
web browser into their desktop app instead.

Qt is the best I've seen, but it has the normal c++ FUD plus the infamous
licensing FUD.

And honestly, I'll have to admit that how react models GUIs is a really
attractive.

~~~
einpoklum
> Qt is the best I've seen, but it has the normal c++ FUD

Not sure what you mean exactly; C++ is complex, but why the fear and doubt?

Also - Qt is based on veeery old C++ - a 22-year-old standard. The language
has changed significantly since then, while Qt's fundamental design (in terms
of programming) - not really, or not much. So, Qt is not "normal C++" these
days.

~~~
bmn__
Simply add
[https://github.com/woboq/verdigris](https://github.com/woboq/verdigris) so
you can use C++ ≥ 14.

~~~
slavik81
The moc is not the issue. The biggest design problem with Qt is that it
predates move semantics. That history affects the design of almost every
class.

It feels like a beautiful old walking path that detours around a wall that's
long since been torn out. It's still fine... but... it's not how you'd design
it if you were to start from scratch.

------
coppolaemilio
I did a lot of tutorials on my YouTube channel on how to start making GUI
applications with Godot. The visual scripting is really bad for now, so I
would stick with GDScript (a Python like language) or C#. It is really a great
piece of software to make something quick for non-technical people. I really
recommend anyone to explore and play with it a bit and I'm sure you'll find a
use for this amazing engine.

~~~
mhh__
> visual scripting is really bad for now

Are there any visual scripting languages that aren't terrible? The system in
unreal works but every time I use it I find myself wanting a text editor (I
have spent years learning to program well, be that C++ or shaders, just let me
do that!).

~~~
pierrec
If it's general purpose, then I agree that visual languages always seem to be
an annoyance. If it's domain-specific, that's another story, since many
domains are all about connecting blocks together. The most common use case is
audio/video signal processing, where it works well if you're working above a
certain level of abstraction.

~~~
throwaway43234
Indeed, I've had mostly positive experiences with Isadora in the audio/video
signal processing visual scripting space.

------
jayd16
No mention of overdraw, pixel perfect rendering, layout performance, power
consumption, view recycling/scrolling, or render caching (caching the
composition result).

Does Godot handle this stuff well? I have no idea. I wish the post did a
better deep dive. I know Unity doesn't compare well to the native APIs in
these regards.

------
yoz-y
In part criticizing SwiftUI:

> While you get a GUI inspector panel for your GUI components you are still
> forced to largely write the GUI in code.

Well yes. The time and experience (at least for me) has shown that designing
UIs anywhere outside the code will eventually bite you. Not to mention that
from the very moment a second person joins your team you can practically throw
your version control system out of the window for UI files. Thanks but no
thanks.

~~~
wlesieutre
Interface Builder is all fun and games until you have a merge conflict in a
storyboard. It's all XML files so you'd think it'd be solveable, but SwiftUI
makes the code representation so much more readable.

And really, you can drag and drop elements into the live previews and it
writes the code for you, including automatically wrapping existing components
in horizontal/vertical stacks as needed to arrange the layout. So SwiftUI
still has some of the visual UI editor benefits, just broken into smaller
pieces with a much more useful text representation.

~~~
yoz-y
Exactly. For maintainable code I think this is the way forward.

------
nitwit005
I like the concept, but you're starting your development by throwing out the
native UI components, along with all the accessibility features, keyboard
shortcuts, and other features that go with them.

A search about accessibility immediately popped up github issues acknowledging
the difficulty making screen readers work:
[https://github.com/godotengine/godot/issues/29736](https://github.com/godotengine/godot/issues/29736)

There are some applications that mimic all those friendly native behaviors,
but it tends to take a lot of work, and sometimes pushing updates when the OS
behaviors change.

------
emmanueloga_
Yeah no kidding, choosing a GUI framework is pretty difficult task... all of
them suck for a different reason :-).

I'm using cljfx these days and really enjoying it. For desktop apps I think it
is a great choice [1].

The approach described using Godot could work well depending on the type of
app, I think. For instance, this commercial app [2] is built using Kivy [3],
which basically draws the controls using sdl+openGL, so a similar kind of
setup as the Godot one described in the OP.

1: [https://github.com/cljfx/cljfx](https://github.com/cljfx/cljfx)

2: [http://www.yeco.io/](http://www.yeco.io/)

3: [https://kivy.org/#gallery](https://kivy.org/#gallery)

------
juskrey
Several years ago using Unity3d to make an advanced cross platform (half
business half industrial) GUI was an excellent experience and result. So yes,
I readily believe modern game engines are good for cross platform GUIs and may
conquer a niche here.

------
greggman3
This is such a bad idea. Try adding a line editor. Now try typing anything
that is not ASCII or an emoji. Suddenly you'l see why you generally do not
want to use a game engine for a tools.

Even the Godot editor itself is not non-English friendly. It's got a horrible
experience for any language that uses an IME. If you try to insert an emoji on
Mac the IME won't even appear.

~~~
jfkebwjsbx
Assuming that is true, it is an oversight. There is no actual technical
limitation.

I am confident if Godot sees usage as a GUI/app framework, they will take care
of that.

~~~
jariel
Surprisingly, they won't.

Text input and manipulation is so incredibly ugly and hard, that basically
nobody cares it enough to to it really well.

Unicode to start is complicated. Then you have things like bidirectional text.

Line breaking is complicated.

There are no accepted practices for a lot of use cases.

Hyperlinks. Embedded content like images.

Copying/inserting html and other formats.

Styling content.

Rendering 100 000 lines of styled content without screwing up user input.

Line-heights. Tabs. Font definitions that are ambiguous an inconsistent (a lot
of font tables today still don't provide enough space for accents on capital
letters, think Swedish - so you have broken looking text or have to 'fake
it'). Screwed up Kerning tables.

No established standard for real pixelation and rendering - zoom in and you'll
see font's can be rendered a variety of ways.

Emojis, fat finger cursor navigation on mobile devcies, input managers.

It's hard to describe how messy it gets because none of it is academic, it's
not some scary-hard algorithm - it's just an incredibly ugly pile of cross-
cutting code with a zillion little bits and pieces of corner cases.

And a big one for gaming engines: they don't render text 'natively'. You
basically have to create textures. Every big of text, it's own texture. How
big is the texture for 100 000 lines of code? Big.

This is actually one are where Qt falls flat. In the 'new and improved' Qt,
they do everything in the GPU, if you try to load 100 000 lines of something
the app will use up 1G of memory and puke. So then you have to magically code
your way around it.

All for what? Why would you want to render text in a _gaming_ engine in the
first place ...

Then you discover that 'apps' and 'games' are really different things, and
they use different tech for good reason. It only gets ugly when they really
have cross paths.

~~~
jfkebwjsbx
Nobody is saying Godot should implement their own text engine. There are
several available ones they can use, or just pick whatever the platform
offers.

> Why would you want to render text in a gaming engine in the first place ...

Just about _every_ game needs text, including Unicode text. Every proper
engine handles it.

~~~
jariel
" just pick whatever the platform offers."

The platform does not offer anything.

"Just about every game needs text, including Unicode text. Every proper engine
handles it"

No, what they do is paste a few characters on screen, handling a more common
subset of Unicode. They don't come close to handling most of the things I
described above.

Not even Qt handles text well - Qt allows you to do some fun 3D things with
text, but not you can't open 100K lines of formatted code like VSCode.

Webkit is just as bad - MS had to invent 'Monaco' a huge layer on top to be
able to manage text properly and it's kind of a hack.

Simply put nobody does it well out of the box.

~~~
jfkebwjsbx
> The platform does not offer anything.

All major platforms offer advanced text rendering support.

How do you think Windows or macOS render their UI?

> what they do is paste a few characters on screen, handling a more common
> subset of Unicode.

 _Some_ games do that, in particular old ones or indies. Most games do actual
text rendering properly.

> you can't open 100K lines of formatted code

You definitely can, but not naively. VS Code doesn't render all the text at
once either and neither does any serious text editor.

~~~
jariel
"All major platforms offer advanced text rendering support."

No, they don't realy.

I think you're missing a few pieces in your understanding of what the platform
does in these contexts

The platform does not support text rendering for Qt and such platforms. They
are rendered 'from scratch'.

Some platforms offer some built in components, but even they are quite
limited.

No platform offers the ability, out of the box, to do for example, a 'coded
editor' with properly highlighted syntax. Not even close.

"Most games do actual text rendering properly."

They are 'rendering text properly' for the extremely limited subset of text
that they put on the screen.

Have you ever used even a basic 'text editor' in a game? No? Because they
don't even do that.

" you can't open 100K lines of formatted code"

"You definitely can, but not naively."

'Natively' means nothing on the context of 'browser'. If you mean to say 'the
browser doesn't do it out of the box' \- then ok, yes, we agree. And why not,
because it's extremely hard?

There are 0 comprehensive text APIs that are built upon gaming or even 3D
engines today. Most of the barely handle basic text formatting. They put a few
lines of text on the screen in a limited number of languages, and that's it.

There are very, very few platforms that offer comprehensive text rendering,
including Qt, GTK, and native platform components - they're basic.

Providing comprehensive text API is not only something that has to be layered
on top of those things - they also have to 'hack' those platforms to work
around inherent bugs and limitations.

------
georgewsinger
Nice post. I look forward also to a future where Godot helps facilitate VR
(office) applications as well.

We have developed SimulaVR
([https://github.com/SimulaVR/Simula](https://github.com/SimulaVR/Simula) \--
a Linux VR Desktop) on top of Godot, and I think there's a lot of potential
for this in Linux.

------
gavinray
Godot is an incredibly good piece of technology, made by fantastic people.

But I'm not sure that I can echo the sentiment here exactly. I took the time
to read the entire article.

This is what it boils down to for me:

IF you are going to build a native desktop app with a drag-and-drop WYSIWYG
editor, I think it's arguably a solid choice over QT or whatever else you
might do it with.

But the latter part of the article focuses on the argument against using web
technologies:

    
    
      > My discussion of Web technologies needs some disclaimers. I have little experience with web technologies, and I am not very fond of web technology. I am an old school GUI toolkit guy, who did his first GUI stuff using the Intuition toolkit on an old Amiga 1000.
    
      There are a couple of really big problems I see however:
    
      2. It was made for web pages not applications. When trying to make a GUI for an application I found that I so often hit on the limitations imposed by the assumption that we are in some scrollable webpage.
    
      3. It is not made for reusable components, like real GUI toolkits.
    

From time to time, I hear this argument about how because web applications are
run on the web, they're somehow fundamentally different from an application
that might run on your phone or desktop natively in terms of appearance or UI
capabilities.

It's all pixels on a screen. Any design asset you can whip up, with whatever
animations and effects, can be rendered identically on a web, or native
mobile/desktop app.

And modern web applications are entirely made of reusable components and the
principles behind them.

I like to think I don't say without some perspective -- some of the first
applications I ever wrote were VB.NET apps in Visual Studio 2007 using Windows
Forms.

But today the idea of saying "An app made with web technologies cannot look or
function quite like a native desktop app, and it lacks reusable components" is
a bit wild.

Can you imagine trying to build <insert omnipresent application>'s desktop
client with a WYSIWYG.

Finally, will conclude the rant here -- author talks about how Godot's 30MB
compressed/70MB uncompressed size is fantastic, but with Tauri you can build
native desktop apps using HTML/JS in 1-2MB.

[https://tauri.studio](https://tauri.studio)

~~~
rudedogg
> It's all pixels on a screen. Any design asset you can whip up, with whatever
> animations and effects, can be rendered identically on a web, or native
> mobile/desktop app.

The issue is that no one bothers to do all the OS integrations you get for
free when you make a native app.

Also, every web app I've used that pretends to be a desktop app has issues
that make it feel off. Using Discord as an example; I have to focus the title
bar before I can use the minimize/maximize window buttons - unlike every
native macOS app. I run into this almost every day.

I'm not denying that web applications are useful, but if you want something
really high quality, native is the only solution in my opinion.

I was hopeful that web applications could offer a really great way to make
cross-platform applications. After trying some frameworks out, and following
the web standards more closely, I'm pretty pessimistic. The complexity of web
browsers is out of control and I don't think they'll ever be comparable to
native apps.

~~~
fauigerzigerk
The funny thing is, I often prefer Web/Electron apps for the simple reason
that zoom always works and it always works the same way. It's hit and miss
with desktop/mobile apps.

------
qw3rty01
This just reads like a godot advertisement...it only has good things to say
about godot and only bad things to say about any other library. It's really
hard to take the article seriously with so much blatant bias. It also seems to
leave out any technical information that a developer using the engine would
want to know, like how well it integrates with existing code, what paradigms
it uses compared to other UI engines, or whether it uses lazy rendering or if
it constantly runs at 60fps, etc.

~~~
CyberDildonics
I made this comment when someone was talking about using GLFW and IMGUI to
make an application with a openGL window and I think it applies here too,
because it is easy to overlook the things that you will eventually need that
are not trivial to add once you go down the road of using tools made for only
very basic UIs.

"I would bet that the easiest thing would be FLTK. You can use system colors
and make an openGL window while having everything else you would expect in a
UI library. Executables with no dependencies start at a few hundred KB and it
is very fast. There is even a single big pdf for documentation and dozens of
examples that show off every widget. FLTK is very underrated these days
because no one is out there marketing it.

GLFW and IMGUI are great libraries, but once you start wanting a program with
various modal and non-modal windows, menus, widget layout, a native look, file
dialogs, fonts, drag and drop, copy and paste, unicode, spreadsheet tables,
physical printing, custom widgets, functions to hide OS specific system stuff
(like stat, directory listing etc.) you might wish you had started with
something made for what you are trying to do. "

~~~
mwcampbell
Unfortunately, FLTK falls short in at least one important way: it doesn't
implement accessibility, e.g. for blind users with screen readers. Godot and
immediate-mode GUIs have the same problem.

If I'm not mistaken, the most lightweight cross-platform UI toolkit that draws
its own widgets (unlike wx or SWT) and implements accessibility is sciter [1].
It's a good thing the antivirus vendors (who seem to be sciter's biggest
customers) want to sell to governments.

[1]: [https://sciter.com/](https://sciter.com/)

~~~
follower
> it doesn't implement accessibility, e.g. for blind users with screen
> readers. Godot [has] the same problem.

Yeah, this is currently a valid criticism--it's an aspect I'm hoping will see
more development attention in the future.

I did recently discover this project which is working on improving the
situation: [https://github.com/lightsoutgames/godot-
accessibility/](https://github.com/lightsoutgames/godot-accessibility/)

------
pxf
MaterialMaker [https://github.com/RodZill4/material-
maker](https://github.com/RodZill4/material-maker) is also made in Godot :)

------
EamonnMR
It's not the world's best WYSWYG editor but it sure is a WYSWYG editor, with
cross platform exports. You can even write your apps in C# if you want.

~~~
krapp
And using C# gives you the added benefit of the rest of the C# ecosystem. You
can use Nuget right in the VS solution file Godot generates to import whatever
you like.

------
pkphilip
I think Lazarus is a much better environment for creating desktop apps which
are small, cross-platform and very fast. The component architecture is much
more advanced than Godot and you have access to a huge number of components.
Extending these components or creating new components is also very easy.

~~~
hoistbypetard
Don't you have to use Pascal for that, though?

I'm sure the tooling is better by now, but I remember being pretty happy not
to need to touch Pascal anymore by the late '90s. The APIs that expected
Pascal conventions were often pretty miserable to use.

~~~
pkphilip
Yes, you do need to use Object / Free Pascal but it is actually quite a nice
language and you can interface with C libraries quite easily

~~~
hoistbypetard
That's good. Converting between pascal and C calling conventions is one part
of the 1980/1990s that I have absolutely zero desire to revisit.

I do recall that some of the Object Pascal class hierarchies that got
developed were quite nice, and I am glad to hear there's more development
continuing that direction.

------
malkia
How would this work on 2 or 3 monitors. Asking this, since any serious content
creator tool end up using windows across monitors, and there you need good
docking support.

Qt has some, but not all the way there, like Visual Studio has (but there are
some good alternatives for Qt).

The other two pain points (for DCC): \- HDR support (again across monitors) \-
Hi-DPI support (and again across monitors)

Once you start hitting issues above (among many small others), you realize how
much there is to add (wacom tablet support? What next?)

~~~
fish45
I'm not too up to date with Godot news, but I remember that a recent update
(maybe devlog?) added good multi monitor support to the editor, and therefore
the gui toolkit of the engine, since the editor uses the engine.

------
privateSFacct
My question - what happened to microsoft in this space?

The get up and go speed of the super old windows forms approach was fantastic.

Now I'm supposed to use - XAML? UWP? WPF? Do these have great windows form
designer still?

I'm talking speed between download and go with an GUI, a button, a text box
(maybe data bound) etc.

This will age me, but for all the decades of "improvements" this tooling has,
every time I've tried to do the little widget apps thing I used to be able to
do trivially I end up wondering in the woods.

~~~
numlock86
You can do the "WinForms approach" with WPF/XAML still, but once you got the
ideas and concepts behind MVVN, observables, bindings, converters, collection
controls and so on, there is absolutely no turning back and you start to miss
that stuff on WinForms.

~~~
privateSFacct
Is WPF/XAML the right way now to do quick get going windows app development?

~~~
pjmlp
Yes, although the future is WinUI.

[https://microsoft.github.io/microsoft-ui-
xaml/about.html](https://microsoft.github.io/microsoft-ui-xaml/about.html)

------
nslindtner
I'm trying doing this with Unity.

My main issue is the amount of learning necessary for doing "simple" stuff - I
think onboarding of new people will be a challenge.

But I guess time will tell :-)

That said i do enjoy the experience - and some of the "game" features do give
an amazing opportunity to make a nice interface.

I you go this route, do prepare yourself to spend your hours very different -
making an animation takes no time - making a simple tab sequence takes time
:-)

------
FlashBlaze
A great app made using Godot is heavypaint[1]. He explains that in his Blender
everyday talk[2]

[1] [http://www.heavypoly.com/heavypaint](http://www.heavypoly.com/heavypaint)

[2] [https://youtu.be/3jZLTZnIiKU?t=2318](https://youtu.be/3jZLTZnIiKU?t=2318)

~~~
wraptile
Wow, that's really cool! There has been so much new painting software on linux
which makes me really regret selling off my drawing pad.

Here's a good illustration of the program in usage:
[https://www.youtube.com/watch?v=JCY4dfVNq9Q](https://www.youtube.com/watch?v=JCY4dfVNq9Q)

------
rcarmo
I have been playing around with Godot (to help my kids) and, to be honest, I
had largely the same idea. For personal apps that have simple GUIs and have no
formal spec, it might be just the ticket.

(I've been thinking of building an app to do photo triage, and Godot can
certainly load up a bucketload of image assets and render them...)

------
Thaxll
That article is very flawed and also misses a critical point about UI in
general, the reason why Windows feels like Windows in the last 20 years is
because of UI/UX, I used Windows all my life and when I have to open a new app
eventough I never used it before I can naviguate easily, everything makes
sense, I click it does what it's supposed to, pop messages are all the same,
menu looks the same, they all follow the same standard.

It's like driving a car, you can have thousand of different models and yet you
get inside one you can drive it right away. You don't have that kind of
usability if everyone was doing custom GUI running with a game engine.

Same reason why there is a learning curve with UI in games, every games are
different so every UI are also different, it takes time to naviguate properly
in a new game.

Consistance is key.

------
cercatrova
If you're going to do something like this, just use Flutter. It's the same
principle, draw pixels to a screen, but it has a lot of advantages over Godot
for application development, such as accessibility and only rerendering
components when they change.

------
cycomanic
Not familiar with godot, but the GUI reminds me a lot of the blender GUI. I
always wondered if the devs would ever spin out that GUI so that it became a
library, because it always felt blazingly fast compared to e.g. Qt or GTK

~~~
patatapatato
there's this project

[https://github.com/julianeisel/bWidgets](https://github.com/julianeisel/bWidgets)

------
pippy
An underlying tone of this article which most people in this thread have
missed, was the impact of hitting the ground running. Godot quickly gets
something on the screen for someone to build on. Qt is difficult to get
something running. The impact of this makes technical benefits one way or the
other moot. After all, if it works, who cares what technology is better?

I found the hassle of setting up Qt painful, but it didn't scare me away. The
final nail the coffin was their prioritization of Qt Creator over SDK
integration. juggling two IDEs just didn't seem right with an existing
codebase.

~~~
detaro
> _The final nail the coffin was their prioritization of Qt Creator over SDK
> integration. juggling two IDEs just didn 't seem right with an existing
> codebase._

Curious what you mean by that? What did you need Qt Creator for that you
couldn't do otherwise?

------
jv22222
When I came here I was hoping to hear all about godot making minority report
type futuristic GUIs... I was surprised to see it was all about a game engine
making regular every day 2020 UIs!

------
est31
Reminds me how in 2015 I built a web server in Godot. It's very limited, uses
busy polling to listen for new connections, but nothing else was available at
the time (IDK about current Godot). [https://github.com/KOBUGE-Games/godot-
httpd/blob/master/http...](https://github.com/KOBUGE-Games/godot-
httpd/blob/master/httpd.gd)

Where there's a will, there's a way :).

------
fit2rule
I am a big fan of the MOAI toolkit, which is similar to Godot in some ways -
inasmuch as its a game engine toolkit with a Lua front-end - and with which I
have created a number of 'non-game' GUI apps.

It was easily one of the nicest projects I've ever done - no web stuff to deal
with, only MOAI for the core layer, with Hanappe doing the regular work of
providing the GUI controls and abstractions I need - scroller views, buttons,
sliders, etc.

And since that experience, I really yearn for a similar kind of framework on
the better-supported engines out there (MOAI has gotten a bit long in the
tooth in the last few years).

Its really quite a neat feeling to ship an app that uses highly optimised game
code for its lower interface abstractions, with a mid-layer framework on top
of it - which then can be packaged and run on any platform: iOS, Android,
Windows, Linux, MacOS - and looks the same, functions the same, on every
platform.

It does take some courage however. You do have to make a great UI experience
for the end user - if its half-assed or buggy, the whole thing falls down.
But, when it works, it works very well and blows away the whole Web framework.
I really don't like doing apps any other way these days ..

------
TheMagicHorsey
I feel strongly that OP should check out Google's Flutter project. It has many
of the benefits he sees in Godot, with a more general focus rather than the
singular focus on games.

Flutter is very "game-like" in the way it does its UI. It does not use the
native graphics elements. Everything is a component that is rendered by
Flutter's own rendering engine ... AND even the inputs (like touch) are
handled directly in Flutter.

------
pier25
JUCE is another option one could explore for cross platform non-web UI.

It's generally used to make audio apps and plugins, but these require UIs are
after all. I'm fairly certain the first versions of Ableton Live were made
with JUCE, I'm not so sure about the later ones. MaxMSP is also made with
JUCE.

[https://juce.com/](https://juce.com/)

~~~
follower
I looked into JUCE a while back when I was keen to find a good cross-platform
UI solution but was put off by the licensing aspects that seemed more
complex/onerous than even Qt's. YMMV.

------
skratlo
There is so much bullshit and lies about Qt5, I won't bother finishing that
piece of crap:

Erik Engheim: Qt5 is 5GB Actual fact (on arch linux): qt5-base = 64.07 MiB,
qt5-declarative = 24.72 MiB, qt5-quickcontrols2 = 8.56 MiB

> Try having somebody look at a Qt design you made. “Oops sorry you need a 5
> GB download to do that. Oh and btw you need to register an account on a
> website, login and search really hard to find the free version.”

...blatant lie, etc. I won't bother, this guy is nuts. Thanks god for Qt, it
has its quirks but on the desktop it's the best we can do to dev cross-
platform

Erik Engheim: Consider Qt Creator IDE which is quite minimalist, without Qt
which it requires to run, requires over 200 MB Actual fact: 108.03 MiB

~~~
gregschlom
There might be some confusion about Qt the runtime (ie: compiled binaries) and
the Qt SDK for development. Last I remember (admitedly, >8 years ago) the Qt
SDK certainly was a multigigabyte download.

In this case, you need the SDK to develop a UI with Qt, so I think the
author's comparison is fair.

> Consider Qt Creator IDE which is quite minimalist, without Qt which it
> requires to run, requires over 200 MB Actual fact: 108.03 MiB

Probably depends on the platform, I wouldn't be surprised if it was > 200 MB
on OS X. But either way, 100 vs 200, same order of magnitude

~~~
jcelerier
> Probably depends on the platform, I wouldn't be surprised if it was > 200 MB
> on OS X. But either way, 100 vs 200, same order of magnitude

keep in mind that Qt Creator comes with a full clang for its C++ code model
which is already 40-50 megabytes at least ; no decent C++ IDE can skip that.

Regarding the Qt SDK size, what can take gigabytes is installing it for all
android & iOS ... ABIs / versions.

for a fast SDK installation experience, I recommend aqtinstall:

    
    
        $ pip install aqtinstall
        $ time python -m aqt install 5.15.0 linux desktop -O ~/Qt/
        10,43s user 2,14s system 153% cpu 8,213 total
        $ du -csh ~/Qt/5.15.0
        592M 5.15.0
    

(but really, just install e.g. qtbase5-dev on Debian systems has 99.9% of what
is needed for most GUI desktop apps and is ~13 megabytes:
[https://packages.debian.org/sid/qtbase5-dev](https://packages.debian.org/sid/qtbase5-dev)
what takes space is 3D engines, webviews, multimedia apis, etc... but an awful
amount of apps don't need those)

------
keyle
I use Godot on a daily basis, full time. Don't try that at home.

~~~
FraKtus
Why?

------
mark_l_watson
Interesting Article and also conversation here.

I think the future of interactive immersive VR work environments is looking
very strong so using it for GUI apps seems like a good first step.

The author of this article said that he is not a web developer and he has a
pro-application perspective. I think he misses the huge opportunity for web
properties to also render into Virtual Reality.

Out of curiosity I looked at some of the examples in the Oculus Quest SDK.
Basically Android+3D, effective but there is lots of room for improvement.

------
lxe
The section on "Electron, HTML5, CSS and JavaScript" is worth a read. We might
have taken a few wrong turns when it comes to web technologies for
applications.

------
ogig
The author has a point that game engines may be suitable for some
applications. In arquitecture I've used Twinmotion, based on unreal and
Lumion, not sure about the engine on that one, probably unreal too. It may be
obvious in this field, where game like visualization is directly usable, but I
can see other areas where It may work. Anything regarding 3d objects will find
in a game engine state of the art, real time, visualization tools.

------
makecheck
Regarding sizes for Xcode, etc.: While I think they’re bloated downloads, they
include things like dozens of OS simulators, far more than the app/IDE itself.

------
imtringued
I personally got so used to the look of Gnome3 + GTK that I want all my
applications to either use GTK or at least try to attempt to use a similar
theme. The most important factor, as petty as it may sound, is the size of the
control elements. If there is a generic dark theme it's usually okay but if
the standard controls look off it usually doesn't appeal to me.

------
qppo
How well does godot support dynamic/programmatic layout (w.r.t odd aspect
ratios and resizing), localization, and accessibility?

I'd also take issue with the notion that 2D UI frameworks based on game
engines are more performant than their alternatives, because game engines are
optimized for 3D graphics and often struggle with performance once your UI
state becomes reasonable large.

~~~
irq-1
> How well does godot support dynamic/programmatic layout (w.r.t odd aspect
> ratios and resizing),

Very well (it's a game engine)

> localization, and accessibility?

Poorly and not at all. Godot has a student adding PO files:

[https://godotengine.org/article/gsoc-2020-progress-
report-1#...](https://godotengine.org/article/gsoc-2020-progress-
report-1#i18n-improvements)

~~~
follower
I'm not sure that "poorly" is an _entirely_ accurate description of Godot's
localization abilities.

The GSOC project you linked to is about _enhancing_ the existing .po based
feature: "In Godot, we [already] have two ways of importing translation - by
using CSV or PO files."

Here's a blog post about someone's experience doing a translation for a Godot
game: [https://sites.miis.edu/vprolow/2019/12/15/godot-game-
localiz...](https://sites.miis.edu/vprolow/2019/12/15/godot-game-
localization/)

And here's an official tutorial:
[https://docs.godotengine.org/en/stable/tutorials/i18n/intern...](https://docs.godotengine.org/en/stable/tutorials/i18n/internationalizing_games.html)

------
0xdeadbeefbabe
> Game development faces some rather brutal conditions to survive.

Which begs the question how do other areas of development get such easy
conditions?

~~~
danielscrubs
Competition. When I was in high school some 15 years ago many of my classmates
wanted to make games. It was seen as fun and because it was seen as you had to
be smart to do it (parents had no clue) it was in my classmates eyes the
perfect combination.

Fifteen years later and the competition is huge, and the demand in overtime
and the stress followed.

As you start to make even more “programming is fun” classes, what they don’t
see is the other end, and then queue in the FAANG salaries as if that is
indicative of what programmers salaries are.

If I get kids, I’ll tell them to do some soul digging to find out what they
find fun that the majority instead finds boring or something that has a clear
path through a moat.

------
brunoborges
Why is Hacker News not interested in JavaFX at all? Seriously.

~~~
gonzo41
I know right! I watched a scene builder demo and was floored at how easy
things were.

Java went with webapps thinking it'd be easier to manage distribution of the
application if a browser did it for you. Or at least that's how the trends
played out. It kind of works, but the real missed opportunity was all the
client side processing and storage that desktop apps bring to the table.

------
nnq
Anyone interesting in using this to create a code-editor / IDE? I'm dying to
try my hands at a next gen IDE created using a game engine :D

~~~
Alex-----
Check out Glass Editor [https://glasseditor.com/](https://glasseditor.com/)
it's made using an unreleased game engine.

~~~
nnq
...god, my eyes, they hurt, that design, they're bleeding now ...you almost
made me change my mind of whether this would be a good idea :)

(Hint: I'm interested in mostly using this for creating a graphically rich but
minimalistic distraction-free ADHD-friendly experience ...that could also be
usable in VR for even more distraction free coding - I mean since most pro
devs touch type anyway, using a keyboard in VR would just work for us, without
any extra stuff.)

------
ngcc_hk
Need a hello world, then something extra like a form, a solitaire etc to see
how the rabbit goes.

------
jbritton
Does anyone know if Godot can play a live video stream with graphics drawn on
top?

~~~
follower
I _think_ that's possible.

From a quick search there's this:
[https://docs.godotengine.org/en/stable/classes/class_videopl...](https://docs.godotengine.org/en/stable/classes/class_videoplayer.html)

(But that may not be a _live_ stream, necessarily, I guess.)

Also there's this that may be relevant:
[https://docs.godotengine.org/en/stable/classes/class_spatial...](https://docs.godotengine.org/en/stable/classes/class_spatialmaterial.html#class-
spatialmaterial-property-flags-use-shadow-to-opacity)

The latter is documented as:

"""

[...] enables the "shadow to opacity" render mode where lighting modifies the
alpha so shadowed areas are opaque and non-shadowed areas are transparent.
Useful for overlaying shadows onto a camera feed in AR.

"""

------
follower
This is an area I've been actively exploring and think has real potential.

For context, my interest is in:

* Cross-platform support.

* Ease of distribution.

* Ease of construction.

* Platform stability.

* "Licensing"/business issues.

* Accessibility.

In the past I've used Qt w/ C++, Qt w/ Python, web w/Python backend, Python
w/embedded web server and dabbled/looked into things like wx etc. (Oh, and, MS
Access with VBA. :D )

# Platform Native UI

If you want/need Platform Native UI, then Godot is not going to work for you,
period. But neither are most of the other cross-platform options because if
they're only 95% they're not native. My impression is that if you want
platform native _and_ cross-platform then per-platform clients w/shared
backend implementation is pretty much required.

But I also think that platform native (as much as I might like it) is not
necessarily mandatory for successful product, see, e.g. Slack.

I think the key around this is once you've chosen to not _be_ platform native
don't _pretend_ to be platform native. Lean into making the UI tailored for
your application.

And with a game engine there's a whole lot of space to lean into in this
regard--particularly in relation to visualisation.

If you're happy with 95% and don't care about any other aspect then likely Qt
will be a contender for you.

# Ease of Distribution

 _Trying_ to distribute a Qt + Python app as a single binary (within the last
2 years) was how I ended up ditching Qt & using an embedded web server
instead. Despite all the effort & projects trying to make this work, IMO it
still doesn't.

With the small initial Godot download and, a (admittedly half gig) "templates"
download containing the cross-platform app "shells", it's possible to export
to Windows, Mac, Linux, iOS, Android & HTML5. Depending on the platform the
output might be a single binary, a disk image, zip file or binary + support
files but where required traditional packaging tools can also be used.

This is really powerful for me (as both a developer & user) when the platforms
I use (primarily Mac/Linux) are not in the majority & frequently get left out
of releases.

# Ease of Construction

In relation to games, the highest praise I have for Godot is:

* Since I downloaded Godot I've actually made and released games.

I've found the integrated nature of the IDE really supports iterative
development.

Game-making is often a very collaborative effort and because Godot has been
developed (in part) to enable non-developers to not have developers be the
bottle-neck it has visual-based tools & a node/component based architecture
which also can make it a powerful tool for other technical but "non-developer"
people.

# Why not use web technologies?

If your project makes sense as a web site then, make it a web site.

If you want to have a standalone app, you have experience with web
technologies and memory/performance aspects aren't an issue, then, sure build
it on Electron.

But if you can do those things, you can almost certainly use GDScript and gain
the benefit of an integrated IDE and comparatively tiny downloads. (And still
export it to HTML5/WebAssembly--admittedly currently probably with a slower
initial page load time--but it's still an option.)

Additionally, currently Godot runs on older OS (e.g. even back as far as Mac
OS 10.9) than Electron does which keeps getting dragged along to newer
versions by Chrome's requirements which seem to place little emphasis on
supporting older machines/OS.

# Why not Qt?

Ah, Qt, I really want to like you.

If Qt works for you, then use it.

But my experience with Qt has been one of a business that continually seems to
struggle with how to survive; tries to stretch their license compliance in
terms of LGPL & contract with KDE to breaking pointing (because, really, they
wish they didn't have that constraint at all); and, a continual churn of the
underlying technology that results in apps that only support newer & newer
OS/Qt versions even if they don't require anything more than, say, Qt 5.2.

If you're a big corporate and/or if a 95% cross-platform solution is enough,
then I think there's still situations where Qt probably makes sense but in
terms of my niche desktop application development needs it's just too much
hassle.

# Is Godot ready for applications now?

Somewhat. Obviously if your application is a game & the required feature set
matches Godot's, then yes. :)

Based on my own experience using Godot to develop non-game applications tends
to run into some areas of its feature-set which have seen less attention & so
have bugs, lack features and/or lack documentation. (e.g. complex Tree
controls, more sophisticated font rendering (e.g. kerning), very complex
layouts.)

Overall, I think Godot is at a stage where a bunch of people (including OP)
have realised it has potential around non-game application development but
also has some rough edges in that regard that still needs to be improved.

Given the size & focus of the development team up to this point that's not
surprising but I'm excited to see where it may go in future.

# A Note on Accessibility

As mentioned elsewhere in the comments, Godot also unfortunately doesn't
currently have a great accessibility story.

There is at least at least one project that I know of that is working on
improving that: [https://github.com/lightsoutgames/godot-
accessibility/](https://github.com/lightsoutgames/godot-accessibility/)

In addition, Godot's node-based UI system in particular I think lends itself
to retro-fitting better accessibility support more than a different
architecture might.

But if you need your app to be accessible today then Godot probably won't meet
your needs.

# Bonus: Are InfoSec tools a potential niche for Godot-based apps?

I think that's a strong...maybe. :)

To explore the potential of Godot for non-game apps I've been working on
developing a Godot-based hex viewer/editor with a focus on binary/format
reverse-engineering & visualisation motivated in part by a talk where someone
complained that hex editors hadn't done much new for years.

Early in development I realised that InfoSec has a combination of aspects that
might make it particularly well suited for Godot-based apps:

* Many people who are technically skilled but consider themselves "non-developers".

* Has problems to solve that benefit from new forms of visualisation (often with large amounts of data) not met by standard UI.

* Has an affinity for flashy visuals. :)

* Need tools that don't only run in the cloud.

(In InfoSec and want to make this happen? I'm available for hire. ;) )

------
FraKtus
Godot has only OpenGL renderers. Do they plan to add DirectX and Metal?

~~~
follower
For Godot 4.0 the rendering system is being re-worked to use Vulkan.

------
typon
Are there examples of such advanced GUIs? (links to github)

~~~
krapp
Godot's own editor is one obvious example.

Also I saw this Kanban board posted on Reddit earlier:
[https://github.com/alfredbaudisch/Godello](https://github.com/alfredbaudisch/Godello)

Heavypaint, mentioned elsewhere here:
[https://news.ycombinator.com/item?id=24046431](https://news.ycombinator.com/item?id=24046431)

------
atarian
UIs in game engines are pretty different from the look-and-feel you get using
native components or QT. Even with Electron apps, the text fields and buttons
that you start with are at least native to the platform.

~~~
tomtheelder
That's definitely true. OTOH it does seem that fewer and fewer applications
are designed to match the native look-and-feel. A game engine would not be a
good choice if that was a goal of your project, but I don't think most
projects these days are too bothered about that.

------
mrpickels
flutter is the best. period.

------
gameenginz8
I’ve often wondered why more desktop software and data analysis stuff isn’t
written in something like Unreal.

\- optimized across platforms \- optimized net code libs \- modal
collaboration tool: build in blueprints or code (basically web components
before web components) \- advanced visualization \- source control integration
\- the frontend can be backend language agnostic, swap C++ for Rust over time
\- no web assembly needed - heavily polished ergonomics and UX \- custom input
map support is robust, tools can have their own keymap (we aren’t
secretaries!)

The tech world at large is really addicted to the toolkits of the wrong
companies, IMO

Apples “pro” dev tool in Xcode feels like a boring business tool.

Once closed desktop tools are now free for development with a market for
making money now. Godot is just as open as Visual Studio or Firefox, minus the
DOM, JavaScript, etc.

Cloud infra and micro services can still be what they are, all the usual
safety features.

Web/mobile development landscape just feels bloated and insane compared to
building once in Unreal or Godot and outputting to multiple platforms like the
game engines are doing.

~~~
Thaxll
Because the overhead and complexity is huge and useless. Unreal is not
optimized to make GUI application, it's used to make games. Engines don't have
anything useful to make modern app on the desktop.

~~~
gameenginz8
The overhead and complexity of a dozen different IDEs, JS frameworks, 4
browsers, 2 mobile phone platforms, etc etc is less complex?

In a day to day engineering perspective it’s all a mess of abstraction and
indirection anyway?

If we’re going to optimize ONE stack, I’d prefer the one with all the
optimized rendering and input mapping, rather than hacking that all into a
bloated document parser like we’re hacking into a browser?

IMO that is textbook functional fixedness.

~~~
yoz-y
For one applications need familiarity and uniformity. Games don't. For example
games have exactly zero accessibility support, system actually knowing about
what is being rendered is quite useful for it to provide tools like voice
over. What about IME?

> If we’re going to optimize ONE stack

Why would we though? There are different classes of applications and there are
multiple platforms with different conventions. Different use cases require
different tools. Every time something "to rule them all" was tried, multiple
niche tools grown around.

~~~
jfkebwjsbx
> For example games have exactly zero accessibility support, system actually
> knowing about what is being rendered is quite useful for it to provide tools
> like voice over.

Some engines do have accessibility support. Most games don't do accessibility
because it costs money. Same as web apps, by the way. It is not a technical
limitation.

> What about IME?

What about it? It works just fine in any proper engine. There are a lot of
non-Latin-charset speakers in the world...

