Live data from Hacker News

Deno Desktop

docs.deno.com

381–390 of 418 posts

Re: Deno Desktop

#381
post #4

Earlier quoted context omitted.

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

Their comparison page shows some savings, but not in every case (~40 MB / ~150 MB) https://docs.deno.com/runtime/desktop/comparison/

To be fair the ~150MB is for the CEF scenario (when chromium gets bundled); and eventually they want to introduce a shared CEF runtime across apps.

Re: Deno Desktop

#382
post #202

Earlier quoted context omitted.

I change clothes all the time too, still match the pieces of clothing each time. 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.

So if you already wear clown shoes does that mean that you have to wear only clown costumes?

Someone who is in full clown costume looks less ridiculous than someone who wears clown shoes and is otherwise dressed "normally", yes.

Re: Deno Desktop

#383

Earlier quoted context omitted.

> This point of view always confuses me, because web developers already need to deal with platform differences. 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.

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

Re: Deno Desktop

#384
post #296

> Bindings are not IPC. The Deno runtime and the rendering backend run as threads / processes inside the same address space (CEF) or coordinated process group (WebView). Calls go through in-process channels, and the backend dispatches them from its run loop. -- https://docs.deno.com/runtime/desktop/bindings/ I don't understand how the coordinated process group works. Doesn't that mean in this multi-process mode it mu…

from what i understand after a quick look at the source is it uses a C ABI to communicate between the WebView/CEF "host" application and the deno runtime which is loaded by the host as a shared library.

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

Re: Deno Desktop

#385
post #296

> Bindings are not IPC. The Deno runtime and the rendering backend run as threads / processes inside the same address space (CEF) or coordinated process group (WebView). Calls go through in-process channels, and the backend dispatches them from its run loop. -- https://docs.deno.com/runtime/desktop/bindings/ I don't understand how the coordinated process group works. Doesn't that mean in this multi-process mode it mu…

from what i understand after a quick look at the source is it uses a C ABI to communicate between the WebView/CEF "host" application and the deno runtime which is loaded by the host as a shared library. 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/…

also notable that deno has a very low overhead bindings layer for doing JS->C/C++/Rust/Native interop using v8 fastapi calls where possible.

Re: Deno Desktop

#387

Earlier quoted context omitted.

webkitgtk isn't just quirky, it's also much slower compared to more popular browser engines and is particularly bad with RAM usage.

is webkitgtk different than the engine used in safari?

Not necessarily? As far as I know they come from the same WebKit source. But the bridge between WebKit and the OS is of course specific to each system. WebRTC is still experimental in webkitgtk while caniuse says Safari supported it back in 2017.

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

Re: Deno Desktop

#388
post #360
post #198

Earlier quoted context omitted.

Huh, I was going to mention Node's `--experimental-transform-types`, but that was completely removed in v26: https://github.com/nodejs/node/pull/61803

Wow, this is sad to hear. So if I understood correctly, node is walking back from trying to run TypeScript? Pretty sad if so. I hope it's a temporary step back to leap forward, in the future.

Only for non-erasable Typescript! The support for running erasable TS is here to stay. It's not ideal, but on the other hand this is paving the way for the TC39 proposal - if that ever progresses...

Re: Deno Desktop

#389
post #278
post #26

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

[dead]

Re: Deno Desktop

#390
post #70
post #26

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

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.

I don’t understand this logic. The acquisition doesn’t guarantee the project dies and staying unacquired doesn’t guarantee the project continues.

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.

Post reply on HN