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

331–340 of 418 posts

Re: Deno Desktop

#331

Post by FooBarWidget »

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…

Web developers already have to deal with different browsers, versions and API coverage.

Re: Deno Desktop

#332

Post by skydhash »

gf000 wrote: post #302
skydhash wrote: post #274

Earlier quoted context omitted.

> You clearly see the issue I don’t. VLC is available everywhere, so your requirement is clearly not a problem. Jetbrains is available on all major desktop OS.

Well, getting a hardware-accelerated blank buffer onto a screen to render video content is hardly the epitome of graphical user interfaces. VLC has very few and basic UI elements. Jetbrains is a better example, using Java with Swing which is not a common choice. As seen from my other comment, I do think this is a good direction, but it ain't any more native than Flutter or for what it's worth an Electron app, none of…

Portable applications is not a recent need. The only requirement is to have a standardize interface and an implementation for each of the platform. Where you put that interface is an engineering skill.

VLC went with QT (which has done all the hard work) for the UI, and their own libraries for the media playing part. Other software like Emacs and sublime has implemented their own UI libraries. Some just ship libraries and others build UI for them.

The issue with Electron is that it brings a whole jungle and a gorilla holding the single banana that the devs actually need. And the dev flung the whole thing at the users. It's like establishing an iron mine, a steel factory and then pollutes the whole region when building a quick stone bridge would do. Because the only thing you know are suspension bridges.

Re: Deno Desktop

#333

Post by koolala »

rbits wrote: post #178
koolala wrote: post #141

Earlier quoted context omitted.

No customizable programmable browser runtimes exist for those.

What do you mean by that? Does this[1] not count? [1] https://capacitorjs.com/

Correct, that isn't a browser it uses a webview. The limited webview version of Deno Desktop could work like that on phones.

Re: Deno Desktop

#334

Post by NekkoDroid »

Lucasoato wrote: post #163
leleat wrote: 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...

Both Steam and Battle.net use CEF for their UI as well. And IMO they are on 2 ends of the "nice to use" from the implementation side (Steam being a sluggish hell and B.net being nice). Though then again B.net is only for Blizzard games, so they can also optimise for the limited set games.

Re: Deno Desktop

#335

Post by hbn »

mohsen1 wrote: post #191
lillesvin wrote: post #6

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

In practice it's much harder to maintain a native app. I am noticing this with ChatGPT Mac app vs. Codex Mac app. ChatGPT on Mac is constantly behind compared the web ChatGPT while Codex is shipping features at a much higher velocity. Also ChatGPT hangs and has more weird bugs compared to Codex.

The issues with the ChatGPT Mac app could also be reflective of the state of Swift UI considering not even Apple themselves can ship Swift UI apps that aren't janky.

https://daringfireball.net/2026/06/swiftui_only_makes_it_eas...

Re: Deno Desktop

#336

Post by vintermann »

p-e-w wrote: post #192
vintermann wrote: post #77

Earlier quoted context omitted.

Yes, if there's one lesson from historical UI research that still holds, it's that mode switching is expensive. That's why people install vi plugins everywhere. Wait...

Vi plugins don’t even exist for the vast majority of applications.

The last resort is to switch to ROU mode (key combo for entering it is :wq)

Re: Deno Desktop

#337

Post by EddieRingle »

clumsysmurf wrote: post #90
olcay_ wrote: post #85

Earlier quoted context omitted.

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.

Compose UI apps can be compiled to native binaries already, via Kotlin's LLVM backend, though at the moment only the macOS/iOS targets have proper (official) support. Last I looked (a few years ago now), the Linux and Windows targets shouldn't be too far off, since it's all built on top of Skia already, someone just needs to care enough to put in the work. (But since right now you already get coverage for all platforms between JVM and Wasm, not to mention hot reload support on the JVM, there's little motivation to do so.)

Re: Deno Desktop

#339

Post by nicoburns »

fireant wrote: post #328
nicoburns wrote: post #245

Earlier quoted context omitted.

> I've always wanted to build a direct-browser integration that could use HTML+CSS for the layout, but avoids needing a JS runtime. Idk how lightweight servo is but one day I hope I will see my idea come to light Blitz ( https://github.com/DioxusLabs/blitz ) is exactly that. It's a new custom browser engine supporting standard HTML/CSS with a native Rust API (and optional integration with Dioxus which is a React-like…

That's really nice. It would be really good for game GUIs too where the situation is quite poor and would work well with underlays/overlays/worldspace UIs. That said while binary size may be around 10mb, it still baloons to 500mb at runtime for your TODO list example which is more than some electron apps.

Yeah, the RAM usage is quite high atm. The good news is that it's almost all the rendering layer (WGPU+Vello). So if we can make the renderer more efficient then it's likely we can bring that down. There is also some low hanging fruit in the DOM implementation (but I think that's only actually causing a few 10s of MB of usage).

I would also note that native toolkits (SwiftUI, etc) tend to also use at least ~100mb RAM these days. A lot of that is unavoidable if the app is actually visible, due to modern screen resolutions being so high.

Re: Deno Desktop

#340

Post by bigstrat2003 »

boofus wrote: post #224
preommr wrote: post #201

Earlier quoted context omitted.

I will die on the hill that Java was a good language, and had the potential to leapfrog us from where we are by at least a decade. But it got hobbled by the awful, awful enterprise style culture, cultural misunderstanding of OOP (especially inheritance), and corporation shenanigans (fucking oracle).

Java may be good, but it's boring. No joy comes from programming in Java. I need to enjoy my work to be engaged and productive.

That is a matter of taste. I enjoy programming in Java just fine.
Post reply on HN