
Show HN: DeskGap – Like Electron, but uses the system webview - patr0nus
https://deskgap.com/
======
disillusion
I think it's interesting how debates about Electron inevitably end up with the
arguments 'the developer wants X' vs 'the user wants Y'. However, there's one
aspect a lot of people seem to overlook in their arguments: pragmatism.

The ideal application:

\- uses almost no memory

\- uses almost no disk space

\- is extremely fast

\- costs (next to) nothing

\- and has all the features in the world

\- presented in a manner that automatically shows the user only the exact
features (s)he cares about

In the real world, we have to balance the project/product requirements. In the
end, only these things matter:

\- It yields a net profit (monetary or otherwise) for the company or owner

\- It has (and keeps) added value in comparison to similar software

\- It's fun to design and develop in/for

\- It has bugfixes and new features in a timely manner, without taking up too
much development time

\- It has a pretty, easy to use interface

\- It's quick and snappy enough to run

Adding that all up, and developing in something like Electron is a no-brainer:
mean time between iterations is faster, design and development is more fun and
the end user has a product that is fast enough for their needs packed with
features. Try that in any low level language or without control over the
engine and you'll have to severely hamper one of these goals.

~~~
fxfan
> snappy enough to run > Electron is a new brainer

Not everyone on earth is a dev/gamer/video-editor. For regular people,
electron is a cancer that needs to be nipped in the bud. Remember, 91% of the
desktop on earth is Windows (meaning regular USD 300 machines). And of them
I'd wager less than 10% fit have machines where electron is snappy (1.2K
Thinkpads).

What the earth needs is a better cross platform native GUI framework. NOT
electron.

~~~
w0utert
_> > What the earth needs is a better cross platform native GUI framework. NOT
electron._

I always like to use VSCode as an example. It's a tool a use on a daily basis,
and I like almost everything about it. It's also a poster-child for a good
Electron application, maybe one of the best around. Add to that I completely
understand why it was made using Electron, and why it might not have existed
in this form (available, up-to-date, and feature-complete on all platforms,
regularly improved, etc) at all if it wasn't because of Electron.

But it's not.snappy.enough.

Even though large performance-sensitive parts of it like the editor buffer
data structures etc are (AFAIK) implemented natively, the whole user
experience is actually quite bad. It's sluggish, inconsistent, it's full of
random glitches, and everything feels like an insane amount of effort went
into putting more and more lipstick on various parts of a pig to hide that the
whole thing is like a house of cards and sluggishness and instability hides
around every corner.

I feel a little sad that so many developers defend Electron so vehemently,
pretending that it's 'ok', 'fine' or even 'very good' for end users, because
it's not. I fully agree it's great for the people (and mostly the companies
making money off the people) who develop commercial stuff with it, because it
obviously saves a shit-ton of money if you want to deploy something across the
3 major platforms.

All of this is completely unrelated to the end-user experience though, who
typically uses just one platform at a time and couldn't care less if the
application they are using is also on some other platform. Or if they use it
across multiple platforms, how many extra UI devs where needed to make native
UI's for each of them.

Any developer who knows how freaking fast modern computers are and why should,
when completely honest, should feel ashamed that something like Slack or
VSCode is made in a way that makes it so sluggish and memory-hungry, and that
we now all accept this because it's cheaper to develop that way, and the
applications are (supposedly) 'snappy enough to run'

~~~
markn951
>But it's not.snappy.enough.

