Hacker News Reader

Comment by patr0nus | Hacker News Reader

Hi HN,

DeskGap is another try to build an lightweight alternative to Electron. Compared to the existing attempts [0, 1], I choose not to go that far and bundle a real Node.js with it[2].

And to battle test the framework, I wrapped squoosh[3] into a desktop app[4] with DeskGap, and successfully submitted it to the app stores.

[0] https://github.com/pojala/electrino

[1] https://github.com/jscherer92/Quark

[2] https://deskgap.com/#faq

[3] https://squoosh.app

[4] https://github.com/patr0nus/Pym/

View on HN

Howdy, can you compare the system-side webview with https://github.com/zserge/webview? Specifically, what control do you use on windows, MSHTML or have you incorporated the recently-freed-from-UWP (I think) Edge API?

EDIT: Appears the latter [0]. Great work. I wonder how this affects bundling...does this make it a UWP app?

0 - https://github.com/patr0nus/DeskGap/blob/master/core/src/win...

No it's still a Win32 app. As you supposed, It's freed from UWP[0] ;).

[0]https://docs.microsoft.com/en-us/windows/communitytoolkit/co...

What happens if you run an EdgeHTML-using application on Windows 7 or 8? I noticed that the EdgeHTML control in WinForms and WPF is not a drop-in replacement for the old WebBrowser control (i.e. it isn’t a subclass, so you must use one or the other, but Microsoft didn’t document the best way to switch between controls based on feature-detection).

When you try to call the API, it will fail as it’s not there. The precise failure mode will depend on the application. One possibility would be to crash outright. Another would be to try the EdgeHTML control, then fall back to MSHTML. Yet another would be to try EdgeHTML, then complain in an alert, notifying the user of the requirement for the new version of Windows.

Looks like a great project!

The webpage mentions the app size, but no mention of RAM usage, which is a bigger concern with Electron apps to me. Can you comment on how it compares?

Based on my experiences of using Safari, Edge and Chrome, the RAM overhead is lower. However as the app gets more complex the overhead becomes irrelevant.

So for now I consider DeskGap a good place for simple apps. But if you start to build something like VS Code, the RAM usage can’t be good, either.

Thanks for making DeskGap!

I have been watching these types of tools (desktop js frameworks) and I'm glad the DeskGap docs[0] explain the difference between existing tools like Electrino and Quark although the most notable difference is that those two projects are no longer maintained.

I just added DeskGap to my list of Awesome Desktop JS frameworks[1].

[0]: https://deskgap.com/#there-are-already-similar-attempts-elec...

[1]: https://github.com/styfle/awesome-desktop-js

It has barely started and still pre-alpha, but I would add revery[0]. I know the team working on it and they have a good history of finishing what they start.

[0] https://github.com/revery-ui/revery

How is Deskgap lightweighter than Electron if, at the end of the day, it's using the browser on my OS (which, let's assume, is Chrome)?

No it would not be. Hopefully Electron will actually do this in some day.

Because if it uses the same browser binary as your other web apps (tabs or other DeskGap apps), the OS can share memory between them. Not possible with electron since every app bundles its own Chromium binary.

That is incorrect. Programs can't share memory just because they've been launched from the same binary.

This is just reusing a DLL and saving disk space thanks to it.

Pretty sure they can on Linux at least.

You are confusing data memory and code memory.

I am not, actually I am pointing out that the comment I replied to does.

Both code memory and data memory will be shared by any modern OS. The code memory will of course be shared since it's the same, and the data memory will be shared until modified. Then that memory page will be copied for the process that changed it (check out copy-on-write).

And then there's disk memory, which isn't as important IMO but still it will of course be smaller since you don't ship the whole browser stack for each application.

Shared memory is "a method of conserving memory space by directing accesses to what would ordinarily be copies of a piece of data to a single instance instead, by using virtual memory mappings or with explicit support of the program in question. This is most often used for shared libraries and for Execute in place (XIP)" according to Wikipedia.

I don't understand why you are talking about launching binaries. The entire point of this approach is to not launch a separate browser instance.

You are patently wrong. The primary advantage of DLLs is shared memory usage:

https://docs.microsoft.com/en-us/windows/desktop/dlls/advant...

Of course they can. This is what OS engineers have spent decades thinking about and optimizing. And then stuff like Electron appears and circumvents all those optimizations. Which is the main reason I dislike it.

Sure, but with sandboxing and technologies such as Firefox Containers, containers in general (such as Docker), and VMs (together with a secure enclave such as utilized in Qubes) it can all be thrown in the trash bin. Its just a matter of time until that's the norm. iOS is already on top of doing sandboxing well.

Are you claiming that when two apps on iOS use a webview, there are 2 copies of the system library implementing the webview in memory?

If not, why are you appealing to iOS to help make your case?

I'm going to avoid installing Windows 10 for as long as possible, so I hope this never takes off. No offense.

Reply on news.ycombinator.com