Desktop Apps with Deno | Hacker News Reader

Desktop Apps with Deno

github.com

72 pointsmodinfo31 comments

This is what frustrates me with JS development/the ecosystem - why use Astrodon instead of Tauri directly, with deno and whatever else you want? Sure maybe a bit quicker to get started, but there's more unknown/unfamiliar, another set of docs to look at, another thing that could be the cause when something goes wrong, just unnecessary indirection.

Or put another way, why isn't this just a template repo, why does it need it's own 'community', versioning, plugin system etc., it just seems like an annoying level to have a framework at to me - on top of Tauri but beneath any svelte/vue/etc. framework you might use.

> why use Astrodon instead of Tauri directly, with deno

i haven't heard of any of these. even deno just heard today.

Well that's my point really, this sort of behaviour of the ecosystem leads to exponential 'stuff' to be (not) aware of.

Tauri's the Electron-like bit doing the bulk of the work here. It's framework & JS runtime agnostic, just packages up your compiled frontend with your Rust backend, and provides an API between the two.

Does that mean I get to link you to Bun?

https://www.youtube.com/watch?v=FMhScnY0dME

https://bun.sh/

https://xkcd.com/1053/

I am not currently familiar with Tauri or Astrodon, but it appears that Tauri uses Nodejs and Astrodon uses Deno. For me this makes Atrodon more appealing as it appears that despite years of using Node, in the future I may move to Deno. Certainly I am going to try Deno. And since I do build some small desktop things with Electron, I might try Astrodon for them. Thank you Node. Thank you Electron. Thank you Deno and thank you Tauri and Astrodon.

I'm about 95% certain Tauri doesn't care what you use, though I've only used Node and I'm sure all its quickstart docs assumes so too, but basically it just needs to know how to bundle your frontend, it doesn't care what you write it with or how you compile it.

Tauri itself is written in Rust. You could have a static page that loads the rest by SSR in Rust and no node/deno/anything.

My understanding is that Tauri is designed for using a Rust back end (i.e. the code responsible for creating windows, and native platform interop), with arbitary html+javascript front-end. One can think of it more as a way of creating a web-tech based UI for your program otherwise written in rust.

Astrodon on the other hand appears to be designed around allowing you to write the back-end in javascript running on Deno, with the front end still being arbitrary html+javascript. The net result being more akin to a deno powered electron (instead of a node powered one).

Hopefully we'll get cross-platform (desktops, mobile, and web) GUI libraries that aren't using webtech on non-web platforms soon. Flutter is already viable, I believe. There are also some interesting movements in Rust-land: Lapce uses Druid to run on all desktop platforms. Sadly, neither Druid nor Iced support the mobile OSes yet. But eventually we might be able to forget about all these Electron and Electron-esque messes.

They already exist, but few want to use them. Qt is a thing and has been for a very long time. It really wouldn't take much effort to interface with it from JavaScript.

Qt more or less requires you to write C++ though, so it's understandable people don't want to use it. Even if you use QML you'll still write most of your app in C++.

Plus, customising the look of Qt apps is way way more difficult than web apps. QtQuick is better than QtWidgets but it's also waaaaay less mature. For instance you can't make custom scenegraph widgets containing text.

Anything that is "native" is going to require FFI integration into whatever dynamic language it is being used with.

Also, C++ really isn't that hard for a JS developer to learn for the purpose of creating a native UI system.

> QtQuick is better than QtWidgets but it's also waaaaay less mature.

No one should be using Quick, IMO.

> No one should be using Quick, IMO.

I agree - I meant it is better in terms of animation/styling support. Worse in just about every other way.

I wouldn't hold my breath. Systems engineers have been trying and failing for years to do this. Modern web browser finally did what they couldn't.

Using an incredible amount of system resources for simple tasks?

Creating an equally slow UX on multiple platforms?

Make UI dvelopment fast and accessible so people can move human resources in other areas of development?

I prefer a fast UI over fast UI development.

Todays web based apps tend to skip my inputs if I type to fast, and I'm not a fast typer.

Apps stand and fall with their UI.

Apps should please their user nit their developer and I say that as a developer.

