I swear we're just going to end up with Java again.
Java would be a killer platform if they shipped built-in, tauri-like, UI.
Deno Desktop
81–90 of 418 posts
Re: Deno Desktop
#82Earlier quoted context omitted.
Try dioxus, it has live reload but it's a work in progress.
Dioxus seems to be 'just' another way to generate HTML on the desktop. Electron but Rust? Is there a legitimate upside there?
With Dioxus, program logic compiles to native code instead of running it through a JS engine, and it ships its own HTML renderer (Blitz) instead of bundling a whole browser. So it's a lot more lightweight and performant than Electron.
As a minor bonus, the live-reload is also faster than what frameworks like React do. It truly has subsecond latency, which isn't exactly a game changer but is nice when iterating on visual details of an app.
Re: Deno Desktop
#83Earlier quoted context omitted.
ironically the only group of users I've found that actually care about native UI, are other developers and Mac purist.
I have seen users having trouble with pixel soup UIs. They may not think "This should be in a native toolkit", but they do think "How the hell do I subscribe to a folder in the new Outlook?".
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.
Re: Deno Desktop
#84Similar 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.
Do you reccomend and resources for building w/ & learning about wasm?
Re: Deno Desktop
#85Re: Deno Desktop
#86> 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…
In case anybody else wondered CEF is the Chromium embedded framework.
Re: Deno Desktop
#87[flagged]
Re: Deno Desktop
#88Similar 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.
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 works is also illuminating: https://docs.wasmtime.dev
Re: Deno Desktop
#89I swear we're just going to end up with Java again.
At this point I think that would be a more sane outcome than whatever it is we have right now.
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.
Re: Deno Desktop
#90Earlier 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 and AOT compiled binaries would be amazing (GraalVM Native Image kinda thing) but it doesn't look very easy at the moment. Leyden with a regular JVM might be the best we get.