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

401–410 of 418 posts

Re: Deno Desktop

#401

Post by esperent »

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!

I'm still using node/npm and it's... fine. Every so often I read these posts and think I should change but node/npm is already a low friction part of my workflow.

However, what I have seen is that a lot of other libraries I use have switched to Bun. I haven't seen any that switched to Deno, and so I've been under the impression that Bun is becoming a strong node replacement candidate while Deno is not, or at least that the community is making a strong preference for Bun. Anyone have more insight into this?

Re: Deno Desktop

#402

Post by wiseowise »

olcay_ wrote: post #85
wiseowise wrote: post #81

Earlier quoted context omitted.

Java would be a killer platform if they shipped built-in, tauri-like, UI.

There's Compose Multiplatform if you are willing to switch to Kotlin. Only caveat is that it uses Canvas rendering on web.

Compose Multiplatform is just a worse Flutter.

Re: Deno Desktop

#403

Post by liamgm »

SpaghettiX wrote: post #151
bel8 wrote: 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.

But that would be the same argument for using electron? Why use this and not electron?

the option to use system webview , electron don't provided that

Re: Deno Desktop

#404

Post by cdud3 »

echelon wrote: post #282
tonyedgecombe wrote: post #86

Earlier quoted context omitted.

In case anybody else wondered CEF is the Chromium embedded framework. https://github.com/chromiumembedded/cef

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…

Or use QtWebEngine which uses Chromium under the hood, provides a stable and rich API and enables sharing rather then bundling the browser runtime + is Cross-Platform + security updates are handled too.

Re: Deno Desktop

#407

Post by DiabloD3 »

zerr wrote: post #351
DiabloD3 wrote: post #329

Earlier quoted context omitted.

I notice you say, specifically, Qt Widgets. Yes, classic Qt Widgets still doesn't allow for hardware acceleration. However, the majority of Qt UIs you deal with are in Qt Quick, which is hardware accelerated. Almost all of KDE is Qt Quick, for example.

Yes, I was considering C++ (and C) desktop UI toolkits. Unlike Qt Widgets, QML/JavaScript is a horrible mess and not suitable for desktop software.

When I'm on Linux, I use KDE exclusively now (although I'm hoping Cosmic replaces it someday). The apps that use QML are fine even on decade old CPUs with absolute shit iGPUs, still better than even absolutely awfully designed WinUI apps.

Re: Deno Desktop

#408

Post by qbane »

teaearlgraycold wrote: post #184
qbane wrote: post #153

Earlier quoted context omitted.

I doubt the benefit. Practically every Electron app on a desktop uses different versions of Chromium and many are very out of date because of the risk of breaking when upgrading.

People build web apps for an array of browsers and huge ranges of versions. I think if you started using some tech to deploy an end user program and knew from the beginning the browser could be updated beneath you it would work just fine. But if you start with a golden version of Chrome and put off updating for too long you’ve let yourself get too comfortable.

You could, but by targeting a specific Electron app the mindset would be much simpler. Just take a look of how many times does the dev behind VS Code decide to upgrade their Electron/Node.js version, and how many breakages due to them.

It is all about unknown unknowns.

Re: Deno Desktop

#409

Post by ai_fry_ur_brain »

lwansbrough wrote: post #88
ai_fry_ur_brain wrote: post #84

Earlier quoted context omitted.

Do you reccomend and resources for building w/ & learning about wasm?

It's all so bleeding edge right now. It also depends how deep you want to go. An increasing number of languages support wasm as a compile target, which is helpful. Bytecode Alliance do semi-regular streams on Youtube. I think reading (recent) material on WASI (0.3) and the Component Model would be a good start. Understanding the relationship between a host and a guest is valuable. Learning what wasmtime is and how it…

Tyty

Re: Deno Desktop

#410

Post by DanielHB »

echelon wrote: post #282
tonyedgecombe wrote: post #86

Earlier quoted context omitted.

In case anybody else wondered CEF is the Chromium embedded framework. https://github.com/chromiumembedded/cef

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…

> It seems great to be able to cut hundreds of megabytes out of your app installer

Your points are valid, but the big upside is that the default system webview is very likely to already be loaded in memory before your app starts. And if multiple apps use the default system webview all of them will load that same dynamically linked binaries only once.

I don think the RAM savings are that significant on modern systems, but it greatly speeds up app first-loading times.

Post reply on HN