This is something that can bring me back to Deno. Binary size is still pretty big IMO. If they can trim down runtime based on the specific uses of standard library (sort of treeshake Deno runtime itself), it would be revolutionary. Java promised this with `jlink` but sadly failed to deliver for wider adoption.
Deno Desktop
371–380 of 418 posts
Re: Deno Desktop
#372Why this and not rust or go?
Re: Deno Desktop
#373Why this and not rust or go?
That would give us efficient desktop apps that don’t need a JavaScript runtime.
Re: Deno Desktop
#374Why this and not rust or go?
Literally the first question in TFA.
Re: Deno Desktop
#375Earlier quoted context omitted.
You are running a binary that you got from the developer. If it presented you with Deno permissions, I think that would be misleading because there’s no guarantee of their integrity.
That is true. I wonder if it could be possible to let the user supply and wrap the app around their own, trusted installation of Deno (rather than the one bundled in the app) to specify permissions.
Why not run it in a vm or container instead then, it seems a bit much imho.
Re: Deno Desktop
#376Earlier 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…
This point of view always confuses me, because web developers already need to deal with platform differences. Especially if your app app also runs in a browser, like Slack and Discord — at that point, what issues do the differing system webviews cause that you don't need to deal with anyway just targeting browsers? It's also funny to me as someone who's been building websites for 20+ years at this point, because the…
The platform webviews are significantly older/worse than typical web browser versions, especially on macOS and Linux.
On macOS, the only way to upgrade your WebView is to upgrade your OS, which requires rebooting. Lots of people just don't bother. You can upgrade to the latest Chrome or Firefox just by downloading it (assuming they support your macOS version), and they auto-upgrade themselves pretty aggressively.
On the web, very old versions of Safari (6+ years old) are a tiny fraction of a percent of your traffic; many web developers just ignore them. In a desktop app based on a WebView, ancient WebViews can be as high as 10-15% of your macOS user base. Ignoring them is not an option.
On Linux, it's common for the major version of WebKitGTK to not upgrade at all except during major OS upgrades. Anyone on Ubuntu LTS 20 is going to have a 2020-vintage WebKitGTK with security patches. (And Ubuntu LTS 20's WebKitGTK was buggier than macOS WebKit, even in 2020, because Apple has more dedicated full-time developers and testers making sure that macOS WebViews work end-to-end.) If you're shipping an app based on WebKitGTK, you can expect to see double-digit percentages of your Linux users running really old WebKitGTK.
Maybe you're such a great developer that your web app works great on ancient browsers, but, if so, it's probably because you didn't need/use much JS in the first place. (Maybe you used HTMX or something.) In that case, is there even any benefit in shipping a "desktop app"? What's your desktop app even for? Offline support? (But your app is all server side…?)
If you have a JS-intensive app that works great on ancient, buggy browsers, then platform WebView might work for you. It's not nobody, but it's hardly anybody.
Re: Deno Desktop
#377> Web technology is the most widely-known UI toolkit in the world. Poor choice of words there IMHO. The reason Electron apps get a lot of flak is because they are everything _but_ a UI toolkit. They consistently miss the mark in adopting UI patterns from their host OS. Web tech is just web tech. Yes it will allow you to render a button, but even unstyled, the button won't necessarily look native to the OS, and will v…
At this point the only OS with a consistent look and feel at all is Mac. For the other OSes, I don't even know what a "native" look and feel would be. And most apps have their own branding and style they want to tout anyway. So I don't think "apps should look native" is the leading reason to not use Electron. For me, the leading reason to use Electron is the fact that I already have a browser running so why not just…
> At this point the only OS with a consistent look and feel at all is Mac.
Apparently, NOT! Apple's controversial Liquid Glass UI disrupted their long-standing Human Interface Guidelines by prioritizing cinematic aesthetics (transparency, refractions, and blur) over core tenets like readability, contrast, and content deference. Critics highlight that transparent, light-bending panes frequently clash with underlying wallpapers or videos, causing text and buttons to become illegible. This is a HOT topic in recent WWDCs and amongst UI designers.[1]
[1] https://blog.prototypr.io/why-apples-liquid-glass-design-is-...
Re: Deno Desktop
#378Earlier 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…
This point of view always confuses me, because web developers already need to deal with platform differences. Especially if your app app also runs in a browser, like Slack and Discord — at that point, what issues do the differing system webviews cause that you don't need to deal with anyway just targeting browsers? It's also funny to me as someone who's been building websites for 20+ years at this point, because the…
Yes, we're used to platform differences, but that's kind of the benefit of shipping a desktop app, isn't it? So that we don't have to deal with the platform differences. If you bundle the browser, then that ought to all go away. No graceful degradation necessary, no polyfills.
Re: Deno Desktop
#379I was wondering how this integrates with Deno's permission system, which is one of its biggest strengths especially for letting agents run amok on your device. The CLI reference page[0] notes, > The permissions you grant at compile time are baked into the compiled binary: I think it would be nice if this could be surfaced to the user somehow, like letting the user know and decide which permissions they want to give a…
You are running a binary that you got from the developer. If it presented you with Deno permissions, I think that would be misleading because there’s no guarantee of their integrity.
Then do `deno ./my_downloaded_deno_gui` instead. If you trust the copy of deno you downloaded, then hopefully it can be trusted to verify the permissions of random downloaded deno-apps.
Yes, it kind of defeats the standalone binary aspect but if you're really concerned about security, maybe it's a happy medium.
Re: Deno Desktop
#380Earlier 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…
Tauri's cef-rs is indeed quite good. I think it's available, ready, works: it's just that there aren't many folks using Tauri and only a fraction of them are aware/interested in exploring further. https://github.com/tauri-apps/cef-rs
Huge fan, this should definitely be the default. The user experience is incomparable.
One thing I'd like to verify: can the OS effectively use shared mem for cef across multiple different cef-rs apps? I really hope so. In this time of RAM being scarce, this optimization could be such a benefit.