Rendered at 11:30:48 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
leleat 4 hours ago [-]
> Shared CEF runtime across apps. Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roadmap.
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?
Just to let you know, CEF was used for Riot and League of Legends client as well [0]. The results haven't been nice, but I'm not aware if this was a problem with the CEF technology itself or other component/processes are to be blamed.
When the new client was built, microservices were the hot new buzzword.
The new client is some weird plugins/services based architecture. Things that'd barely warrant their own class in a boring OOP-based UI framework are instead now "isolated" services. The reality of this isolation being that if one piece breaks, the whole UI becomes unusable anyways. Dozens of things that in another app would've been just a simple synchronous call now behave like remote procedure calls and messages, forcing all the complexity of distributed systems into a local application for no reason.
That's why it runs like ass, breaks if you look at it wrong, and your CPU draws more power when using the client than when playing the game at 200FPS.
qbane 2 hours ago [-]
I doubt the benefit. Practically every Electron app on a desktop uses different versions of Chromium and many are very out of date because of the risk of breaking when upgrading.
teaearlgraycold 43 minutes ago [-]
People build web apps for an array of browsers and huge ranges of versions. I think if you started using some tech to deploy an end user program and knew from the beginning the browser could be updated beneath you it would work just fine. But if you start with a golden version of Chrome and put off updating for too long you’ve let yourself get too comfortable.
troupo 39 minutes ago [-]
> People build web apps for an array of browsers and huge ranges of versions.
en masse they don't. They just target the latest Chrome
teaearlgraycold 30 minutes ago [-]
De facto they do because functionality built three years ago and tested then is running along side functionality they built yesterday and tested on today’s Chrome.
People also do seem to test on iOS Safari because that pain in my ass needs special care on my software. So if a site works on it they either got lucky or tested on an iPhone. It’s generally only other people’s weird tech demo stuff that doesn’t work.
lwansbrough 3 hours ago [-]
Web devs are used to their target being evergreen, so I suppose you could opt in or out of that model: "just give me what you got".
fwlr 16 minutes ago [-]
True for this decade, but in the previous decade it was very much the opposite. Before you used any kind of browser api or nice language feature you would feature-detect it:
if (typeof Array.prototype.includes === ‘undefined’) { …
And if it wasn’t there you would define it yourself, it was called “polyfilling”. This was so commonplace that we built significant tooling like babel to standardize feature detection tests and fallback implementations - for a few years you could write
request.then(response => response.json())
And behind the scenes the Rube Goldberg machine would turn this into something that would run in a JavaScript environment that had neither arrow functions nor promises.
Someone 3 hours ago [-]
> Web devs are used to their target being evergreen
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.
lopis 2 hours ago [-]
> Web devs are used to their target being evergreen
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.
hun3 2 hours ago [-]
System WebView but Electron is now the system
actionfromafar 2 hours ago [-]
Ah, that's a new systemd module now.
sheept 5 hours ago [-]
I was wondering how this integrates with Deno's permission system, which is one of its biggest strengths especially for letting agents run amok on your device.
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.
> Runtime permissions for desktop apps (a permission prompt on every filesystem / network access, i.e. Deno's permission system applied to desktop sandboxing).
jorisw 5 hours ago [-]
> Web technology is the most widely-known UI toolkit in the world.
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.
Culonavirus 4 hours ago [-]
That is not why people use Electron. The goal is not and never was to just be a "UI toolkit" and "adopting UI patterns from their host OS".
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).
Levitating 2 hours ago [-]
gstreamer is not that complicated
TylerE 49 minutes ago [-]
It has a really really crappy security record, though.
kiicia 2 hours ago [-]
chromium is basically operating system at this point, it lacks kernel and ability to boot independently (added in chromium os), which is both good (from abilities standpoint) and bad (when copy of chromium is bundled with every app that renders webform with text field and button and nothing else)
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)
taffydavid 42 minutes ago [-]
Chrome OS is literally an operating system that's 90% through chromium
ignoramous 2 hours ago [-]
> chromium is basically operating system at this point
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).
conradludgate 5 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
noufalibrahim 4 hours ago [-]
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.
wiseowise 4 hours ago [-]
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.
djxfade 2 hours ago [-]
This is pretty much what Tauri solves. It re-uses the systems WebView. So the built apps are tiny (kb to a few mb)
smackeyacky 4 hours ago [-]
Looking native has long left the station as an objection about a UI.
Like 25 years ago. Nobody gives a damn since Microsoft stopped giving a damn.
vintermann 4 hours ago [-]
I'm not part of the Apple world, but I thought they gave a damn?
yurishimo 3 hours ago [-]
Depends on the tool. We (mac people) tend to prefer native toolbars and settings menus, but I would say the days of relying on a "native" textarea or button are now behind us.
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.
jabwd 3 hours ago [-]
Nah they stopped caring as well. Developing an application for macOS is hell nowadays. I hate the state of things but both Apple and Microsoft dropped the ball. Linux is even worse, so yeah I don't see a reality out of this unless we actually create something that surpasses the web in all measures.
nobody_r_knows 2 hours ago [-]
[dead]
DonHopkins 3 hours ago [-]
Liquid Glass says no, they don't give a flying fuck any more.
Abishek_Muthian 5 hours ago [-]
Every time I use Zed across Linux, macOS and Windows , I'm amazed stable and performant it's GPUI framework is. As a user, I'm very happy with it; of course some basic features like accessibility is missing but I'm sure it will be implemented soon.
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.
fny 5 hours ago [-]
Live reload. GUI development in compiled languages is a pain compared to web development.
eklavya 4 hours ago [-]
Try dioxus, it has live reload but it's a work in progress.
ga_to 4 hours ago [-]
Dioxus seems to be 'just' another way to generate HTML on the desktop.
Electron but Rust?
Is there a legitimate upside there?
neobrain 3 hours ago [-]
With Dioxus, program logic compiles to native code instead of running it through a JS engine, and it ships its own HTML renderer (Blitz) instead of bundling a whole browser. So it's a lot more lightweight and performant than Electron.
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.
Abishek_Muthian 3 hours ago [-]
Sounds similar to Wails. It does the same but with Go instead of Rust.
soanvig 2 hours ago [-]
For me it's not stable. After they change their renderer from one to another it freezes for me from time to time. But on the other hand I'm running Nvidia on Wayland so I feel no hate towards Zed owners - and restart is super quick ;)
Abishek_Muthian 2 hours ago [-]
Interesting, I'm on Nvidia in Wayland most of the time too and haven't had single freeze or crash in a very long time. Even the Windows is running inside the Qemu.
What DE? I'm on KDE.
oblio 2 hours ago [-]
> basic features like accessibility is missing but I'm sure it will be implemented soon.
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.
Abishek_Muthian 2 hours ago [-]
I agree about the complexity, but the core developers understand that the accessibility support is crucial and that's where my hope comes from.
That's good news, but I would continue the timer there. That issue is from March 2023 so the counter is at 3 years, 3 months. Let's see if they have anything decent before 10 years.
LunaSea 4 hours ago [-]
Who cares if it looks native?
Native UIs change all the time too and not always for the better.
jorisw 2 hours ago [-]
Change over time is something different from apps looking vastly different at any given time.
valleyer 16 minutes ago [-]
Unfortunately nowadays even the built-in apps on the major desktop OSes are inconsistent, so the temptation for third-party apps not to care is somewhat understandable.
m-schuetz 3 hours ago [-]
> They consistently miss the mark in adopting UI patterns from their host OS.
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+.
jorisw 2 hours ago [-]
That's an advantage to you. Not necessarily to your users.
Klonoar 57 minutes ago [-]
Users don't actually give a shit.
This is a techie complaint, and that's opting for a charitably nice description.
m-schuetz 2 hours ago [-]
The alternative is not that users get a UI specific for their OS, it is that users get nothing since I do not have the resources to develop for multiple systems. So yes, it is also an advantage to users.
resonious 2 hours ago [-]
At this point the only OS with a consistent look and feel at all is Mac. For the other OSes, I don't even know what a "native" look and feel would be. And most apps have their own branding and style they want to tout anyway. So I don't think "apps should look native" is the leading reason to not use Electron.
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.
jorisw 2 hours ago [-]
> 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.
utopiah 5 hours ago [-]
> look native to the OS
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.
jorisw 5 hours ago [-]
Consistency is a large factor in any good design, UI design more so.
gf000 4 hours ago [-]
Consistent like what? Like maybe a decade ago one could say that osx was consistent, but nowadays even SwiftUI and cocoa is visibly different, let alone every second app that uses electron. And people don't care.
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)
jorisw 2 hours ago [-]
> SwiftUI and cocoa is visibly different
Do they render different looking buttons?
Gigachad 5 hours ago [-]
They have internal consistency. The iOS version looks like the macos version which looks like the web version, etc.
This upsets HN users but the rest of the world decided that apps looking like windows built ins doesn't matter.
ahartmetz 5 hours ago [-]
It's more like developers decided - nobody asked the users.
debazel 4 hours ago [-]
ironically the only group of users I've found that actually care about native UI, are other developers and Mac purist.
ahartmetz 4 hours ago [-]
I have seen users having trouble with pixel soup UIs. They may not think "This should be in a native toolkit", but they do think "How the hell do I subscribe to a folder in the new Outlook?".
Gigachad 3 hours ago [-]
The problem in these usability cases is pretty much always layout and constant redesigns rather than the exact theme the button has. I've seen plenty of unusable native ui soup UIs and very clean and simple custom UIs.
ahartmetz 3 hours ago [-]
You could call it the exact theme when a clickable UI element looks just like regular text (it was not inside any kind of button-like shape in the Outlook case that I saw), but it's super common to have that in web-based UIs.
whizzter 3 hours ago [-]
Right, but bad UI's was not uncommon before webviews, if anything the spartan-ness of the web often simpified patterns whilst reliance on weird hotkeys in desktop apps isn't uncommon.
port11 2 hours ago [-]
OS-level consistency is also consistency. It depends what we value. A lot of apps’ design could’ve been basic, OS-like UI. Apps such as GymBook or WhatsApp are internally consistent while still adopting many elements from the system’s design, instead of reinventing the wheel.
oneeyedpigeon 2 hours ago [-]
There are two types of consistency in this context: consistency within an OS and consistency across them. I, too, prefer the first because I only really use one OS, but this preference varies. I don't think it's right to say that the first case = "ui toolkit", but the second case doesn't.
jorisw 2 hours ago [-]
Consistency as a design virtue applies to a single user's experience. This means consistency within the OS.
eterevsky 4 hours ago [-]
Within OS consistency is much less of thing a thing than Web design conventions. Windows by itself has had several different UI frameworks over the years, so different "native" Windows programs can look completely different from each other.
oneeyedpigeon 2 hours ago [-]
> Within OS consistency is much less of thing a thing than Web design conventions.
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.
m-schuetz 3 hours ago [-]
Consistency is the reason why Electron is great. Consistency of the UI across operating systems.
d12bb 2 hours ago [-]
Great for the developer. The user doesn’t use Mac, Windows and Linux. Just one for work and one at home, with mostly different apps, so they couldn’t care less if it looks the same on different platforms.
m-schuetz 2 hours ago [-]
They may care, however, if they get anything at all. I do not have the resources to target something to all platforms, so the alternative wouldn't be "Users get UI targeted towards their OS", the alternative would be "Users get nothing since developers don't have the time to also target their system".
jorisw 2 hours ago [-]
> I do not have the resources to target something to all platforms
Some speculate that agentic engineering will enable the return of native apps
jorisw 3 hours ago [-]
If you think operating systems have nothing to offer in terms of UI patterns or guidance, then yes, that's a different type of consistency.
p-e-w 4 hours ago [-]
That’s why HN users constantly advocate for Vim, a program in which every single thing works completely differently from every other modern application.
vintermann 3 hours ago [-]
Yes, if there's one lesson from historical UI research that still holds, it's that mode switching is expensive. That's why people install vi plugins everywhere.
Wait...
p-e-w 22 minutes ago [-]
Vi plugins don’t even exist for the vast majority of applications.
DonHopkins 3 hours ago [-]
A foolish consistency with terribly designed shallow superficial desktop user interfaces dreamed up by overpaid cocaine addled corporate boutique brand designers with not only no experience but actual burning contempt for usability and human factors and accessability and affordances is the hobgoblin of little minds.
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.
pjmlp 5 hours ago [-]
Yeah, it is mostly laziness and cost cutting at the expense of users.
Nowadays there isn't even an excuse anymore, just vibe code it away in native frameworks.
gf000 4 hours ago [-]
Which native framework?
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.
jorisw 3 hours ago [-]
> if you want a truly universal UI
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.
gf000 7 minutes ago [-]
Well, maybe Java's AWT has been correct all this time.
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.
actionfromafar 1 hours ago [-]
Probably many Electron users also view that as a regression, but a tradeoff worth making.
kajman 4 hours ago [-]
I never thought I'd defend Electron, but I'd rather use the bloated web UI than a vibe coded Qt/GTK version I'm positive will not have seen any human QA.
DonHopkins 3 hours ago [-]
But GIMP! /s
ThatMedicIsASpy 4 hours ago [-]
When I can modify my desktop/theme (KDE) with css I will happily start doing it since that sounds easy.
Styling every application independently because it’s all individual Electron UI without a shared toolkit is much better indeed…
m-schuetz 3 hours ago [-]
I have better things to do than spend my time adopting UI for various different systems. If Electron gives me the option to easily create a UI that looks the same everywhere, then I'll pick Electron over anything else any day.
stared 1 hours ago [-]
Tauri is getting traction in the meantime.
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.
divan 1 hours ago [-]
This. It's nuts how the whole industry accepts that typesetting engine from 80s with bunch of hacks on top is currently dominating cross-platform UI development.
wiseowise 4 hours ago [-]
> 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.
The irritating, and unnecessary, pedantry.
nnevatie 3 hours ago [-]
Indeed. Even Qt isn't native, in the most purist sense.
DonHopkins 3 hours ago [-]
Since when did anyone ever complain that youtube, google maps, roblox, or any other web sites didn't have native buttons and UI patterns?
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?
jorisw 2 hours ago [-]
Basically you're saying websites are the same as apps, and whether they're used in the browser or as a desktop app, the UI is fine to ditch that of the OS. Fine if you think so. I'll be sad to see OS and apps diverge completely in terms of UI.
d12bb 2 hours ago [-]
YouTube succeeds for its content. Its UI is hot garbage both in the web and their apps. Google Maps is an atrocity and I’m very thankful Apple has decent data where I live. Roblox I don’t know, other websites I consume mostly in Reader mode.
raincole 3 hours ago [-]
> UI patterns from their host OS
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?
wilg 5 hours ago [-]
None of that changes whether it's a UI toolkit, which it surely is.
solarkraft 5 hours ago [-]
This is a smart thing to ship. For me it would totally be a consideration when deciding on a platform to use.
sjeno 5 hours ago [-]
agree, small footprint & cross-platform looks like a nice alternative to electron or tauri..
I'm happy for competition in this space, specially because Deno can run true TypeScript directly and not just strip types like the current Node implementation.
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.
flohofwoe 4 hours ago [-]
Deno also just strips the type annotations when running TS code - at least by default. To get type checking you'll need to run via `deno run --check`, or use the separate `deno check` subcommand. No big deal since type checking and linting usually happens automatically in the IDE during development.
bel8 3 hours ago [-]
Good to know. Does it also preclude features like enums?
Bartek from the Deno here. Nope, we do support enums OOTB.
aabhay 4 hours ago [-]
Tauri doesn't lock you in to one JS ecosystem. In fact, it doesn't require you to use javascript at all.
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.
jpace121 4 hours ago [-]
> Why would I use Tauri now?
You’re “backend” isn’t JavaScript.
swiftcoder 4 hours ago [-]
> and you get a reliable rendering engine
How is it more reliable than Tauri - aren't they both using the system webview?
Deno desktop can use system web view OR embed CEF. Tauri is just system web view.
aabhay 4 hours ago [-]
The benefit of Deno Desktop is it's like Tauri except for when you want it to be Electron???
GeneralMaximus 3 hours ago [-]
This is a feature many apps actually need.
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.
SpaghettiX 2 hours ago [-]
But that would be the same argument for using electron? Why use this and not electron?
WASM you can bundle for Windows, macOS, Linux, Android, iOS and web. Unlike Deno Desktop, it doesn't rely on a browser engine.
catears 2 hours ago [-]
Just FYI, when checking out jumpjets homepage, the white-dot airship in the background made the white text in the hero banner hard to read.
Cool project!
matharmin 3 hours ago [-]
Do you mean "Unlike Deno Desktop"? Deno Desktop definitely relies on a browser engine.
lwansbrough 3 hours ago [-]
Yes, thanks.
ai_fry_ur_brain 3 hours ago [-]
Do you reccomend and resources for building w/ & learning about wasm?
lwansbrough 3 hours ago [-]
It's all so bleeding edge right now. It also depends how deep you want to go. An increasing number of languages support wasm as a compile target, which is helpful.
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
paulbjensen 37 minutes ago [-]
Actually, this would be amazing for distributing web games as apps for Steam or online purchase. I am going to give it a try.
krawcu 4 hours ago [-]
Why did they describe electrobun as macOS only?
I checked their docs and it has support for Windows, macOS and Linux
Thanks, I'll update the docs. When we wrote them a couple weeks back, Electrobun was announcing Linux only support.
lillesvin 5 hours ago [-]
As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.
mohsen1 26 minutes ago [-]
In practice it's much harder to maintain a native app. I am noticing this with ChatGPT Mac app vs. Codex Mac app. ChatGPT on Mac is constantly behind compared the web ChatGPT while Codex is shipping features at a much higher velocity.
Also ChatGPT hangs and has more weird bugs compared to Codex.
deely3 4 hours ago [-]
We spend a lot of time using different browsers. As far as I know there no web engine that use native OS UI for rendering.
kuekacang 2 hours ago [-]
Isn't all uses native OS UI widget? But since the brand need to be experienced the same across platform, it overrides the native rendering and use custom styles instead.
nicce 1 hours ago [-]
> As far as I know there no web engine that use native OS UI for rendering.
That sounds like a monster I would be afraid to touch.
droidjj 5 hours ago [-]
> The default WebView backend uses the operating system's own webview for small binaries, and you still have the entire npm ecosystem available through Deno's Node compat layer.
Sounds like a similar architecture to Tauri, but your business logic is in typescript instead of rust.
progx 5 hours ago [-]
> Opt into the bundled Chromium (CEF) backend when you need identical rendering across macOS, Windows, and Linux.
Sound more like Electrobun
liampulles 2 hours ago [-]
Having deno desktop do the framework handling for a bunch of popular options is an interesting choice. It seems deno is trying less to be an agnostic JS runtime, and more an "integrate everything toolkit" (not unlike Spring in the Java space).
DaanDL 4 hours ago [-]
I swear we're just going to end up with Java again.
wiseowise 3 hours ago [-]
Java would be a killer platform if they shipped built-in, tauri-like, UI.
olcay_ 3 hours ago [-]
There's Compose Multiplatform if you are willing to switch to Kotlin. Only caveat is that it uses Canvas rendering on web.
clumsysmurf 3 hours ago [-]
Compose and AOT compiled binaries would be amazing (GraalVM Native Image kinda thing) but it doesn't look very easy at the moment. Leyden with a regular JVM might be the best we get.
mfru 4 hours ago [-]
At this point I think that would be a more sane outcome than whatever it is we have right now.
tonyedgecombe 3 hours ago [-]
We were writing and shipping desktop applications with it back in the nineties. Although many of the arguments against it were similar to the arguments against Electron today.
ivell 52 minutes ago [-]
I think the UI look and feel was very ugly for many users and that caused its demise. The cross platform skin was ugly. The native skins were in the uncanny valley.
The framework was reasonably good for its time. By the time good looking UI frameworks came, the bad reputation was already set.
frou_dh 8 minutes ago [-]
Even the later JavaFX was a tasteless exercise. I opened some apps and you could tell within 1 second that something was wrong because all the text was using fugly non-platform-native (or somehow screwed up) text rendering.
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.
nottorp 1 hours ago [-]
Hmm suppose you have a node GUI-less application. What would you pack it in to have something reasonably self contained to deploy?
Curious to know who is using Deno in anger most days and in production full time? It seems like the choice of JS runtimes exploded over the past few years with that, Bun, etc.
flexagoon 3 hours ago [-]
Why "etc."? Isn't it just node, bun and deno? Genuine question
asim 2 hours ago [-]
In case someone is using something we haven't heard of e.g some are running using cloudflare workers which also has some unique runtime properties. AWS has something called LLRT.
> Backend and UI communication goes through in-process channels, not socket-based IPC
Are they running the frontend and backend in the same process? Sounds a bit dangerous security-wise?
whilenot-dev 1 hours ago [-]
How can in-process channels be more dangerous than a socket-based IPC? The frontend still goes through the "secure" JavaScript engine AFAICS.
3 hours ago [-]
taosu_la 2 hours ago [-]
Is this a new trend? Why are everyone starting to do desktop runtime? For example, I recently saw Bun Electron, and then I saw this project.
iagooar 2 hours ago [-]
I guess people are tired of each instance of an Electron-based app using 1GB+ of RAM.
utopiah 5 hours ago [-]
Interesting but IMHO as we see on mobile providing WebViews work. Maybe instead of having Electron, Tauri, Electrobun, now Deno desktop but also plenty of alternatives then desktop browsers should provide WebViews on desktop with sandbox and permissions that make those applications usable. The alternatives listed here would just be fallback for a transition period until the WebViews are "good enough".
pjmlp 5 hours ago [-]
Webviews have always worked since MSHTML, the issue is being comfy helping Google's market share instead of writing portable Web code.
utopiah 5 hours ago [-]
That's a whole can of worms, Micro$lop entangling its own browser with its OS, getting a (gentle) slap on the hand for its abuse of monopoly position for it, having to remove it claiming it's "impossible", etc.
andyferris 5 hours ago [-]
Is it not a web view? With nodejs capabilities from the “backend” half of the app for normal desktop app filesystem access etc?
utopiah 5 hours ago [-]
If a Web View is not provided by a browser then it's an already installed browser then it's as they say "web rendering engine" that they ship along.
I'm trying to argue that it should already be available via Firefox, Chromium, etc on desktop.
koolala 2 hours ago [-]
Firefox doesn't release a webview engine but if they did I wonder if Linux distros would use it.
daft_pink 4 hours ago [-]
Is it going to support iOS/Android?
bartlomieju 43 minutes ago [-]
Bartek from the Deno team here. No promises yet, but we're looking into feasibility of it.
koolala 2 hours ago [-]
No customizable programmable browser runtimes exist for those.
Maybe it is because it is still in development, but building and running the Hello World example just gives me a blank terminal and a white window that is not responding.
bartlomieju 43 minutes ago [-]
Sorry to hear that, could I ask you to file an issue in our bug tracker?
arikrahman 4 hours ago [-]
I've decided on using a Clojure/Flutter hybrid that gets the best of all worlds. May integrate move from Bun to using Deno here https://codeberg.org/arik/clutter
5 hours ago [-]
pippoit 3 hours ago [-]
can i open a socket with these tools ? can i open an odbc connection for example ? Or have i need to have a backend ? On desktop usually you can do much more than in the sandbox of a browser . I ask because i don't know these technologies. On windows, even if i don't like it, if the interface and the logic are not too complex, powershell with winform make you create things without "anything" installed and you can easily interact with other windows programs ( office 365 suite, autocad and so on ) so for doing "fast things" in my opinion is a very strong alternative .
bartlomieju 42 minutes ago [-]
Yes, you can do all that. You get a fully-fledged Deno program that can do all of this, _plus_ you get a frontend GUI app.
shevy-java 1 hours ago [-]
I watched traditional GUIs for a while and used many of them, mostly via ruby as wrapper, sometimes also via java. I finally reached the conclusion not too long ago, that web-apps are the only real alternatives now. Too many things do not work when it comes to traditional desktop applications. There are even regressions, e. g. ruby-gtk4 barely works for me. And there is no real support for any problems really. People make fun of e. g. electron "soooo big so bloated", and WebAssembly is still not really in any breakthrough after almost 20 years. But traditional desktop apps are also even more dead. So I'll have to add JavaScript/TypeScript/Node now simply because there are no real alternatives to this anymore. I'd wish we would have a real "write once, run everywhere"...
calvinmorrison 1 hours ago [-]
Odd because I'm wrapping up an app that uses Xaw. It should run on the billion or so machines that support X11
error: Module not found "file:///D:/source/DenoTest/desktop".
sippeangelo 2 hours ago [-]
deno desktop ships in Deno v2.9.0 and is not in a stable release yet. To try it now, run deno upgrade canary to install the canary build. The command, configuration keys, and TypeScript APIs may still change before the feature is stable.
wg0 4 hours ago [-]
I hope bun desktop is coming soon?
tonyedgecombe 3 hours ago [-]
I expect a poorly conceived and buggy vibe coded version will be available this afternoon.
porridgeraisin 5 hours ago [-]
While I've never liked to use deno compared to node and bun, this looks particularly good. The zero config options are nice, all the features seem to be in the place I like, and I'm happy they're not dogmatic about using the system webview and let you ship your own CEF. The state of system webviews on non-windows platforms is horrendous.
numlock86 4 hours ago [-]
How does this differ from electrobun, which they explicitly mention, but make no point about? I had a quick drive with deno desktop and don't see how it's better. If anything it's lacking in comparison in my opinion. But hey, we can build desktop apps with deno now, too. So they got that going I guess ...
bartlomieju 41 minutes ago [-]
Bartek from Deno team hear. I'll love to hear what you feel is missing so we could improve `deno desktop` for more users.
actionfromafar 4 hours ago [-]
I think for a little while longer, you can catch bun anything, electro or not, refugeess just by not being bun.
bossyTeacher 4 hours ago [-]
How is this better than Electron?
IshKebab 4 hours ago [-]
Vastly easier to set up, optionally lets you use platform web renderers, Typescript by default, you can use the Deno API instead of Node (compatible with less code but much better designed), built-in auto update, you can use Fresh which IMO is the best web framework.
RE: Tauri not having cross-compile... There's a GitHub action that compiles for Linux, Windows, and Mac. So practically it does have it, just not out of the box.
DiabloD3 5 hours ago [-]
I don't get the point of this.
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.
flohofwoe 19 minutes ago [-]
You should try the last few Xcode versions some time. As far as I'm aware there's not a single line of Javascript in it, and all UI is 'native' (whatever that means these days), and the whole experience is such a janky and laggy mess that even VSCode feels slick.
It's trivial to write slow UI application in any tech stack, and just being 'native' really means nothing nowadays.
vinkelhake 4 hours ago [-]
I've seen variants of this comment for many years. The alternative to "web UI slop" would presumably be one of the many native toolkits.
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.
kombine 4 hours ago [-]
Yes, native UI toolkits are not perfect, even though I consider Qt very close to one (I'm sure naysayers will find nitpicks). In the end, the choice is between the apps that eat 1GB of your RAM and learning to deal with some idiosyncrasies of native toolkits.
DiabloD3 4 hours ago [-]
It hasn't made any inroads on the desktop though... all anyone did was just package their own SWA into a self-contained browser that serves its own content. They continue to be websites, with all the pitfalls of them.
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.
thepasch 2 hours ago [-]
I think the fact that you listed off five toolkits for three different OSes, all of which are "that OS's own toolkit," might point at the root of the problem here.
DiabloD3 2 hours ago [-]
Windows is so fucking old that I think it has a right to try again.
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.
d12bb 2 hours ago [-]
Even if SwiftUI, Qt and whatever Windows uses this morning were absolutely perfect, developers would write web UI slop to not have to write three frontends. That, and familiarity with JS are the whole reason.
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
[0]: https://www.riotgames.com/en/news/architecture-league-client...
The new client is some weird plugins/services based architecture. Things that'd barely warrant their own class in a boring OOP-based UI framework are instead now "isolated" services. The reality of this isolation being that if one piece breaks, the whole UI becomes unusable anyways. Dozens of things that in another app would've been just a simple synchronous call now behave like remote procedure calls and messages, forcing all the complexity of distributed systems into a local application for no reason.
That's why it runs like ass, breaks if you look at it wrong, and your CPU draws more power when using the client than when playing the game at 200FPS.
en masse they don't. They just target the latest Chrome
People also do seem to test on iOS Safari because that pain in my ass needs special care on my software. So if a site works on it they either got lucky or tested on an iPhone. It’s generally only other people’s weird tech demo stuff that doesn’t work.
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.
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.
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).
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.
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.
[1] https://github.com/zed-industries/zed/discussions/6576
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+.
This is a techie complaint, and that's opting for a charitably nice description.
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.
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.
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.
Some speculate that agentic engineering will enable the return of native apps
Wait...
https://daringfireball.net/2025/12/bad_dye_job
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.
https://9to5linux.com/kdes-new-css-based-style-engine-union-...
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.
The irritating, and unnecessary, pedantry.
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?
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.
You’re “backend” isn’t JavaScript.
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.
WASM you can bundle for Windows, macOS, Linux, Android, iOS and web. Unlike Deno Desktop, it doesn't rely on a browser engine.
Cool project!
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
https://docs.deno.com/runtime/desktop/comparison/ https://github.com/blackboardsh/electrobun#platform-support
Also ChatGPT hangs and has more weird bugs compared to Codex.
That sounds like a monster I would be afraid to touch.
Sounds like a similar architecture to Tauri, but your business logic is in typescript instead of rust.
Sound more like Electrobun
The framework was reasonably good for its time. By the time good looking UI frameworks came, the bad reputation was already set.
https://news.ycombinator.com/item?id=19837817
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.
https://nodejs.org/api/single-executable-applications.html
https://github.com/awslabs/llrt
https://developers.cloudflare.com/workers/runtime-apis/
Are they running the frontend and backend in the same process? Sounds a bit dangerous security-wise?
I'm trying to argue that it should already be available via Firefox, Chromium, etc on desktop.
[1] https://capacitorjs.com/
Yeah, hello desktop.
D:\source\DenoTest>deno desktop main.ts
error: Module not found "file:///D:/source/DenoTest/desktop".
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.
It's trivial to write slow UI application in any tech stack, and just being 'native' really means nothing nowadays.
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.