Live data from Hacker News

Show HN: DeskGap – Like Electron, but uses the system webview

deskgap.com

21–30 of 268 posts

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#21
I find it amusing that the opening paragraph describes it as a "framework for building cross-platform desktop apps" and then shortly below that in the "Supported Platforms" section it lists one Mac OS and one very specific version of Windows. No Linux at all. Even native Windows apps are more cross-platform than that! (I have written a few which will work on any version of Windows starting at Win95...)

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#22
post #5

These projects completely overlook _why_ people choose Electron over the system view. - Nobody wants to be testing against multiple browser/rendering engines in 2019. - Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately. Edit: Since I can already see the litany of armchair-quarterback-desktop-app-authors, I'm just going to link to the comment from…

The Slack dev you're quoting doesn't mention any of your points. His points were that the native extension API was clunky (DeskGap could improve upon this), that users of old OS versions are completely left out in the cold for updates (he mentions severe UI bugs, which is very different from "we need bleeding-edge Chrome features"), and that the difference would be negligible anyway since the poor RAM and CPU usage is from their own garbage JavaScript code anyway, not the browser engine.

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#23
post #5

These projects completely overlook _why_ people choose Electron over the system view. - Nobody wants to be testing against multiple browser/rendering engines in 2019. - Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately. Edit: Since I can already see the litany of armchair-quarterback-desktop-app-authors, I'm just going to link to the comment from…

> Nobody wants to be testing against multiple browser/rendering engines in 2019. That's why DeskGap uses EdgeHTML on Windows. With toolchains such as webpack and babel, building an app that runs on WebKit and EdgeHTML (which is going to be replaced by Chromium[0]) can't be that hard. > Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately. DeskGap do…

> That's why DeskGap uses EdgeHTML on Windows

Strangely, that would likely make it most conformant on Windows. I can't imagine that KHTML is up to date in terms of specifications (but I could easily be completely wrong about that) and Apple/Safari is taking tips from Microsoft during their IE days.

It would seem that the platform differences would be quite large, but at least the JS engine would be consistent.

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#24

I find it amusing that the opening paragraph describes it as a "framework for building cross-platform desktop apps" and then shortly below that in the "Supported Platforms" section it lists one Mac OS and one very specific version of Windows. No Linux at all. Even native Windows apps are more cross-platform than that! (I have written a few which will work on any version of Windows starting at Win95...)

I shared your concern before I started the project, and talked about this in the readme's FAQ[0].

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

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#25
post #5

These projects completely overlook _why_ people choose Electron over the system view. - Nobody wants to be testing against multiple browser/rendering engines in 2019. - Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately. Edit: Since I can already see the litany of armchair-quarterback-desktop-app-authors, I'm just going to link to the comment from…

Also, Electron provides things like single command building, automatic updates and menu bar support (which looks supported in DeskGap).

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#26
post #11
post #2

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://d…

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.

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#27
post #2

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://d…

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.

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#28
post #7

Earlier quoted context omitted.

> Nobody wants to be testing against multiple browser/rendering engines in 2019. That's certainly _one_ reason why. I would posit that the main reason is that web developers would like to reuse their webapp skillset for building desktop apps. This seems like it accomplishes the goal. Re: testing against multiple browsers, frankly this is _mostly_ a solved problem. The big gaps between rendering engines is on the real…

It is not a mostly solved problem. The people behind Slack, Spotify, and so on have actually commented on these threads explaining the exact line of reasoning. This stuff isn't limited to just CSS, and it makes total business sense to avoid it.

I don't consider Slack and Spotify to be good at making applications (despite their popularity). These are the least efficient chat app and least efficient music app ever, in a multi-decade history of chat and music apps, which didn't have the overflowing abundance of convenience and productivity offered by Electron.

(This is like the obviously silly quote "we lose money on every sale, but we'll make it up in volume!" translated into "this rich environment and set of libraries enables such amazing developer productivity that we can create much better optimized user experiences!" while the laggyness and flakyness and huge memory use are just never optimized away with that productivity.)

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#29
post #3

Earlier quoted context omitted.

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

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.

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#30
post #5

These projects completely overlook _why_ people choose Electron over the system view. - Nobody wants to be testing against multiple browser/rendering engines in 2019. - Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately. Edit: Since I can already see the litany of armchair-quarterback-desktop-app-authors, I'm just going to link to the comment from…

Then again, the Slack app segfaulted on launch for months because of a node.js incompatibility with newer glibc. So I guess what you've traded for is

- Nobody bothers to be testing against multiple operating systems in 2019.

- Everybody gets to wait for Slack to get around to it while the system webview gets the compatibility update almost immediately.

Great for the authors, shit for the users. On the bright side, it was the straw that broke the camel's back, and my org doesn't pay Slack any more.

Post reply on HN