Comment by conradludgate
14 hours ago
How is it a poor choice of words? It might not be "native" UI, but they never claimed as such.
I've always felt that native UI on Linux always looks incredibly ugly and I'd much rather use a nicely styled HTML+CSS layout instead.
In my experience, Electron mostly gets flak for being bloated and slow, it not being native is sometimes a secondary point people add on top.
I've always wanted to build a direct-browser integration that could use HTML+CSS for the layout, but avoids needing a JS runtime. Idk how lightweight servo is but one day I hope I will see my idea come to light
I don't mind the idea of using HTML components and widgets to style desktop applications. CSS and the DOM are widely known and reusing those for desktop apps is probably a good idea.
The problem, as you've pointed out, is that electron apps are bloated and slow. If they became the default and my editor, chat client, terminal, and everything else that I keep open were just thin layers around web applications, I'd rather figure out a way to move things into a browser rather than pull a piece of the browser out to wrap these applications.
There’s a point where it stops scaling in the browser, whether it’s due to scale or poor practices. For example Slack is annoyingly slow to start up and work in my FF, but works OK as an Electron app.
This is pretty much what Tauri solves. It re-uses the systems WebView. So the built apps are tiny (kb to a few mb)
> I've always wanted to build a direct-browser integration that could use HTML+CSS for the layout, but avoids needing a JS runtime. Idk how lightweight servo is but one day I hope I will see my idea come to light
Blitz (https://github.com/DioxusLabs/blitz) is exactly that. It's a new custom browser engine supporting standard HTML/CSS with a native Rust API (and optional integration with Dioxus which is a React-like UI framework in Rust). Baseline binary sizes are around 10mb.
We share a few components with Servo (Stylo the CSS engine (also shared with Firefox), and html5ever the HTML parser), but we've built a bunch ourselves too: notably we have our own layout engine, DOM tree and event handling. Servo is unfortunately tightly coupled with SpiderMonkey, and there is little prospect of removing that dependency in the short term.
That's really nice. It would be really good for game GUIs too where the situation is quite poor and would work well with underlays/overlays/worldspace UIs. That said while binary size may be around 10mb, it still baloons to 500mb at runtime for your TODO list example which is more than some electron apps.
Yeah, the RAM usage is quite high atm. The good news is that it's almost all the rendering layer (WGPU+Vello). So if we can make the renderer more efficient then it's likely we can bring that down. There is also some low hanging fruit in the DOM implementation (but I think that's only actually causing a few 10s of MB of usage).
I would also note that native toolkits (SwiftUI, etc) tend to also use at least ~100mb RAM these days. A lot of that is unavoidable if the app is actually visible, due to modern screen resolutions being so high.
This isn't exactly what you were suggesting, but it made me think of https://hacks.mozilla.org/2026/02/making-webassembly-a-first... since that article is about not needing to go through js to use wasm.