It's pretty clear to me that JavaScript is becoming the de facto standard for UI/UX programming, regardless of platform, and regardless of web vs. native targets. Even GNOME has JavaScript bindings. [0]
The problem is performance... requiring a web browser to draw a UI takes a LOT of CPU and memory, and not all devices have enough power to deliver a smooth experience across all potential workloads.
I worry that every year we keep increasing our processing requirements and bloat without good reason for it.
Why should every Windows release require a faster and faster CPU, and more and more RAM?
The recommended amount of memory for Windows 95 was 8 megabytes, and for Windows 11 it is 8 gigabytes. Why is this not horrifying?
My small Linux system with openbox GUI barely cracks 100MB memory usage in 2025.
What makes the browser slow and inefficient is the fact that it's not a UI framework. It's a system to display text and a couple of images on a 2D plane where every element depends on every other element.
Almost every single interaction and change requires the browser to recalculate the layout of the entire page and to redraw it. It's basically Microsoft Word, with nearly the same behaviors.
And there are no proper ways to prevent that behaviour. No lower and low level control over rendering. Awkward workarounds and hacks that browsers employ to try and minimize re-layouting and redrawing. Great rejoicing when introducing yet more hacks for basic things: https://developer.chrome.com/docs/css-ui/animate-to-height-a... etc.
In none of them text is primary and all other incidental?
> What UI frameworks don't do this?
In which UI framework actions like "set focus on an element" triggers a full page re-layout?
Also, in which UI framework there's even a discussion of "try to not trigger re-paint/re-flow"?
And yes, I know about immediate mode UI where the entire layout is re-calculated every frame. But then they can usually render thousands of elements at 60fps.
> In none of them text is primary and all other incidental?
This is a pretty outdated way of thinking. If we were only speaking about (old) HTML then maybe. But these days HTML and CSS are basically inseparable and go far beyond "text is primary".
> In which UI framework actions like "set focus on an element" triggers a full page re-layout?
I don't see why a browser would need to re-layout for just a focus change. Unless, of course, the CSS changes require a re-layout after the focus has changed (`:focus` selector).
Every UI framework can run into performance issues with layout and/or painting if they're complex enough (or poorly made). There is fundamentally very few differences between HTML+CSS and other UI frameworks.
> But these days HTML and CSS are basically inseparable and go far beyond "text is primary".
That "inseparable" is building on top of a bunch of legacy cruft, hacks and workarounds for a system that is stilm barely suitable to layout some simple text.
Just because CSS is there it doesn't make the browser a UI framework.
> I don't see why a browser would need to re-layout for just a focus change.
Indeed. No one does. And yet you'd be surprised: https://gist.github.com/paulirish/5d52fb081b3570c81e3a (note: unfortunately there's no up-to-date list as some of these issues are fixed in all or some engines, and a bunch of other gotchas are introduced).
> There is fundamentally very few differences between HTML+CSS and other UI frameworks.
Lol. There's almost no other UI framework that struggles with as many trivial performance issues as HTML + CSS [1]. No other UI framework has so many gotchas and issues with even the simplest layouts and animations. No other UI framework has warnings of "you have 800 nodes, it's too big, and will cause issues". No other UI framework has so few ways of telling the framework "delay painting" or "I will take over painting" or "do these paints in batches" or...
> What makes a browser so much more inefficient vs. other UI frameworks?
The fact that each app carries their own copy of the browser engine.
Teams, Chrome, Steam - that's at least three Chromium engine embeds that all take up hundreds of megabytes each. Not to mention Steam is in the background and has no windows visible, and yet it has the Chromium helper processes gobbling up RAM. WTF is this shit.
Life used to be easier in the Windows 98 days with OCX, you just dragged a webview in the VB6 application designer and that was it, and IIRC it was even possible to embed Firefox in the same way for a while...
> The fact that each app carries their own copy of the browser engine.
This has nothing to do with the browser itself. Ideally everything would use the same browser instead of shipping their own. On Windows it's already possible with WebView2 but developers need to choose to go that route. Teams should already be using it.
> Why should every Windows release require a faster and faster CPU, and more and more RAM?
I don't know. But does it? It doesn't seem like you verified that yourself - you're comparing stated recommended specs of Windows to actual usage of Linux.
Have you used other ones? Not a dig, I've primarily used HTML/CSS for UIs and have been playing around with Compose recently and haven't made up my mind what I like more.
GNOME has its own interpreter, kinda how React Native does it for mobile. But performance all boils down to the layout engine. Most native UI components take shortcuts with text which is the most difficult thing to render. And the widget tree is simpler.
And there’s the whole inspector in web browser, meaning that the layout is not done once and forget. There’s various sub components still present for whatever features. Great in the browser, not great for standalone apps.
Same thing with KDE Plasma and its UIs being written in QML, which allows better separation of business logic (written in C++) and graphical interface (QML Javascript).
A choice of tech stack can never be enough to prove anything. It only establishes a lower bound on resource usage, but there is never and upper bound as long as while() and malloc() are available.
