Live data from Hacker News

Deno Desktop

docs.deno.com

161–170 of 418 posts

Re: Deno Desktop

#161

Similar to something I'm working on for games: https://jumpjet.dev WASM you can bundle for Windows, macOS, Linux, Android, iOS and web. Unlike Deno Desktop, it doesn't rely on a browser engine.

Just FYI, when checking out jumpjets homepage, the white-dot airship in the background made the white text in the hero banner hard to read.

Cool project!

Re: Deno Desktop

#162
post #37

As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.

We spend a lot of time using different browsers. As far as I know there no web engine that use native OS UI for rendering.

Isn't all uses native OS UI widget? But since the brand need to be experienced the same across platform, it overrides the native rendering and use custom styles instead.

Re: Deno Desktop

#163
post #66

> Shared CEF runtime across apps. Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roadmap. This[0] sounds interesting. I am not familiar with CEF, so I wonder how the versioning works. When different apps require different versions of CEF, do we just essentially end up with the electron model where every app bundles their own browser (just sli…

Just to let you know, CEF was used for Riot and League of Legends client as well [0]. The results haven't been nice, but I'm not aware if this was a problem with the CEF technology itself or other component/processes are to be blamed.

[0]: https://www.riotgames.com/en/news/architecture-league-client...

Re: Deno Desktop

#164
> Backend and UI communication goes through in-process channels, not socket-based IPC

Are they running the frontend and backend in the same process? Sounds a bit dangerous security-wise?

Re: Deno Desktop

#165
post #37

As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.

We spend a lot of time using different browsers. As far as I know there no web engine that use native OS UI for rendering.

> As far as I know there no web engine that use native OS UI for rendering.

That sounds like a monster I would be afraid to touch.

Re: Deno Desktop

#166
post #164

> Backend and UI communication goes through in-process channels, not socket-based IPC Are they running the frontend and backend in the same process? Sounds a bit dangerous security-wise?

How can in-process channels be more dangerous than a socket-based IPC? The frontend still goes through the "secure" JavaScript engine AFAICS.

Re: Deno Desktop

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

Tauri is getting traction in the meantime.

A non-native UI has some issues, but also one clear advantage - it is easier to make a cross-system app with the same looks.

Re: Deno Desktop

#168
I watched traditional GUIs for a while and used many of them, mostly via ruby as wrapper, sometimes also via java. I finally reached the conclusion not too long ago, that web-apps are the only real alternatives now. Too many things do not work when it comes to traditional desktop applications. There are even regressions, e. g. ruby-gtk4 barely works for me. And there is no real support for any problems really. People make fun of e. g. electron "soooo big so bloated", and WebAssembly is still not really in any breakthrough after almost 20 years. But traditional desktop apps are also even more dead. So I'll have to add JavaScript/TypeScript/Node now simply because there are no real alternatives to this anymore. I'd wish we would have a real "write once, run everywhere"...

Re: Deno Desktop

#169
post #115
post #55

Earlier quoted context omitted.

Which native framework? Even in a "post-vibe code" era I wouldn't want to create multiple versions of the same app, and none of the "platform-native" GUI toolkits run on everything. SwiftUI is apple-only, gtk has pretty bad compatibility on non-linux, qt is decent but requires C++ or python, and even so still not much for mobile. Don't even get started on "Windows frameworks", because as I write this sentence they ma…

> if you want a truly universal UI Right. If you want your app to look the same, custom way, ditching what the OS has to offer. Some developers still believe an operating system has useful UI components and patterns worth adopting. From this thread it's clear that there's plenty who don't. Personally I view that as a regression.

Probably many Electron users also view that as a regression, but a tradeoff worth making.

Re: Deno Desktop

#170

I watched traditional GUIs for a while and used many of them, mostly via ruby as wrapper, sometimes also via java. I finally reached the conclusion not too long ago, that web-apps are the only real alternatives now. Too many things do not work when it comes to traditional desktop applications. There are even regressions, e. g. ruby-gtk4 barely works for me. And there is no real support for any problems really. People…

Odd because I'm wrapping up an app that uses Xaw. It should run on the billion or so machines that support X11
Post reply on HN