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.
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).
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.
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.
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.
What DE? I'm on KDE.
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.
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.
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.
Native UIs change all the time too and not always for the better.
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+.
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)
This upsets HN users but the rest of the world decided that apps looking like windows built ins doesn't matter.
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...
The irritating, and unnecessary, pedantry.
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.
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?
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?
Yeah, hello desktop.
D:\source\DenoTest>deno desktop main.ts
error: Module not found "file:///D:/source/DenoTest/desktop".
The CLI reference page[0] notes,
> The permissions you grant at compile time are baked into the compiled binary:
I think it would be nice if this could be surfaced to the user somehow, like letting the user know and decide which permissions they want to give access to.
[0]: https://docs.deno.com/runtime/reference/cli/desktop/#runtime...
> Runtime permissions for desktop apps (a permission prompt on every filesystem / network access, i.e. Deno's permission system applied to desktop sandboxing).
WASM you can bundle for Windows, macOS, Linux, Android, iOS and web. Unlike Deno Desktop, it doesn't rely on a browser engine.
Bytecode Alliance do semi-regular streams on Youtube. I think reading (recent) material on WASI (0.3) and the Component Model would be a good start.
Understanding the relationship between a host and a guest is valuable. Learning what wasmtime is and how it works is also illuminating: https://docs.wasmtime.dev
With that said, this is going to eat a lot of Tauri market. Why would I use Tauri now? The 150mb of additional bundle size is just an extra 1 to 10 seconds of download time in most internet connections and you get a reliable rendering engine.
Also, we've had several developer framework startups get acquired -- Astro, Nuxt, UV, Bun, Vite. It doesn't exactly inspire confidence in a software that you want to last and give support for years.
How is it more reliable than Tauri - aren't they both using the system webview?
E.g. Tauri uses WebKitGTK on Linux, which has historically been slow, unstable, and frequently lagging behind the main WebKit project. This is enough of an issue that even Tauri is working on the ability to use CEF instead of the system web view in Tauri apps.
Things are generally fine on recent versions of Windows and macOS. The system web views on these platforms will be evergreen versions of WebKit or Blink. But if you want to support very old versions of Windows or macOS, you might choose to use CEF instead of wrestling with Safari-from-five-years-ago.
I wonder if it supports opening invisible browser windows and doing things like intercepting cookies. In my desktop application I leverage a hidden browser window to manage auth state and use it like a proxy for the rest of the application. Might try to port it to deno desktop.
Sounds like a similar architecture to Tauri, but your business logic is in typescript instead of rust.
https://docs.deno.com/runtime/desktop/comparison/ https://github.com/blackboardsh/electrobun#platform-support
The world is trying to make computers faster and more accessible, more web UI slop isn't going to help that. Dumping Javascript entirely is the first step on that road.
I see it in a different way. The fact that "web UI slop" has managed to make great inroads on the desktop is an indictment of the state of native toolkits. If you think it's a problem that desktop apps are being written with web toolkits, the solution for that isn't to shame (as the term "web UI slop" clearly tries to do), but rather to figure out how to improve the native toolkits.
The opportunity to improve those toolkits was always there, and the ball was dropped.
I don't need to spend 2GB-4GB of RAM just to have a over-glorified IRC clone!
Also, the native toolkits are fine. Windows has two toolkits, the ShellUI/MFC family (which does everything required, although it doesn't always get hidpi on legacy apps correct; it gets integration for blind people and also unicode/multilingual correct, and also works with touch interfaces), and WinUI does it more modernly (and ticks all the boxes). OSX has its toolkit, seems to nail everything correctly. Linux has Qt (lets ignore GTK for now, only reason you use GTK is if you want to appear Gnome-native), and Qt also does native++ uplifting on other toolkits (ie, native widget + additional feature expansion, plus perfect mimicry of native look for entirely new widgets), plus Qt does everything you need to do correctly and easily.
There are also new UI toolkits coming up through the ranks that are trying to knock Qt off that #1 position. None of the WebUIs would even place in this race.
Web UI toolkits always look non-native, are hard to interpret, often use low contrast (and frankly ugly) colorschemes, are easy to use in ways that do not comply with usability standards across OSes, and usually do nothing for A11Y.
The opportunity to improve those toolkits was always there, and the ball was dropped.
And, btw, the reason Microsoft even bothered is because (dun dun dunnnn) lots of internal apps at Microsoft were written with Qt, not MFC, and leadership got pissed when they realized (they couldn't tell the difference, since Qt does the native++ technique).
As for Linux, yeah, thats a shitshow. Qt was closed source, Linux isn't, so they made Gtk, but then Qt got open sourced, and then the Gtk guys just kept going. Qt can mimic Gtk3/4 themes and already uses 100% native rendering (same APIs Gtk does).
People keep writing Gtk apps for some reason, and I don't know why. I can get the C++ hate, but Qt has the cleanest C++ I've ever seen.
This[0] sounds interesting. I am not familiar with CEF, so I wonder how the versioning works. When different apps require different versions of CEF, do we just essentially end up with the electron model where every app bundles their own browser (just slightly less bad). Or is there still an advantage to a "shared runtime" in that case?
[0]: https://docs.deno.com/runtime/desktop/comparison/
https://github.com/chromiumembedded/cef
Since when? The browser landscape is much better today than 10 years ago, but no web dev worth their salt assumes anything about the user agent.
I would think/hope web developers are used to “just give me what you got”. Any other mindset leads to “you must install <browser> to see this site”.
It’s Electron devs that are used to that.