The goal of an app is to make the life of it's users easier not mine. It's my blood, sweat and tears so they can save theirs for their job.

Linear.app has shown that a web-powered desktop app can be as fast as a native desktop app.

There's still tons of room to make web powered desktop apps better than the current mainstream Electron ones - without abandoning the browser.

There's a commercial project that's trying to make linear's architecture into a framework: https://replicache.dev/

Demo: https://repliear.herokuapp.com/d/lXsPEs2kl6?view=active

I think people really underestimate the strength, and brilliance, of the web platform.

Flutter is available. But with Flutter you're largely gonna be limited to the widgets and design styling created by Google.

QT exists. But QT will also be driven by the needs of the QT corporation.

The way web tech has evolved, however, there are a whole bunch of different widget libraries, a whole bunch of different design philosophies, a whole bunch of different platforms that you can build on, from the largest companies in the world to individual developers.

It's very hard to see how any other tech can ever evolve to this point. If any other company/developer creates an alternative stack, that stack will almost certainly be dominated by those creators. If instead, some sort of consortium comes together to create this non-web tech, it will move far too slow to catch up with the contemporary state of web tech, never mind where web tech would have reached over the time they spent on reaching that state.

Lovely to see this space continue to grow.

Despite the hate it gets, Electron is an incredible tool to be able to quickly create a decent native experience (and as someone who uses linux - I tend to get native apps with company support, which is miles ahead of where I was 10 years ago).

I'm glad to see folks playing around with the native installed webviews - now that MS is all in on webview2, this feels like a good solution to some of the bloat required by locking a chromium version in electron.

Slightly more likely to hit compatibility issues across machines, but for most apps not using cutting edge apis - not too much of a concern.

And a lot of electron apps tend to have web versions anyways (I mean why not, right?), so you're probably supporting all the big browsers already, so you might as well use the platform's native webview.

This isn't really true (often, but not always).

etcher is electron based - https://www.balena.io/etcher/

But given it's writing to removable media and is an offline only experience - there's no reason to host a page at all.

Works great across every OS I use it on.

> create a decent native experience

I never found an electron application that was even remotely "decent" or "native". The best one I used was Element (Matrix), any other way somewhere between "somewhat usable, but not good" (Webex) and "mv program /dev/null" (Teams)

The only way to get a good native experience, is to write native apps, using the native Toolkit.

> The only way to get a good native experience, is to write native apps, using the native Toolkit.

Hey - I'd love it if companies would do that too. But in the mean time... I'm not enough of an ass to throw away the solutions that work.

That said - Webex is not an electron app (Appears to be QT...). Teams is terrible by itself (no electron needed). Other apps do just fine... So I'm not sure what it is you think you're comparing.

Slack/Discord/Etcher are all electron, and frankly they work fine (etcher is even nice).

So between "You're on linux and we don't support that" vs "Here's a working app with company support (electron based)"... I know which I'd pick.

Ah, well you are right, webex is not even Electron, does not even remotely look like Qt.

Discord was - last time I used it on the desktop - awfully sluggish and basically even worse than in a browser.

We can just extend it to non-electron toolkits (E.g. Java Swing):

- Splash screen (E.g. I've rarely/never seen a native Libadwaita/GTK program that used one, they may exist, but are really rare in the linux world, examples: Teams, Mediathekview)

- Custom notifications (E.g. in teams, if you download a file, you get undismissable - at least for me ^^ - notifications that stay always on top)

- Weird custom things (E.g. Teams draws on close and minify buttons, that makes no sense)

- Order of the buttons in e.g. boxes (Is it Yes-No or No-Yes?)

That's how I measure "native-ness"

Does it use the native/default webview of the platform?

Since it's based on Tauri, I would think so: https://tauri.app/

Oh, missed that, thanks. While this has obvious advantages over electron, like file size, it has the great disadvantage, that you can't be sure, that your view layer behaves the same for all platforms.

Even on the same platform you can't be sure.

Different version, different behavior.

Can someone on Windows or Linux comment on how this compares with nativefier?

Isn't this more of an Electron alternative, exposing desktop APIs to web based apps, where nativefier is just a wrapper over webpages?

I think you're right

Reply on news.ycombinator.com