5 ms·

Desktop Apps with Deno

72 points by modinfo 4y ago

lagrange77 4y ago
Does it use the native/default webview of the platform?
- e12e 4y ago
  Since it's based on Tauri, I would think so: https://tauri.app/ https://tauri.app/
  - lagrange77 4y ago
    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.
    - croes 4y ago
      Even on the same platform you can't be sure. Different version, different behavior.
hrdwdmrbl 4y ago
Can someone on Windows or Linux comment on how this compares with nativefier?
- folkrav 4y ago
  Isn't this more of an Electron alternative, exposing desktop APIs to web based apps, where nativefier is just a wrapper over webpages?
  - hrdwdmrbl 4y ago
    I think you're right
horsawlarway 4y ago
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.
- mort96 4y ago
  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.
  - horsawlarway 4y ago
    This isn't really true (often, but not always). etcher is electron based - https://www.balena.io/etcher/ 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.
- JCWasmx86 4y ago
  > 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.
  - horsawlarway 4y ago
    > 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.
tormeh 4y ago
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.
- ravenstine 4y ago
  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.
  - IshKebab 4y ago
    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.
    - ravenstine 4y ago
      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.
      - IshKebab 4y ago
        > 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.
- 4y ago
OJFord 4y ago
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.
- 5350-uiop-1130 4y ago
  > why use Astrodon instead of Tauri directly, with deno i haven't heard of any of these. even deno just heard today.
  - OJFord 4y ago
    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.
  - adolph 4y ago
    Does that mean I get to link you to Bun? https://www.youtube.com/watch?v=FMhScnY0dME https://www.youtube.com/watch?v=FMhScnY0dME https://bun.sh/ https://bun.sh/ https://xkcd.com/1053/ https://xkcd.com/1053/
- talkingtab 4y ago
  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.

72 points by modinfo 4y ago

lagrange77 4y ago

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

e12e 4y ago
Since it's based on Tauri, I would think so: https://tauri.app/ https://tauri.app/
- lagrange77 4y ago
  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.
  - croes 4y ago
    Even on the same platform you can't be sure. Different version, different behavior.

hrdwdmrbl 4y ago

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

folkrav 4y ago
Isn't this more of an Electron alternative, exposing desktop APIs to web based apps, where nativefier is just a wrapper over webpages?
- hrdwdmrbl 4y ago
  I think you're right

horsawlarway 4y ago

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.

mort96 4y ago
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.
- horsawlarway 4y ago
  This isn't really true (often, but not always). etcher is electron based - https://www.balena.io/etcher/ 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.
JCWasmx86 4y ago
> 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.
- horsawlarway 4y ago
  > 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.

tormeh 4y ago

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.

ravenstine 4y ago
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.
- IshKebab 4y ago
  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.
  - ravenstine 4y ago
    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.
    - IshKebab 4y ago
      > 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.
4y ago

OJFord 4y ago

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.

5350-uiop-1130 4y ago
> why use Astrodon instead of Tauri directly, with deno i haven't heard of any of these. even deno just heard today.
- OJFord 4y ago
  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.
- adolph 4y ago
  Does that mean I get to link you to Bun? https://www.youtube.com/watch?v=FMhScnY0dME https://www.youtube.com/watch?v=FMhScnY0dME https://bun.sh/ https://bun.sh/ https://xkcd.com/1053/ https://xkcd.com/1053/
talkingtab 4y ago
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.