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/
Deno Desktop
381–390 of 418 posts
Re: Deno Desktop
#382Earlier 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?
Re: Deno Desktop
#383Earlier 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.
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> 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…
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> 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/…
Re: Deno Desktop
#386Re: Deno Desktop
#387Earlier 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?
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
#388Earlier 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.
Re: Deno Desktop
#389I'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…
Re: Deno Desktop
#390I'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.
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.