Chromium has so much stuff packed into it, its insane. All that utility comes with Electron. And that's a good thing.
If you ever worked with video, for example, you know that having the full power of a modern browser in a desktop app is a game changer. Video playback (not to mention transcoding, which is also possible with modern web and webcodecs) is a complex beast, implementing that yourself is massive undertaking, not to mention in a desktop app that is supposed to work on win/mac/lin. I've built apps with Electron in tens of hours that would otherwise take me tens of days or more (and thats with AI because I'm not a video expert).
when it goes about using webapps as desktop apps, native PWA support should be used, it would - in theory at least - lessen most issues electron apps have but will need extra effort and that's why we can't have nice things (like RAM free for other tasks)
I get what you're trying to say, but Chromium is far from being an OS. What you could say is, Chromium is as complex as an OS, or is replacing the OS in providing functional libraries atop devices (OS-provided application framework, if you will).
1: 24-core CPU and I can’t move my mouse https://news.ycombinator.com/item?id=14733829
2: https://news.ycombinator.com/item?id=14736498
> Just as a data point - Chrome has more code than the linux kernel -
> It's an operating system (pretending to be a browser).
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
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.
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.
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.
Like 25 years ago. Nobody gives a damn since Microsoft stopped giving a damn.
The other thing I find most Mac people appreciate is a shared understanding of hotkeys and if your app goes against the norm, one of the first feature requests will be to add configurable hotkey support.
Unfortunately, Apple has dropped the ball with their newest native apps in regards to UX and it will take years for them to go back and improve things. The new OS this fall is aiming to start that process, but it will still be a band-aid in some respect.
Native UIs change all the time too and not always for the better.
There's aesthetic value to coherence. There's also design, usability value. I have Telegram, Steam and Firefox opened right now and each one of them displays different minimize/maximize/close buttons on the top right. That's not ideal.
As a developer, I'm not sure what's the barrier for entry is apart from Rust then again it's the USP as well.
As a minor bonus, the live-reload is also faster than what frameworks like React do. It truly has subsecond latency, which isn't exactly a game changer but is nice when iterating on visual details of an app.
What DE? I'm on KDE.
Accessibility implementations frequently are more complex than the entire UI drawing bits. Most custom UI toolkits never implement accessibility, even decades after creation.
That hope is misplaced.
The irritating, and unnecessary, pedantry.
Is that a problem? A button with a legible label is a button. The host OS doesn't have to look exactly like the applications it runs.
Windows has like 4 frameworks available on a bare new, latest OS install, just go deep enough in the "settings" or whatever they call it, and you can reach down to winforms. And on top the start menu is a react element!
(And in Linux you have the gtk and the qt world, and everything else)
Do they render different looking buttons?
This upsets HN users but the rest of the world decided that apps looking like windows built ins doesn't matter.
The only examples I can think of are actions that are intentionally not easy to reach. How exactly it's done is platform-specific, but the (mis)feature doesn't come from the platform and can be implemented in other ways on other platforms.
- Apple UIs hide some power user functionality behind obscure hotkeys
- Similar: Shift-Delete to permanently delete (Windows, KDE) - Similar: Shift-right click to "Open With..." (Windows, KDE)
- In desktop apps that FOR SOME REASON try to look more like web apps, the hidden menu bar can be restored with Alt or Alt-M (Firefox, KDE)
One group of people who routinely carry the can for poor product usability and another who by definition care about the Mac platform; entirely what would be expected.
Sorry, are you saying that two random web apps will typically share more UI consistency than two random Windows apps? Because, although I'm not currently familiar with Windows, I would be amazed if that were true.
Wait...
Some speculate that agentic engineering will enable the return of native apps
What resources is actually needed? More often than not it just requires good engineering. You do not have to duplicate everything across platforms.
For your users. Engineering is about designing things for the convenience of the builder, but for the convenience of the user.
That doesn't say anything about the value of whatever UI kit is in place, being shared consistently by apps. A virtue that, apparent from this thread, is no longer universally shared.
Nowadays there isn't even an excuse anymore, just vibe code it away in native frameworks.
Even in a "post-vibe code" era I wouldn't want to create multiple versions of the same app, and none of the "platform-native" GUI toolkits run on everything.
SwiftUI is apple-only, gtk has pretty bad compatibility on non-linux, qt is decent but requires C++ or python, and even so still not much for mobile. Don't even get started on "Windows frameworks", because as I write this sentence they may have left a new one in the ditch.
Flutter may be the closest, but why didn't they go with e.g. Java instead of a new language?
So yeah, if you want a truly universal UI then web is your best bet.
Right. If you want your app to look the same, custom way, ditching what the OS has to offer.
Some developers still believe an operating system has useful UI components and patterns worth adopting. From this thread it's clear that there's plenty who don't. Personally I view that as a regression.
Of course there is value in having "OS-native" buttons, transitions, windows etc. And many parts of GUIs are basically standardized. The problem is all the parts that are not, and have to look the same everywhere.
They don't. No one generates GBs of simulation data and create plots on their phones, and this is what "app" I am working on is doing.
Web is bad everywhere outside of the browser.
You clearly see the issue.
We are not that bad nowadays, it is a skill issue.
There are plenty of ways to have portable applications with native UIs without shipping a browser.
Somehow we managed to do it for decades and without AI writing the code for us.
If you want to ship a browser, I already have one, thus standard Web, with a daemon if it really must be.
Portable frameworks exist, but they are at most native to a single platform.
I don’t. VLC is available everywhere, so your requirement is clearly not a problem. Jetbrains is available on all major desktop OS.
Jetbrains is a better example, using Java with Swing which is not a common choice. As seen from my other comment, I do think this is a good direction, but it ain't any more native than Flutter or for what it's worth an Electron app, none of these are "what the OS provide". FYI Jetbrains has to do quite a few platform-specific tweaks to make them better citizens on each platform.
VLC went with QT (which has done all the hard work) for the UI, and their own libraries for the media playing part. Other software like Emacs and sublime has implemented their own UI libraries. Some just ship libraries and others build UI for them.
The issue with Electron is that it brings a whole jungle and a gorilla holding the single banana that the devs actually need. And the dev flung the whole thing at the users. It's like establishing an iron mine, a steel factory and then pollutes the whole region when building a quick stone bridge would do. Because the only thing you know are suspension bridges.
You can use JS but it doesn't ship a browser engine, it renders with its own lightweight toolkit.
What you suggest is a disadvantage is one of the key advantages of Electron to me. I precisely do not want my things to look different on different OS. I don't have the resources to test my apps on all devices, and knowing that whatever I test on one system looks the same on another is A+.
This is a techie complaint, and that's opting for a charitably nice description.
Have you ever had a job as a tech support? If not, you don’t have anything to say.
People do complain about inconsistent UX. Especially when it does not behave like the platform it’s on.
Knock it off already.
Are you implying that the Windows, Mac, and Linux native desktop user interfaces don't all totally suck??! Or that there wasn't a huge celebration when Alan Dye finally left Apple for Meta? Or that users are clamoring for Jony Ive's infamous shallow superficial visual elegance over affordance and discoverability and usability?
Is it just too confusing for people to use youtube because the buttons don't look and feel exactly like native Mac buttons on the Mac and native Windows buttons on the Windows and whatever the kids are using on Linux desktops these days, therefore nobody uses youtube, and that it will only ever get popular if it just had a native look and feel?
I genuinely wonder who ever want that, and what apps those people use on their PC. Can you imagine, for example, Blender Foundation says that their next goal is to make Blender's UI look more like the host OS?
I have somewhat more experience with QGIS. It has a standard Mac menu bar, but the icons are inelegant and Windows-ish, window layouts are Windows-ish, dialogs don't behave correctly in Mac full screen mode. It could use a MacOS glow-up.
I think Visual Studio Code (native menu bar, native save/open, but a core UI kind of unto itself that is consistent across Mac and Windows) does a better job of balancing cross-platform vs native.
And then there's the approach taken by Adobe and Microsoft Office. These apps do a much better job of adopting native platform appearance and conventions (sometimes at the expense of application consistency across platforms).
As for the common dialogs, I agree with you. There's no better example of why you should stick with common dialogs than the shitshow that is Microsoft Office. The file-save... thing is mind-bogglingly bad. It looks like a hastily-thrown-together debug screen. You have no idea what you're looking at. The fields are primitive, unnecessarily-huge box outlines. There's no treeview to show you where you're working in the filesystem. There's a big list of what, history? Why?
Garbage.
For me, the leading reason to use Electron is the fact that I already have a browser running so why not just use that to render your webpage... Make it a PWA if you want it in its own window.
Seems like I'm part of a shrinking minority (in this thread at least) who believes that web[sites/apps] in a browser, and apps running on the host platform, are different things in terms of UX expectations.
Apparently, NOT! Apple's controversial Liquid Glass UI disrupted their long-standing Human Interface Guidelines by prioritizing cinematic aesthetics (transparency, refractions, and blur) over core tenets like readability, contrast, and content deference. Critics highlight that transparent, light-bending panes frequently clash with underlying wallpapers or videos, causing text and buttons to become illegible. This is a HOT topic in recent WWDCs and amongst UI designers.[1]
[1] https://blog.prototypr.io/why-apples-liquid-glass-design-is-...
A non-native UI has some issues, but also one clear advantage - it is easier to make a cross-system app with the same looks.
On Windows you have 20 different ways to write native apps that all look different.
On Linux you have Qt/GTK and god knows what else.
Only macOS is somewhat consistent although with Liquid Ass it's also getting worse.
Poor choice of words there IMHO.
The reason Electron apps get a lot of flak is because they are everything _but_ a UI toolkit. They consistently miss the mark in adopting UI patterns from their host OS.
Web tech is just web tech. Yes it will allow you to render a button, but even unstyled, the button won't necessarily look native to the OS, and will vary between browsers.