Deno Desktop(docs.deno.com) |
Deno Desktop(docs.deno.com) |
Hi! I'm trying my best okay? Hokusai Pocket might currently be composed of wood and string, but one day he will be a real boy!
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.
The web views are entirely about productivity gains, not technological excellence. I don't know of many who would argue that the web view approach is superior from a purely technical perspective. It is mostly downsides in terms of performance, E2E latency, startup delay, security edges, etc.
Is that supposed to be a challenge?
WinForms is incredibly easy and simple to use...
Doesn’t mean you should use it for new things in 2026, but for building a chat app with? Yeah, it’d be very easy.
I’d know, because I’ve done it (granted it was over 15 years ago at this point, but I’ve done it). Was used internally, with a PHP backend. Worked great!
Yeah, hello desktop.
D:\source\DenoTest>deno desktop main.ts
error: Module not found "file:///D:/source/DenoTest/desktop".
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.- Can use "raw, system WebView, or bundled CEF" vs "bundled Chromium"
- The size can be smaller in the Raw/WebView cases.
- Built-in automatic differential updates
- Built-in cross-compilation (+the compilations just come built into Deno itself rather than as a 3rd party package).
And, of course, the same lists as one would generate when comparing the base Deno vs Node themselves.
So thankfully we can still have our REPLs with live reloading and nice documentation (MDN, W3schools etc.) and large library of embeddable UI components without most the costs of using electron.
If cross compiling were really just about the result rather than the means, what would the difference be between that and normal support for multiple targets?
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.
Yes, classic Qt Widgets still doesn't allow for hardware acceleration.
However, the majority of Qt UIs you deal with are in Qt Quick, which is hardware accelerated. Almost all of KDE is Qt Quick, for example.
Smart move from the Deno team to get me to try out their ecosystem. I probably wouldn't have bothered prior. I've been mostly fine with npm, as its been much faster of late, and the security features recently released are good.
Worth noting is that the team has improved compilation features steadily. Every issue I watched last year has been completed and I’m not encountering blockers anymore.
I'm trying to argue that it should already be available via Firefox, Chromium, etc on desktop.
> Small by default, full Node compatibility
I tried `deno desktop index.ts` with the 5-line Hello world in the article.
Result (Windows 10): 442 MB. Ouch.
I thought it would be smaller than an Electron build, but it's far worse. Did I do something wrong?
(libcef.dll: 247 MB) (deno-test.dll: 78 MB <- contains the hello world)
So I hoped we could have a <= 20 MB solution by reusing the OS webview or similar. Having more than 400 MB is a bit deceptive for me. (Again: maybe I just did something wrong in the config: should I do something else than `deno desktop test.ts`?)
https://docs.deno.com/runtime/desktop/backends/#webview-(def...
That's Sciter (https://sciter.com) and Sciter.Quark (https://quark.sciter.com) in particular, no?
Are they running the frontend and backend in the same process? Sounds a bit dangerous security-wise?
For 8 years now, constantly updating to newest Electron, my Electron app has been using only about 150mb of RAM - (see Video Hub App)
The web is probably the closest thing the software industry has to a truly universal, open application platform. There is corporate influence, but it is substantially more vendor-neutral than any other UI platforms.
The web stuff mostly uses licenses such as MIT, Apache 2.0, and BSD. GPL-licensed projects exist, but still many more on permissive side.
Web is based on open standards developed through organizations and specifications are publicly available, royalty-free, and implemented by multiple independent browser engines rather than being owned by a single corporation.
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?
It seems great to be able to cut hundreds of megabytes out of your app installer, but the platform differences wind up being a complete and ongoing pain in the ass.
Tauri support on Windows is phenomenal.
Tauri on Mac runs into lots of WebKit/Safari issues, especially on older Mac machines that have an older engine that doesn't support modern web APIs. Your app can crash or be left non-functional. You'll find out about these runtime bugs in the wild randomly, and patching for some customers can take days, if not weeks.
Linux support is hellish, and it's best to not even try targeting Linux with Tauri.
Tauri is in the process of adding CEF support. It should probably become the default build target for all platforms.
> Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June
Granted this was years ago, maybe the situation improved? I had to abandon my CEF project because of this.
[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.
It's not the only option, but it's the most mature with the largest amount of docs + stack overflow questions, so it's a "safe" choice.
If you peek into the native resources files of most games/desktop apps, you'll find a good portion of them bundle + use the CEF dll.
No shortage of games using it for in-game browser stuff, too.
The desktop app was originally a native C++ app, but they switched to CEF around 2011-2012. (It caused a very noticeable drop in performance!)
Before that I was closing both and playing a game of roulette. By the the time my game was working, I may have already been reported for being afk and the game ended. Edit: other bugs have included starting to download the game and then signing in afterwards (their UI doesn't stop you) and then download progress disappearing, perhaps hanging, and you having no way to know it for a 40gb file unless over an hour has passed and you check disk size and then realize the client doesn't know how to load it. Start over and do a fresh install again, clear cache etc because their cache of the client still thinks somethings being downloaded even though it's not. Also having chat permanently off, results in weird glitches with friends requests and being unable to add new friends.
Horrible experience. But since the game is so optimized for addiction and dark patterns these days, and sunk cost, its a game I find myself returning to every once in a while.
if (typeof Array.prototype.includes === ‘undefined’) { …
request.then(response => response.json())
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...
Yes, it kind of defeats the standalone binary aspect but if you're really concerned about security, maybe it's a happy medium.
> Runtime permissions for desktop apps (a permission prompt on every filesystem / network access, i.e. Deno's permission system applied to desktop sandboxing).
However, what I have seen is that a lot of other libraries I use have switched to Bun. I haven't seen any that switched to Deno, and so I've been under the impression that Bun is becoming a strong node replacement candidate while Deno is not, or at least that the community is making a strong preference for Bun. Anyone have more insight into this?
https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbo...
"NAPI allows native Node dependencies to target Node without actually depending on a specific version of Node or V8. NAPI abstracted the V8 JS engine away, by providing JS-like APIs for: creating an object, declaring a property, etc.
NAPI is the contract that all modern native Node modules use to interact with Javascript." [1]
1: https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbo...
I don't understand how the coordinated process group works. Doesn't that mean in this multi-process mode it must be IPC? Maybe the claim "shared memory space" is more an architectural description than an OS-level claim?
marshalling of values back and forth between the JS/C++/Rust layers still has to happen but these are just straight C api calls in process under the hood so much less overhead than having to do serdes across a socket/pipe.
- https://github.com/denoland/deno/blob/main/cli/rt_desktop/li...
- https://github.com/littledivy/laufey/blob/main/webview/src/m...
Here's the CEF docs on processes: https://chromiumembedded.github.io/cef/general_usage.html#pr...
EDIT: ...and the CEF docs on IPC: https://chromiumembedded.github.io/cef/general_usage.html#in...
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.
I find the feature matrix comparison to be extremely well done and the sections beneath explaining advantages and disadvantages to be some of the best docs I've read recently.
- We can embed an existing application using a sidecar [1].
- Now, we can also use Elixir in the backend, embed the BEAM, and deliver a single binary, see ElixirKit [2].
As far as I know, LiveBook Desktop [3] is using Tauri for building binaries for MacOS and Windows. If Tauri works for the Elixir team, I think it works for me too.
Also, I know that Tauri is not bullet proof. WebView can be limited for some use cases, see [4]. There is some effort to use CEF to mitigate those problems, though [5].
I'd like to know how Deno Desktop compares with Tauri in this context. I know it is a new product, not sure if we could bundle an existing binary in Deno Desktop, like in ElixirKit.
[1] https://v2.tauri.app/develop/sidecar/
[2] https://elixirkit.hexdocs.pm/tauri.html
[3] https://github.com/livebook-dev/livebook/blob/main/rel/app/t...
And you can embed anything on the binary with `deno desktop --include […]`.
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.
https://docs.deno.com/runtime/desktop/comparison/ https://github.com/blackboardsh/electrobun#platform-support
We just got used to it. There is some very vague thin layer of "commonly accepted patterns and symbols", but otherwise users just get through it.
Also ChatGPT hangs and has more weird bugs compared to Codex.
https://daringfireball.net/2026/06/swiftui_only_makes_it_eas...
That sounds like a monster I would be afraid to touch.
But it got hobbled by the awful, awful enterprise style culture, cultural misunderstanding of OOP (especially inheritance), and corporation shenanigans (fucking oracle).
I need to enjoy my work to be engaged and productive.
Especially if to consider that I've added native D support to Sciter [1].
[1] https://terrainformatica.com/2026/06/05/ai-assisted-developm...
You can get your app sizes as low as 15mb with `deno desktop --compress` (in canary)
A tiny "raw" windowing backend exists for WebGPU rendering as well
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
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.
Sound more like Electrobun
> Includes an additional module or file/directory in the compiled executable.
Now you can just start a server with deno pretty easily and serve a website. But WebUI will actually also manage opening the browser window for you as well a make the communication between backend and frontend just like using a Webview or electron.
They beat Tauri at their CEF support.
Webviews are a mistake in most cases. They're too platform-specific, and certain Webviews (Safari/Webkit) are buggy as hell, making platform support a nightmare. (Linux, ironically, is even worse due to how underbaked webviews are on the major desktop Linuces - Tauri is barely functional on Linux.)
Deno Desktop could be a real contender in this space. It's good to see more Electron alternatives.
Sciter SDK [1] contains scapp[.exe] - standalone Sciter engine that can be attached to HTML/CSS/JS bundle making standalone (single exe file) and portable executable. https://quark.sciter.com/ tool allows to compile such apps.
Size of "hello world" is a size of scapp.exe binary + size of compressed HTML/CSS/JS bundle.
On Windows scapp.exe is of ~14 Mb. On Linux ~18 Mb.
Linux version at startup detects GTK4, Wayland or X11 and uses those as windowing backends.
On all platforms Sciter provides out of the box: HTML/CSS/JS runtime, libuv based Node.JS alike runtime, GPU accelerated rendering, WebGL 3D runtime, JS built-in persistence (NoSQL DB).
It does not have TS compiler built-in as Deno, but that TS-to-JS compiler is better to be outside anyway as it is used only once - at app loading.
this is misleading. there is no "running true ts". you will always be running pure js (until someone actually develops a "true" ts engine), and deno does "type stripping" just the same. the only difference is that it bundles the tools and makes it transparent and config-free which is more convenient (although more rigid).
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.
The state of OSS funding is precarious. The acquisitions at least guarantee some runway for the maintainers. Maybe the acquirer has alternative intentions than to simply bankroll the project’s the way it was, but at least someone is paying to keep the maintainers fed.
After having worked in the JavaScript ecosystem for over a decade, I don’t think _any_ project of significant size is guaranteed to last or have support. We need to be thinking about resilience (_when_ the framework stops being supported), not pretending like using OSS projects without paying them should magically give you some support contract/assurances.
Tauri 2.0 added support for iOS and Android builds as targets.
You’re “backend” isn’t JavaScript.
What exactly do you mean by that? Because no js engine carries the ts types into the runtime as far as I know. Deno and nodejs both use v8 as the runtime. v8's internal types are not connected at all to the ts types regardless of the wrapper. The only difference might be when/if static type checking is performed.
How is it more reliable than Tauri - aren't they both using the system webview?
The same set of reasons anyone made desktop apps before Deno desktop launched. Deno desktop is not the reason desktop apps are made. If someone really wanted a desktop app made before, deno desktop isn't going to suddenly make new ones start appearing. It will just be a new choice among the many.
Also TS itself is going towards stripped types. There’s this proposal which might land on browsers some day:
https://tc39.es/proposal-type-annotations/
And in preparation you can use this setting on your tsconfig:
I grew up on 30 mbps. >= 100 is all I need nowadays.
But 10 mbps and websites and downloads really start to take a while.
The more bits and bytes you save, the more people will be pleased with your stuff! Even if they don’t know what bits and bytes are, and just go based on impatience
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'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.
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.
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.
Like 25 years ago. Nobody gives a damn since Microsoft stopped giving a damn.
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.
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.
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.
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-...
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.
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.
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).
The irritating, and unnecessary, pedantry.
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.
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?
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.
I hope it's a temporary step back to leap forward, in the future.
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.
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 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.
news to me. Been using steam since it launched. Never noticed it being sluggish
Outside making it so you don't have to call to open the link yourself, I'm still not sure what could be integrated in the scenario. Deno can integrate with WebView because the WebView APIs were designed to allow external applications to have full control of the session. CEF (the Electron-like) approach works because Deno packages CEF & the APIs as part of the app itself, having even more control of everything. Browsers are meant to be in control of themselves or the user, and have had a long history of fighting malware trying to act otherwise.
What DE? I'm on KDE.
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.
The framework was reasonably good for its time. By the time good looking UI frameworks came, the bad reputation was already set.
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.
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 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.
The problem is like with JS or PHP, it is ubiquitous in many settings. There are a lot of people who can use it because it was the default language taught in CS programs, many corporate settings for decades, or similar. It’s the runtime for android devices. It’s everywhere. Of course you’ll encounter a lot of low quality developers.
Your comment mostly indicates that you haven’t been fortunate enough to encounter the high quality Java devs, not that they don’t exist. They exist and they build world class software that backs massive systems like elastic search, Kafka, spark, or Cassandra.
They responded to my issue several years later. I had changed jobs and I couldn't care less any longer.
If that's your example of quality… well…
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.
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.
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.
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.
You can use JS but it doesn't ship a browser engine, it renders with its own lightweight toolkit.
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.
I don’t. VLC is available everywhere, so your requirement is clearly not a problem. Jetbrains is available on all major desktop OS.
It's also funny to me as someone who's been building websites for 20+ years at this point, because the platform differences used to be much, much worse. Coincidentally, I just saw this article, which makes the case nicely: https://www.bram.us/2026/06/21/do-websites-need-to-function-...
On macOS, the only way to upgrade your WebView is to upgrade your OS, which requires rebooting. Lots of people just don't bother. You can upgrade to the latest Chrome or Firefox just by downloading it (assuming they support your macOS version), and they auto-upgrade themselves pretty aggressively.
On the web, very old versions of Safari (6+ years old) are a tiny fraction of a percent of your traffic; many web developers just ignore them. In a desktop app based on a WebView, ancient WebViews can be as high as 10-15% of your macOS user base. Ignoring them is not an option.
On Linux, it's common for the major version of WebKitGTK to not upgrade at all except during major OS upgrades. Anyone on Ubuntu LTS 20 is going to have a 2020-vintage WebKitGTK with security patches. (And Ubuntu LTS 20's WebKitGTK was buggier than macOS WebKit, even in 2020, because Apple has more dedicated full-time developers and testers making sure that macOS WebViews work end-to-end.) If you're shipping an app based on WebKitGTK, you can expect to see double-digit percentages of your Linux users running really old WebKitGTK.
Maybe you're such a great developer that your web app works great on ancient browsers, but, if so, it's probably because you didn't need/use much JS in the first place. (Maybe you used HTMX or something.) In that case, is there even any benefit in shipping a "desktop app"? What's your desktop app even for? Offline support? (But your app is all server side…?)
If you have a JS-intensive app that works great on ancient, buggy browsers, then platform WebView might work for you. It's not nobody, but it's hardly anybody.
On Mac, I use Firefox and Chrome.
However, if I use a Tauri app on Mac, I have to use dated WebKit. It's out of a Tauri developer's control.
Sure, but many people use Safari, which runs that exact same WebKit engine under the hood. So if your app is available in the browser in addition to Tauri, you have to support it anyway. And at the very least, you as a web developer should be used to supporting it.
Could be attributed to app developers going the extra mile, but I suspect it's the framework choice.
I also doubt it works well on Linux. The performance of webkitgtk is like running an emulator inside an emulator.
Huge fan, this should definitely be the default. The user experience is incomparable.
One thing I'd like to verify: can the OS effectively use shared mem for cef across multiple different cef-rs apps? I really hope so. In this time of RAM being scarce, this optimization could be such a benefit.
Portable frameworks exist, but they are at most native to a single platform.
I remember encountering one bug with Final Form that triggered rarely in Safari, 100% in Webkitgtk, and never in Chromium.
Here's the developer of Tauri saying it's hard to recommend webkitgtk / Linux support:
> So if you need good linux support now/soon i can't 100% recommend tauri (for Linux) as of now. (I used to be more "forgiving" but with webkitgtk getting worse/more unstable each release i changed my mind)
https://github.com/orgs/tauri-apps/discussions/8524#discussi...
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.
Of course using unsupported OSes isn't the best idea, but Apple give you security updates longer than they give you 'fun' safari updates.
This upsets HN users but the rest of the world decided that apps looking like windows built ins doesn't matter.
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?
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.
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.
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.
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.