Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno Desktop

docs.deno.com

Post reply on HN
Print view View original

391–400 of 418 posts

Re: Deno Desktop

#391

Post by jakelazaroff »

CJefferson wrote: post #383
jakelazaroff wrote: post #367

Earlier quoted context omitted.

> On Mac, I use Firefox and Chrome. 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.

Many people run older versions of Mac OS X (because their machine won't upgrade), so their safari is aging -- they use an alternative browser, firefox and chrome support older mac os x. Of course using unsupported OSes isn't the best idea, but Apple give you security updates longer than they give you 'fun' safari updates.

Sure, and many people also run older versions of macOS and also use Safari.

Re: Deno Desktop

#392

Post by arikrahman »

chem83 wrote: post #283
arikrahman wrote: post #48

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

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

Howdy, the Clojure dialects such as ClojureDart as well as Jank interop with the Flutter to provide a better development experience as well as more capable engine. This is inspired by Toyota's Fluorite implementation within flutter, which may be integrated into Clutter on its release.

Re: Deno Desktop

#393

Post by auraham »

For me, the best about Tauri is that:

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

[4] https://www.youtube.com/watch?v=vmslGvxObvM&t=621s

[5] https://github.com/orgs/tauri-apps/discussions/8524

Re: Deno Desktop

#394

Post by umpalumpaaa »

FooBarWidget wrote: post #331
echelon wrote: post #282

Earlier quoted context omitted.

The biggest weakness of a framework like Tauri is the choice to target system webviews instead of bundling a browser runtime. 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 tha…

Web developers already have to deal with different browsers, versions and API coverage.

The beauty of shipping a desktop app would be to not have to deal with that though… also those built in web views are usually older than average.

Re: Deno Desktop

#395

Post by Klonoar »

skydhash wrote: post #257
Klonoar wrote: post #174

Earlier quoted context omitted.

Users don't actually give a shit. This is a techie complaint, and that's opting for a charitably nice description.

> Users don't actually give a shit. 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.

Yeah, I've done that job countless times in my 20 year career.

Knock it off already.

Re: Deno Desktop

#396

Post by liamgm »

40four wrote: post #225

Deno continues to impress me. It’s honestly been quite a while since I started a new project without it. It has fully won my support over Node.js, the ecosystem has really matured nicely. I don’t know how often I’ll use this feature, but it’s really nice to have the option!

yes the big win from this is the Node API / NAPI support , if you write node_modules in nodejs , electron , raycast , edgejs you can reuse it .

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

Re: Deno Desktop

#397

Post by jemmyw »

steve_adams_86 wrote: post #273
jemmyw wrote: post #270

Earlier quoted context omitted.

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

I think they mean deno handles transpiling for you so there’s no visible machinery for this aspect of the program. It’s just convenient.

I assumed they meant more than that because nodejs does the same since v22.18 and prior would do it with a flag. But they mentioned type stripping, which is really all transpiling of ts does for most code.

Re: Deno Desktop

#398

Post by gabeidx »

auraham wrote: post #393

For me, the best about Tauri is that: - 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. Web…

There's a comparison page: https://docs.deno.com/runtime/desktop/comparison/

And you can embed anything on the binary with `deno desktop --include […]`.

Re: Deno Desktop

#399

Post by lmm »

jorisw wrote: post #115
gf000 wrote: post #55

Earlier quoted context omitted.

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 ma…

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

The OS-component-oriented approach was defensible in the days of desktop only (though personally I think it was a mistake even then), but it's not sustainable now. People want your app on their PC to look and behave like your app on their phone (whichever combination of PC and phone they happen to have), and that's a lot more important to them than having it look and behave like other apps on their PC.

Re: Deno Desktop

#400

Post by wolvesechoes »

lmm wrote: post #399
jorisw wrote: post #115

Earlier quoted context omitted.

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

The OS-component-oriented approach was defensible in the days of desktop only (though personally I think it was a mistake even then), but it's not sustainable now. People want your app on their PC to look and behave like your app on their phone (whichever combination of PC and phone they happen to have), and that's a lot more important to them than having it look and behave like other apps on their PC.

> People want your app on their PC to look and behave like your app on their phone (whichever combination of PC and phone they happen to have), and that's a lot more important to them than having it look and behave like other apps on their PC.

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.

Post reply on HN