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

411–418 of 418 posts

Re: Deno Desktop

#411

Post by DanielHB »

lwansbrough wrote: post #91
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…

Web devs are used to their target being evergreen, so I suppose you could opt in or out of that model: "just give me what you got".

Oh god I feel OLD reading this.

Re: Deno Desktop

#412

Post by baliex »

This is pretty cool, I have an interest in running admin interfaces (think web CMS) for non-technical users locally.

I tried out the most basic possible example, from the linked page:

    Deno.serve(() => new Response("Hello, desktop", { headers: { "content-type": "text/html" }, }) );
It worked, after a little wrangling to get a 2.9 preview (deno upgrade canary). Amazing! So, so, so simple!

There's a downside though... that "Hello, desktop" app weight in at 308MB on macOS.

Now, I don't know how that compares to an electron app, or the most lightweight app possible handcrafted specifically for macOS, and there are many, many layers of abstraction between my 1 line of code and the resultant but that is enormous!

Re: Deno Desktop

#413

Post by shunia_huang »

c-smile wrote: post #308
echelon wrote: post #276

Earlier quoted context omitted.

> I'm happy to see this I see that this provides CEF, Webview and Raw They beat Tauri at their CEF support. Webviews are a mistake in most cases. They're too platform-specific, and certain Webviews (Safari/Webkit) are buggy as hell, making platform support a nightmare. (Linux, ironically, is even worse due to how underbaked webviews are on the major desktop Linuces - Tauri is barely functional on Linux.) Deno Desktop…

I think that my Sciter is better option when you need HTML/CSS/JS native application running on Windows (XP and beyond), MacOS and Linuxes. Sciter SDK [1] contains scapp[.exe] - standalone Sciter engine that can be attached to HTML/CSS/JS bundle making standalone (single exe file) and portable executable. https://quark.sciter.com/ tool allows to compile such apps. Size of "hello world" is a size of scapp.exe binary +…

While I'm trying to take a test it seems too much to start a Hello world application, or just to bundle my existing "dist" folder of a part time project.

Is it possible to install some tool, and give it a "dist" fold path and the application is generated all alone?

I'm stupidly lazy, and I hate work with graphical UIs to start a project and input that many fields, make me feel like visiting a 1990 web page requires me registering with tons of information and most of them are useless or at least I can provide later if needed.

Re: Deno Desktop

#414

Post by lmm »

wolvesechoes wrote: post #400
lmm wrote: post #399

Earlier quoted context omitted.

The OS-component-oriented approach was defensible in the days of desktop only (though personally I think it was a mistake even then), but it's not sustainable now. People want your app on their PC to look and behave like your app on their phone (whichever combination of PC and phone they happen to have), and that's a lot more important to them than having it look and behave like other apps on their PC.

> People want your app on their PC to look and behave like your app on their phone (whichever combination of PC and phone they happen to have), and that's a lot more important to them than having it look and behave like other apps on their PC. They don't. No one generates GBs of simulation data and create plots on their phones, and this is what "app" I am working on is doing.

Many times I've thought "what kind of idiot would try to use our app on a phone?" only to find one of our execs was doing exactly that, but YMMV I guess.

Re: Deno Desktop

#415

Post by dominicrose »

josephernest wrote: post #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)

With Visual Studio and Photino, after some tweaking I managed to publish everything in a single .exe file. In Debug mode it produces more files to have source maps that work well. There's no hot-reload but at least it works well.

The Photino app is 18 Mb and it's a real app not a hello world. I'm not sure how much RAM it used since maybe it uses a secondary process (edge webview).

I tried deno desktop with the minimal js file to see if I can avoid relying on VS and C# but it's really bad currently, at least on Windows.

Both the webview and the cef backend produce multiple files and are we supposed to launch a .bat file? It opens a terminal Window (what the hell?) and a UI that doesn't even work. I got to see the Hello message in cef mode but the unicode emoticon doesn't work.

Re: Deno Desktop

#416

Post by conductr »

InsideOutSanta wrote: post #366
conductr wrote: post #285

Earlier quoted context omitted.

15% of devices is not 15% of users. From my own experience having a web app that is 99% desktop windows users, why would I care about safari?

Well, if your app doesn't run on Safari, you're not going to have any users on Safari.

My logs tell me what they try to use. It’s not safari. Also they are paying users and would tell me if it didn’t work on their browser. The demographic I target is 99%+ Windows users.

Re: Deno Desktop

#417

Post by josephernest »

undefined_void wrote: post #229
josephernest wrote: post #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)

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

This gives a 77 MB folder, not containing the browser (we're now using the OS' webview).

I wouldn't call this "Small by default".

I used this main.ts file: `Deno.serve(() => new Response("Hello, desktop", { headers: { "content-type": "text/html" }, }));`

and `deno desktop --backend webview main.ts`.

Unfortunately, launching `deno-test.bat` opens an empty white window, freezed (with waiting cursor...) on my Windows 10.

Re: Deno Desktop

#418

Post by [deleted] »

eric-p7 wrote: post #325
doodlesdev wrote: post #309

The overall feature seems really solid, but I'm impressed they couldn't reduce the average package size further from 40MB even when not using CEF. I guess that wasn't a huge focus when developing this feature? Tauri and Dioxus can easily hit less than 5MB for package sizes. I find the feature matrix comparison to be extremely well done and the sections beneath explaining advantages and disadvantages to be some of the…

Deno Desktop is bundling the V8 JavaScript runtime so it can have JavaScript on the backend. Tauri uses rust for the backend and your browser's JavaScript engine for the frontend.

[deleted]
Post reply on HN