I was following you until this line... In general I agree about Electron
though probably not to the same degree as you. But for me VSCode runs
amazingly well; I think the only thing that tops it is Sublime (and I vastly
prefer VSCode's interface and features). Not saying that what you said isn't
your experience, but you should know it's not everyone's experience.

~~~
arghwhat
VSCode is worlds faster than Atom. However, relative to any native editor
(Sublime Text, Gedit, GVim, Notepad++, Notepad itself, ...), VSCode ranges
from anywhere between "sluggish" to "... is it frozen?". Now, I agree that how
big the difference is, and how big a problem that becomes is subjective, but
the presence of the difference itself is not.

A good example being opening a new window. This is something I do semi-often
to edit something out-of-context that shouldn't taint my current workspace.
Under anything from Notepad to Gedit or Sublime Text, this task has no
perceivable latency. Under VSCode, however, it is so uncomfortably slow that I
actively try to avoid it, and instead use Gedit for these editing tasks. This
is a significant downgrade in workflow compared to Sublime Text.

So, why do I use it? Well, features. However, what must be made very clear is
that _none_ of the features I use in VSCode exist as a result of Electron.
Terminal panes and the better Go/Rust integration has nothing to do with
Electron, and are within areas of difficulty that I could have added it myself
over a weekend had Sublime Text been open source. But it's not, so I can't.

Electron is cancer.

~~~
pault
I wish we could stop calling software we don't like "a cancer". It's hyperbole
and detracts from the conversation, IMO. The phrase "x is a cancer" is a
cancer. :)

~~~
arghwhat
s/is cancer/is an awful framework that significantly and irreparably degrades
user experience, stability and performance of any application written with
it/g

I find the term to be quite fitting here. The use has spread to an absurd
degree, meaning that there is a large change that everyone is running one or
more instances of this framework at any given time, and use of this framework
not only harms UX, but also brings down the machine it runs on through
resource consumption. Well, maybe "pandemic disease" is better than "cancer".

When everything uses something like Electron, you the ability to simple chose
to avoid it. Like a disease, Electron is that you involuntarily get subjected
to, and as such, would prefer to see eradicated.

(And yes, yes, we should improve the experience of making cross-platform
native apps, but due to Electron, no one is even trying anymore outside of
mobile.)

