Live data from Hacker News

Deno Desktop

docs.deno.com

291–300 of 418 posts

Re: Deno Desktop

#291
post #284

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…

I use Wails which is Tauri but for Go and I don't have the kind of issues you're mentioning. Maybe that is a difference between Wails and Tauri but I don't think the system WebView is a significant factor.

Are any of your Mac users using an 10-year old WebView? We frequently ran into that. And there's nothing that can be done about it except engineering around it.

I also doubt it works well on Linux. The performance of webkitgtk is like running an emulator inside an emulator.

Re: Deno Desktop

#292

Earlier quoted context omitted.

The problem in these usability cases is pretty much always layout and constant redesigns rather than the exact theme the button has. I've seen plenty of unusable native ui soup UIs and very clean and simple custom UIs.

You could call it the exact theme when a clickable UI element looks just like regular text (it was not inside any kind of button-like shape in the Outlook case that I saw), but it's super common to have that in web-based UIs.

(And of course, nobody changed any theme in the outlook case)

Re: Deno Desktop

#293

I think the last time I tried Deno for desktop it didn't allow for fullscreen webview apps. that was a showstopper for our kiosk apps. I'll have to revisit that issue and see if it's resolved now. I'm glad to see Deno continuing to march on.

You may have played with a 3rd party/unofficial solution or similar in the past as Deno Desktop has only just now become available in the Canary branch.

Re: Deno Desktop

#294
post #175

Earlier quoted context omitted.

We were writing and shipping desktop applications with it back in the nineties. Although many of the arguments against it were similar to the arguments against Electron today.

I think the UI look and feel was very ugly for many users and that caused its demise. The cross platform skin was ugly. The native skins were in the uncanny valley. The framework was reasonably good for its time. By the time good looking UI frameworks came, the bad reputation was already set.

I think SWT was the best option if you wanted native controls.

Re: Deno Desktop

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

There’s no running TS. Everyone executes JS.

Also TS itself is going towards stripped types. There’s this proposal which might land on browsers some day:

https://tc39.es/proposal-type-annotations/

And in preparation you can use this setting on your tsconfig:

https://www.typescriptlang.org/tsconfig/#erasableSyntaxOnly

Re: Deno Desktop

#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 must be IPC? Maybe the claim "shared memory space" is more an architectural description than an OS-level claim?

Re: Deno Desktop

#297

Earlier quoted context omitted.

Try the webview backend: `deno desktop --backend webview`

The docs say that's the default: https://docs.deno.com/runtime/desktop/backends/#webview-(def...

apologies, this is inaccurate currently, will get things updated

Re: Deno Desktop

#298
post #36

Earlier quoted context omitted.

They really did their best comparing it with other tools here https://docs.deno.com/runtime/desktop/comparison/

RE: Tauri not having cross-compile... There's a GitHub action that compiles for Linux, Windows, and Mac. So practically it does have it, just not out of the box.

Practically that's just the ability to generate binaries for more than one target. "Cross compiling" is specifically that ability without having to invoke a separate external environment to get the additional targets.

If cross compiling were really just about the result rather than the means, what would the difference be between that and normal support for multiple targets?

Re: Deno Desktop

#299

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…

Regular Tauri app (aptakube) user on linux here: the experience is very adequate and smooth, I have no complaints. Speed benefits relative to Electron (similar app: K8S Lens) alone are enough to deal with many possible issues.

Could be attributed to app developers going the extra mile, but I suspect it's the framework choice.

Re: Deno Desktop

#300
post #3

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

> UI patterns from their host OS I genuinely wonder who ever want that, and what apps those people use on their PC. Can you imagine, for example, Blender Foundation says that their next goal is to make Blender's UI look more like the host OS?

I have used Blender just a bit, but it was very jarring when I first opened it and discovered that it has its own menu bar within the window, rather than at the top of the screen. It has its own save/open window rather than using the system-provided one, as nearly all truly native Mac apps do. I doubt most Mac users like this.

I have somewhat more experience with QGIS. It has a standard Mac menu bar, but the icons are inelegant and Windows-ish, window layouts are Windows-ish, dialogs don't behave correctly in Mac full screen mode. It could use a MacOS glow-up.

I think Visual Studio Code (native menu bar, native save/open, but a core UI kind of unto itself that is consistent across Mac and Windows) does a better job of balancing cross-platform vs native.

And then there's the approach taken by Adobe and Microsoft Office. These apps do a much better job of adopting native platform appearance and conventions (sometimes at the expense of application consistency across platforms).

Post reply on HN