Live data from Hacker News

Deno Desktop

docs.deno.com

211–220 of 418 posts

Re: Deno Desktop

#211
post #50

I swear we're just going to end up with Java again.

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).

I have nothing against java. But for some reason in my experience all the developers using it are low quality, and gave it the reputation it has.

Re: Deno Desktop

#212
post #5

I 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.

Re: Deno Desktop

#213
post #72

Earlier quoted context omitted.

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.

Yeah back then a java application could take several minutes to open.

Re: Deno Desktop

#214
I was just today morning thinking about some such idea, for mhtml to be embedded with light weight renderer so it does'nt have to rely on other browser

Re: Deno Desktop

#215

Earlier quoted context omitted.

That is not why people use Electron. The goal is not and never was to just be a "UI toolkit" and "adopting UI patterns from their host OS". Chromium has so much stuff packed into it, its insane. All that utility comes with Electron. And that's a good thing. If you ever worked with video, for example, you know that having the full power of a modern browser in a desktop app is a game changer. Video playback (not to men…

gstreamer is not that complicated

Last time I checked there's a small industry of gstreamer contractors, so it's not that simple.

Re: Deno Desktop

#217
post #176

Earlier quoted context omitted.

gstreamer is not that complicated

It has a really really crappy security record, though.

Those issues are typically from the decoding libraries you choose. Which could even be ffmpeg if you wish. GStreamer just provides a nice high level API.

Re: Deno Desktop

#218
Of all the content they put out I liked the comparison section the most. The last row says iOS/Android - Electron: no, deno: not yet. If they deliver on this it will get much bigger.

Re: Deno Desktop

#219
> deno desktop is opinionated about those tradeoffs:

> Small by default, full Node compatibility

I tried `deno desktop index.ts` with the 5-line Hello world in the article.

Result (Windows 10): 442 MB. Ouch.

I thought it would be smaller than an Electron build, but it's far worse. Did I do something wrong?

(libcef.dll: 247 MB) (deno-test.dll: 78 MB <- contains the hello world)

Re: Deno Desktop

#220

I don't get the point of this. The world is trying to make computers faster and more accessible, more web UI slop isn't going to help that. Dumping Javascript entirely is the first step on that road.

I challenge you to replicate something "simple", like an iMessage-style UI/UX in pure Win32 or WinForms.

The web views are entirely about productivity gains, not technological excellence. I don't know of many who would argue that the web view approach is superior from a purely technical perspective. It is mostly downsides in terms of performance, E2E latency, startup delay, security edges, etc.

Post reply on HN