------
patr0nus
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](https://github.com/pojala/electrino)

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

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

[3] [https://squoosh.app](https://squoosh.app)

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

~~~
kodablah
Howdy, can you compare the system-side webview with
[https://github.com/zserge/webview](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...](https://github.com/patr0nus/DeskGap/blob/master/core/src/win/webview.cpp)

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

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

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

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

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

~~~
jgillich
The majority of Linux users use a GTK desktop, IMO WebkitGTK would be
preferable.

~~~
Fnoord
I use a GTK desktop on my Linux desktop computers (Ubuntu/Debian and Kali).
However, I prefer Qt applications. They look very well on my GTK desktop.

------
wolframhempel
I'm glad to see how this debate has matured from focusing on the technical
downsides to focusing on the business and end-user benefits. But at the same
time, whenever I have Blender open, effortlessly displaying eight different 3D
views and UV mappers and the Spotify app, almost crashing my system by playing
music, I can't help but wish that more developers would walk the extra mile
for the user experience.

~~~
vianneychevalie
Some of the apps like Spotify, or more recently Microsoft Teams are completely
equivalent in their web version. The browser is better at preventing system
crashes from a tab than a single encapsulated web app.

------
Klonoar
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 guy who actually
migrated Slack away from WKWebView.

[https://news.ycombinator.com/item?id=18763449](https://news.ycombinator.com/item?id=18763449)

Blows my mind we're still debating this.

~~~
mch82
> Nobody wants to be testing against multiple browser/rendering engines in
> 2019

Yes, lots of projects want multiple, competitive rendering engines.

It used to be that Windows was the only viable target OS for commercial
software. Firefox and Safari gave IE competition and gave developers who
wanted to target Mac and Linux a way to get a foot in the door. That kicked
off the whole generation of web apps we’ve just lived through. If developers
give up on Gecko and WebKit, then they allow a monopoly again. And since
Electron is made by GitHub and is now owned by Microsoft, Microsoft will again
have the monopoly (with the caveat that Google has primary influence over
Blink).

Render engine competition keeps web standards relevant, which keeps the web
open. Take away competition & we’ll be back in a world where people build to
IE6 for a decade instead of targeting standard HTML/CSS/JS.

~~~
EGreg
I’m going to disagree. Over the two decades I have been programming I have
come to appreciate the benefit of Open Source Collaboration vs competition.
Competition between platforms is good, but it’s not the best. Because those
who produce content waste millions of hours collectively trying to address
every little quirky difference between the platforms. And the standards only
help so much, whether it’s POSIX or WHATWG.

The real reason MS and IE were not so good is because they were a closed
source monopoly! And moreover the copyright was enforced by the government.

Now even M$ switched over to WebKit / Blink.

Collaboration beats competition in the end.

Wikipedia beat Britannica quite handily. And it beat Encarta, too.

Open source beat closed source over time.

The Web beat AOL and Compuserve.

Science beat secret cults and alchemy.

Today Pharma is using patents and competition. People are prevented from
building on each other’s work in microbiology but not in other sciences. Isn’t
that wild?

I would rather have lots of people adding to one snowball platform, than
having competing platforms. AS LONG AS that platform is open source and anyone
can use it for any purpose. If your commits don’t make it into the core, just
market them until they get popular enough. Compatibility is the goal, though.

~~~
gpvos
Chrome/Blink may be open source, but it's controlled by Google after Blink
forked from WebKit. It's hardly collaborative.

------
IronBacon
I've seen a day ago a recording of a presentation from last week FOSDEM where
two other libraries, Lorca[0] (Go + HTML5) and Webview[1] (C++/C/Go), were
described that are similar in scope to this one.

From the _webview_ project page: _It supports two-way JavaScript bindings (to
call JavaScript from C /C++/Go and to call C/C++/Go from JavaScript). It uses
Cocoa/WebKit on macOS, gtk-webkit2 on Linux and MSHTML (IE10/11) on Windows._

[0][https://github.com/zserge/lorca](https://github.com/zserge/lorca)

[1][https://github.com/zserge/webview](https://github.com/zserge/webview)

edit: the link to the video
[https://video.fosdem.org/2019/UD2.120/godesktopapps.webm](https://video.fosdem.org/2019/UD2.120/godesktopapps.webm)

and the presentation slides
[https://fosdem.org/2019/schedule/event/godesktopapps/attachm...](https://fosdem.org/2019/schedule/event/godesktopapps/attachments/slides/2994/export/events/attachments/godesktopapps/slides/2994/slides.pdf)

------
tptacek
There was about a year and a half worth of security work done on Electron
(particularly targeting the Node integration and how Node APIs were exposed).
I worry that not a lot of people know just how insecure Electron apps used to
be, and would generally worry that new Electron frameworks not designed
specifically to be secure are going to recapitulate a lot of that.

~~~
Erlich_Bachman
What is the attack vector that this protects against? Electron apps don't
usually just run user-provided code off the internet? They just run the code
provided by the app vendor?

~~~
pvg
XSS in the app or things it displays/depends on end up being RCE on the
client.

------
Razengan
As a user, I don't like Electron; "webapps" always feel clunky and alien
compared to native apps and the rest of the OS.

As a developer, I can appreciate Electron's utility in targeting multiple
platforms, but one has to wonder:

Why isn't there a good, open, cross-platform UI library already, that compiles
to the native UI of each OS?

Has there even been an initiative to make one?

You'd think the global developer community would have come together to tackle
this problem by now, consider how it's such a pain point for all of us and
users as well.

~~~
c-smile
> Why isn't there a good, open, cross-platform UI library already, that
> compiles to the native UI of each OS?

It is either "good native" or cross-platform. But not both in reality.

In principle can do something very basic using stock platform widgets - some
application that uses _only_ basic widgets: buttons and plain text textareas -
all others are too different on different platforms.

If your app is slightly more than that you will have problems even with basic
stuff. Consider this native UI example (Notepad++) : [https://i.kinja-
img.com/gawker-media/image/upload/c_lfill,w_...](https://i.kinja-
img.com/gawker-media/image/upload/c_lfill,w_768,q_90/ba6wdcpkmlgrb1qgd9gm.jpg)
and something like Sublime Text

Notepad++ is a disaster even native platform API. Sublime Text uses custom
non-native renderer - consistent UI styling.

------
hardwaresofton
BTW for those looking for interesting cross-platform focused UI systems,
Nuklear is pretty cool:
[https://github.com/vurtun/nuklear](https://github.com/vurtun/nuklear)

~~~
atrilumen
Cool, thanks. I'm tempted to make a Node binding.

------
wolfi1
I'm a little bit confused, why would the executable be larger than packed with
Electron? One would assume that if you don't need to pack chromium the
executable size should be comparably smaller

------
svrtknst
I feel like there should be an option that lies between either "Install a new
webview with every app" and "completely trust a previously installed webview".

I guess the downside is that that would be just a new .Net Framework, where an
app requires you to install the Whatever Webview 2.5 in order to run, but it'd
be neat to dodge Safari, while still having leaner Electron apps.

It could possibly be solved by specifying supported webviews in the
application.

------
cf
Is there anything like Electron from a cross-platform and ease of development
standpoint but way more lightweight? I often find applications written in it
to be very sluggish and resource intensive even when the web or mobile version
of the same application is significantly smaller and faster.

------
c-smile
Sciter ([https://sciter.com](https://sciter.com)) then, as it is not like
Electron - it is not using any web view at all.

But it does use HTML/CSS in the same way as WPF uses XAML for UI definitions.

Sciter allows to use best parts of two worlds: flexibility of HTML/CSS/script
for UI definitions and richness, power and compactness of native code as
Sciter is designed to be embeddable from the very beginning.

In what UI engine you can create your own HTML element with native C++ (Rust,
Go, etc) controller when you need to?

And on all Windows versions starting from XP, Mac OS from 10.7, all Linuxes
with GTK3 including Raspberry Pi...

------
mgamache
I am hoping Microsoft's moving Edge to chromium will allow this project to
work on a more Windows platforms. The new Edge will support Windows 7 & 8.

[https://www.theverge.com/2018/12/6/18128648/microsoft-
edge-c...](https://www.theverge.com/2018/12/6/18128648/microsoft-edge-chrome-
chromium-browser-changes)

------
boooohoooo
"Older Windows’ do not have a modern browser engine, only the one that powers
Internet Explorer."

...as if that's an excuse.

------
vijaybritto
The main problem that everyone has with electron is the RAM consumption
right?! If the webviews are anyway gonna increase the RAM to electron levels
while being significantly hard to test and deploy then this will not work out
ever. I'm only bothered about low RAM memory usage not the disk space.

~~~
snarfy
A simple hello world style app in electron and in my own project [1] show
electron using ~100mb while the webview based project ~50mb, so there's that.

[1] [https://github.com/zenakuten/webview-
cs](https://github.com/zenakuten/webview-cs)

------
a-barpetia
[https://github.com/cztomczak/phpdesktop](https://github.com/cztomczak/phpdesktop),
same concept without memory leak. Please, check it out

------
MrEricSir
A cross-platform native webview could be an elegant way to monetize an
application via web ads while minimizing bloat.

------
mezzode
I still think that first-class support for PWAs will be a more promising
alternative to Electron

------
tbodt
Requiring your Windows users to have the October 2018 update makes no sense.

~~~
airstrike
Read the entire article till you get to this part:

[https://deskgap.com/#why-is-the-supported-version-of-
windows...](https://deskgap.com/#why-is-the-supported-version-of-windows-so-
high-any-plan-of-supporting-windows-7-and-linux)

~~~
MrEricSir
Wish they had more technical details here. IE 9 was an update just like the
Windows 10 October 2018 update, but applies as far back as Vista. IE 9 is much
more compliant with modern ECMAScript standards than IE 8 ever was.

IE has been available as a COM component in Windows applications for ages --
at least as far back as XP -- so it could be done.

------
fastbmk
What about Flutter? Soon it will be able to run on multi-platform desktops.

------
stevefan1999
Will there ever be KDE support, since Qt also provided a HTML toolkit?

------
lincpa
I embed a Web server in my project, and when the project starts,
ChromePortable is automatically launched to open the Project home page.

Simple, stable, good compatibility.

------
janci
You mean IE on windows? No, thanks.

~~~
zapzupnz
According to the website, it doesn't use IE's engine, it uses Edge's. Soon,
that will be Chromium.

------
hestefisk
Sorry but: zzzzzz. Did I mention that Riot (Synapse client) uses 25% cpu
consistently when idle on my windows 10 laptop? This is a beefy Lenovo X1.

