Hacker News

In case anybody else wondered CEF is the Chromium embedded framework.

https://github.com/chromiumembedded/cef

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.

[0]: https://www.riotgames.com/en/news/architecture-league-client...

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.

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".

I'd prefer if it just used the system webview rather than downloading and managing an embedded browser itself. Webview2 on Windows for example.

System WebView but Electron is now the system

Wouldn't that just be "Raw"? I.e. start a webserver and ask the system to open the URL. There is no "special stuff" to do in this case like avoid sockets in favor of IPC to a well known webview or package CEF and no real integration to make with dev tools etc after - it's just open socket and serve from prebuilt binary.

> I'm happy to see this I see that this provides CEF, Webview and Raw

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.

You are running a binary that you got from the developer. If it presented you with Deno permissions, I think that would be misleading because there’s no guarantee of their integrity.

> What deno desktop doesn't have yet

> Runtime permissions for desktop apps (a permission prompt on every filesystem / network access, i.e. Deno's permission system applied to desktop sandboxing).

You may be thinking of having messed with a 3rd party/unofficial solution in the past, Deno Desktop is new and only just this last week showed up in the Canary branch.

agree, small footprint & cross-platform looks like a nice alternative to electron or tauri..

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).

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

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.

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.

> 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.

> 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+.

Who cares if it looks native?

Native UIs change all the time too and not always for the better.

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.

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.

Nobody cares about this anymore.

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.

> 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?

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.

> 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.

None of that changes whether it's a UI toolkit, which it surely is.

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.

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?

There’s no running TS. Everyone executes JS.

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:

https://www.typescriptlang.org/tsconfig/#erasableSyntaxOnly

>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.

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).

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.

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.

If you want desktop and mobile builds.

Tauri 2.0 added support for iOS and Android builds as targets.

Temporarily at a place with 10-15 mbps. 150 MB is around 1 minute.

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

> Deno can run true TypeScript directly and not just strip types

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.

> Why would I use Tauri now?

You’re “backend” isn’t JavaScript.

> and you get a reliable rendering engine

How is it more reliable than Tauri - aren't they both using the system webview?

But that would be the same argument for using electron? Why use this and not electron?

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!

Do you mean "Unlike Deno Desktop"? Deno Desktop definitely relies on a browser engine.

Do you reccomend and resources for building w/ & learning about wasm?

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.

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.

Thanks, I'll update the docs. When we wrote them a couple weeks back, Electrobun was announcing Linux only support.

From what I understood, what you want is `deno desktop --include […]`.

> Includes an additional module or file/directory in the compiled executable.

> Opt into the bundled Chromium (CEF) backend when you need identical rendering across macOS, Windows, and Linux.

Sound more like Electrobun

I will die on the hill that Java was a good language, and had the potential to leapfrog us from where we are by at least a decade.

But it got hobbled by the awful, awful enterprise style culture, cultural misunderstanding of OOP (especially inheritance), and corporation shenanigans (fucking oracle).

Java would be a killer platform if they shipped built-in, tauri-like, UI.

At this point I think that would be a more sane outcome than whatever it is we have right now.

The Revenge of Javagator!

https://news.ycombinator.com/item?id=19837817

[dead]

No matter how much you hate everything about js desktop apps — there are no proper alternatives.

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.

I'm truly curious about running another desktop environment inside via WASM, honestly...

libcef is the Chromium embedded framework[0], so your build isn't using a webview or maybe its using both. I just tried it on my mac, and I can't keep libcef out even with `--backend webview`.

https://github.com/chromiumembedded/cef

IIRC Electron hello world is ~ 100-150 MB because it bundles a browser/Chromium runtime.

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`?)

Try the webview backend: `deno desktop --backend webview`

I use it for several applications (frontend, backend, CLIs) in production settings, and it has been excellent. Caveat: I serve small internal teams mostly, some projects only serve < dozen users. One is around 500/day. No issues at all. I’ll definitely use Deno desktop for these internal tools. Their binary compilation (especially now that it can include other binaries) has been totally sound and I expect this to work well too.

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.

Why "etc."? Isn't it just node, bun and deno? Genuine question

Bartek from the Deno team here. No promises yet, but we're looking into feasibility of it.

The docs say it's planned but no proper roadmap for it yet.

No customizable programmable browser runtimes exist for those.

Webviews have always worked since MSHTML, the issue is being comfy helping Google's market share instead of writing portable Web code.

Is it not a web view? With nodejs capabilities from the “backend” half of the app for normal desktop app filesystem access etc?

How can in-process channels be more dangerous than a socket-based IPC? The frontend still goes through the "secure" JavaScript engine AFAICS.

Deno actually has had a built in compile to binary feature * I've used it before a few times.

* https://docs.deno.com/runtime/reference/cli/compile/

Look into Single Executable Applications

https://nodejs.org/api/single-executable-applications.html

Care to expand on what this solution is? What is Clojure bringing to Flutter in this case? Ty.

I guess people are tired of each instance of an Electron-based app using 1GB+ of RAM.

Sorry to hear that, could I ask you to file an issue in our bug tracker?

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.

I expect a poorly conceived and buggy vibe coded version will be available this afternoon.

Bartek from Deno team hear. I'll love to hear what you feel is missing so we could improve `deno desktop` for more users.

I think for a little while longer, you can catch bun anything, electro or not, refugeess just by not being bun.

> I'd wish we would have a real "write once, run everywhere"...

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!

Odd because I'm wrapping up an app that uses Xaw. It should run on the billion or so machines that support X11

  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.

I challenge you to replicate something "simple", like an iMessage-style UI/UX in pure Win32 or WinForms.

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.

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.

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.

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.

They really did their best comparing it with other tools here https://docs.deno.com/runtime/desktop/comparison/