Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: DeskGap – Like Electron, but uses the system webview (deskgap.com)
318 points by patr0nus on Feb 13, 2019 | hide | past | favorite | 260 comments

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.

I disagree.

The ideal application:

- uses no memory

- uses no disk space

- is instant

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

The real-world application, when the developers work for the customer and not for themselves:

- uses almost no memory

- uses almost no disk space

- is extremely fast

- costs next to nothing

- and has almost all the features in the world

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

I disagree.

Sadly, we need to balance features, performance and expectations with our own expectations about what kind of software we want to deliver.

I sincerely hate Electron and the whole ecosystem of bloated apps it enables BUT having matured a bit i can understand why it exists. People that hold the money want software out and want it fast and they don't care if the customer now needs almost 4 gigs of ram in their phone just to play music or browse the odd website.

A depressing state of affairs imho, specially for us "old folks" which enjoyed our software native and optimized as much as we could.

But developers do work for themselves...

I feel like i've seen this argument before, for Java desktop applications

And in my experience those have never taken off - just like in-browser applets - because they were too slow. The only Java based desktop applications I can think of are IDEs to write Java with, and those are too slow.

This comment should be posted under each Electron vs The World discussion as a reminder by a bot.

Disclaimer: I hate Electron. (but really appreciate and admire its developers)

Slack is Electron. Slack is installed on many laptops. Slack App just sucks and wastes real resources.

Genuine question - why do people install the Slack App? I haven't in ages, I just use the web-app and am very happy.

At least for me, webapps are just 1 in a thousand tabs open in 500 browser windows (ok, I exaggerate a bit). For an app with it's own window I can just hit a shortcut and said app gets focus. Disclaimer, not an Elektron fan.

Same for me. I'm so surprised that browser makers still haven't solved this particular problem in spite of all browsers now being multi process.

use `chrome --app`

That doesn't work on macOS.

Different screen share features only work in the app. I'd use the web app if all I needed was chat, but I'm on video calls and using screen share constantly.

I use slack on my second screen.

Pretty perfect summary and the reason why I pick native for side projects and electron for paid work (unless explicitly requested).

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

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

> Even though large performance-sensitive parts of it like the editor buffer data structures etc are (AFAIK) implemented natively

Actually they are not. The search in VSCode uses an external exe writing in Rust, but that is about it as far as custom native code goes.

Atom though did add some native code data structures.

Claims that VSCode is "inconsistent, it's full of random glitches" doesn't match my experience at all. It's solid. Maybe it could be faster, but I find its speed acceptable and regularly run it on a laptop with an Intel i3 CPU.

For someone coming from the Eclipse/Netbeans or Rubymine world, VSCode feels super snappy to me. I love it.

> I always like to use VSCode as an example...

Agreed, it's a great example of why Electron exists, but also a great example of an Electron app done well - I've used other Electron apps that have far fewer features, yet feel sluggish and/or are incredible memory hogs.

> But it's not.snappy.enough.

I also use VSCode on a daily basis (on Windows), and TBH I don't find it any less snappy than native IDEs such as Visual Studio or Rider, or indeed native text editors such as Notepad2.

> the whole user experience is actually quite bad. It's sluggish, inconsistent, it's full of random glitches

Similarly, I just don't have this experience - I find it both consistent and performant.

Do you use it on Windows, or another platform?

One of the standard replies I get when I complain about VSCode being sluggish is that it's not worse or even better than Visual Studio on Windows. That might be true, I don't use Visual Studio so I wouldn't know, but it's an argument that's completely unrelated to Electron. For me that's just whataboutism.

I would rather compare VS code to a regular editor with syntax highlighting, autocomplete and a few bindings to quickly kick off tasks, because that's essentially what it is. Could be Emacs, Vim, Sublime, etc. That's how I use VS Code, so that's what I compare it to. That said, for example XCode or CLion also feel faster, and I consider those way more feature-heavy than VS code.

>> Do you use it on Windows, or another platform?

I'm using VSCode on Linux, on a moderately sized C++ code base with the Microsoft IntelliSense LSP extension. I realize that some of the annoyances I experience are because of the C++ LSP stuff, which is still in preview, but it definitely isn't contained to just that. I sometimes also use VS code on macOS for JavaScript and Python projects, and even though it's a little better there, it's still nowhere near a good native editor. The weird glitches I experience are present on both platforms, and I've had a fair share of them. Keyboard input freezing for some seconds, buffers not updating when files changes, shortcuts not firing, drawing/refresh errors, just to name a few.

> I would rather compare VS code to a regular editor with syntax highlighting...

So, Visual Studio is somewhat sluggish, but Rider is not. I also mentioned Notepad2, which is a native text editor - I find VSCode just as snappy as that.

> I'm using VSCode on Linux, on a moderately sized C++ code base with the Microsoft IntelliSense LSP extension

I haven't used it on Linux, or at all with C++. I've used it on Windows and MacOS, for Typescript, JavaScript and Cordova projects, as well as for note taking (because I find it as fast as a text editor, yet much more fully featured).

Honestly, I've been using VSCode for a long time now, and I've never encountered any of the glitches you mentioned. Just did a totally scientific straw poll of co-workers, who say the same. You sound unsure, but I wonder if it is due to an extension you have installed?

Vim or Vim + YouCompleteMe? Because comparing VSCode which analyze your codebase with Vim alone isn't a fair comparison. My take: I prefer very much VSCode to Eclipse or CLion (Linux on large C++ codebase). As for Vim, I've never managed to configure it in a way that I can use ctags and multiple tabs as simply as I can do it in an IDE.

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

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.

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

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

What are the specs on your computer? How old is it? HDD?

My work machine that I used as reference here (my personal machines are similar, and suffer from similar sluggishness):

Intel Core i7-8700 @ 3.2GHz (12 threads, Coffee Lake)

64 GB 2666MHz DDR4 RAM (4x Kingston KHX2666C16/16G)


GPU is just the built-in UHD Graphics 630

Opening a new window takes presents a blank, black window that has more and more UI glitch in over a 2 second period. This is very frustrating for as a file-open delay when doing quick small edits. Gedit, on the other hand, does it in the time it takes to make the "fwoosh" opening animation (which can supposedly be disabled for faster start).

And for the record, there are no specs bad enough that a text editor should have a noticeable delay to open.

I dunno bout the graphical glitches but I run it on a machine far less beefier than yours (MacBook Air early 2014) and it runs fine for web dev on blogs and static sites and writing blog posts and small scale projects even with a bunch of plugins installed.

The only time vs code got unbearable to use for me was on this iMac late 2013 with an HDD drive I got on Craigslist a month ago but once I upgraded to SSD it was like a whole new computer, even running VMs and Kubernetes, VScode runs real nice working on large scale enterprise apps.

But yeah your computer sounds strong enough to handle any IDE so specs not the problem.

Going from Sublime to VSCode felt intolerably slow. I think Sublime is much better but the trillion dollar company is too much to fight against I guess, the community for VSCode is too big now.

I have been a big fan of VSCode for a while now even enthusiastically recommending it to my fellow colleagues but lately it has been VERY sluggish to the point where I am about ready to ditch it and go back to something like Sublime 3. I love the editor but the performance definitely leaves a lot to be desired.

I find that VSCode outperforms Visual Studio in ‘snappiness’ where Traditional VS lags greatly occasionally on editor input... as far as random glitches go, VS is shite in that dept.

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

That's not how I expected that sentence to end. I don't think regular people are nearly as concerned with performance as the groups you listed are. Regular people are probably using Electron via Slack for work and if it's slow and bloated it's ultimately not their problem. Even a few seconds delay won't cost them anything when it's still a faster replacement for email.

The irony of talking about "regular people" and then using Slack as somebody "regular people" actually use.

"Regular people" are likely to encounter electron by using Telegram or Whatsapp on the desktop, or some recent MS product like Skype. Whether they care or not about bloat, I don't know. I know those chat programs used to have annoying problems with cut & paste and not supporting basic assistive technology (i.e. the "emoji keyboard"), but I have to admit they got better with time; if those fixes have made it upstream to Electron, then things are improving. They are still horribly opaque to native OS services like sharing facilities and whatnot, but it looks like OS developers themselves are throwing all that away these days, so...

I expect the real issue Electron might never solve is real support for more advanced assistive tech for the visually-impaired and other disabled people. That stuff barely works with traditional desktop tech as it is. Obviously that has never been an obstacle in the market at large, it mostly plays a part in public-procurement processes.

As usual, "regular people" means whatever the poster needs it to mean in order for their argument to make sense. It's a straw man.

> "Regular people" are likely to encounter electron by using Telegram or Whatsapp on the desktop

Telegram is written in C++ and uses Qt. Maybe you're thinking of Discord?


Electron has a leg up in this regard long term, insomuch as the web is a platform that folks using assistive tech often use, Chromium is a reasonable target for assistive web technologies, and Electron apps have a higher chance of using accessible semantic building blocks by default.

Now, in practice? Yeah, not so good right now.

Telegram Desktop is a Qt-based app and it doesn't run everything on top of QtWebEngine.

How many non-devs (equivalent to the group of RAM < 6GB) use slack?

About 6k+ people use it in my org - the vast majority are not devs.

I work with a few organisations and small teams that use slack to communicate. They're campaigners, marketing types, logistics, finance, HR, and overall general staff working for businesses and organisations. I was also attending some university lectures recently (on history) and the class had a slack account which we were invited to join if we had any questions or needed support.

You also don't need to focus on Slack. Skype is an electron app. How many people use Skype to connect with their family?

For what it's worth I used VSCode as a ARM build on a Chromebook with crouton. It was fine. I think it cost me $150 used.

> cancer that needs to be nipped in the bud.

Come on with the hyperbole. Electron is effectively (nipped) as it is most usually just the shortest path to giving apps a persistent offline option outside of the browser sandbox. I don't know of _any_ electron app that isn't also a dedicated web app. VSCode is embedded as an editor in a few online code sandboxes.

Electron apps will almost certainly be replaced with PWA akin to the MS strategy. Shared run time, distributed via a 'store' of some kind, etc. It's an arc that we are in the middle of.

I get it, the world needs a better solution. However there isn't one. There isn't even a #2 best option. Electron's success is just the industry's continued failure.

You'd think Google would be close with Flutter, but Flutter doesn't run in the browser. So, fail.

Are there any options you'd suggest using _over_ Electron?

Every couple months an electron thread pops up and gets the same bashing.

The world very much needs electron and that's why it exists. jQuery was the same way forever. People just complained _constantly_ that we should be advancing the spec and using built in calls. That jQuery was some sort of bloated misstep. Well, we're still waiting for web components to be standardized more than 15 years later.

So as I understand it, people that don't like electron would rather us use _nothing_. Thus providing _no_ stepping stone to what should rightfully come next.

I see the same thing with electric cars. They aren't perfect _now_ so why invest in them at all? Why even explore an avenue that could lead to other innovations if it isn't _perfect_ out of the gate? 91% of the world population don't even own cars!

Why would you upvote me if you didn't agree with me?

QT is what i would suggest over electron

Did I up vote you? Likely because your post was provocative and got me to engage.

Also, in the third world things are moving towards machines running celeron / atom CPUs, with 4GB of memory and 32 GB of hard drive space.

Out of experience can tell you 32 GB is a space that can be killed rather fast.

Over the years we've had many cross platform GUI frameworks. Both native (wxWindows, SWT) and non-native (Swing, Qt). Everyone was trying for "better".

There have always been questions of adoption, stability, fidelity of the user experience and others.

Meanwhile web apps have kept chugging along and browsers have gotten better and better.

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

I contend that "native" is irrelevant. People are "native" web users. They use web based interfaces daily. A browser based UI is the "cross platform native" (whatever that means) GUI.

It can be fast (if you do the work, which may involve firing up external processes) it can be beautiful it can look native and it can deliver great user experiences.

It's not the GUI framework we wanted, but it's the one we deserve :)

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

My 10 year old netbook runs RStudio? Discord works great on my 10 year old Dell 2nd screen computer. What doesn't run VSCode?

>What doesn't run VSCode?

Last week was the first time my 2015 XPS laptop started swapping too hard to get any meaningful work done, and that was because I jumped onto a project with a vscode workflow.

Technically it can run vscode fine. But only if it's exclusively vscode.

So now I'm working in my editor of choice most of the time, and then closing all my open applications whenever I need to use the vscode extensions.

Something is seriously wrong with your machine if ti is having issues running VSCode.

Qt isn't good enough for you? These days it's even scriptable with JavaScript.

To add some fyi... a lot of Qt experts recommend you restrict the usage of Javscript to the QML layout of GUI controls and data binding. For business logic (especially cpu-intensive tasks), use C++.

Example of that "avoid Javascript" advice:

deep link: https://youtu.be/vzs5VPTf4QQ?t=30m55s

Even then, you have great bindings like PySide (for Python) that allow you to build Qt apps without resorting to C++. And it will still be snappier, and easier on disk and RAM, than Electron.

and until that exists?

But also remember that those $300 machines are mostly used for next to nothing. For the vast majority of the time people with those machines will have a couple of social media apps open in browsers, a media player running, maybe a mail reader, and perhaps some simple casual game. They aren't going to be running the several apps of any sort, never mind Electron ones, so what does it matter that several Electron apps would make the machine grind into a swappy mess?

If the regular people expect anything modern to be snappy on those machines then they have been mis-sold to[1] and that isn't our fault as devs.

> What the earth needs is...

Then why don't you put a team together and make it, and gain the fame and fortune that comes from solving the matter?

> NOT electron

Nobody is forcing you to use Electron based apps. If you find them, or anything else, too slow then find an alternative that is in a native toolset or entirely browser based, or what-ever.

A key problem is that people want what the want, they want it now, they want it to work on their platform without needing specific version of anything else (i.e. a browser), and they want it free. If Electron allows the thing to be delivered now, in a cross-platform manner, and people aren't willing to wait or pay for the dev time to develop in something smaller/nippier, then Electron is what devs are going to use.

I remember similar arguments regarding VB way back when: people wanting something that started faster and used less RAM bitterly complaining, but not wanting to use alternatives that were available because they cost more. To my mind Electron has a very similar feel to VB back then: great for prototyping, but can be used to produce fuller solutions too if you are willing to accept the cost in speed and weight.

[1] Oh how I love having to explain that 32GB total storage isn't really enough for Win10, especially when that is slow eMMC and the machine is swapping to it on account of only having 2GB RAM, when the sales person[2] said otherwise.

[2] People don't seem to accept "well go ask the salesman to make Office fit and make it go fast for you, you obviously think he knows more than I do"[3] as a valid response...

[3] Heck, those diminutive laptops/tablets/black-boxes-to-plug-into-your-tv, that are still being actively sold as Win10 compatible, can't even install the latest Win10 updates without some technical jiggery-pokery.

>The ideal application:

>- and has all the features in the world

In this case it's okay if it uses up all disc and memory. Actually it can even cost something in this case because only one application is needed.

It should be open source though so users can audit it and fix bugs if required. You see, just by requiring consistency in the requirements, one can get very far. Optimizing for typical startup metrics is just one way to do things but not the only valid one.

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/

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


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

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.

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?

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


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

Pretty sure they can on Linux at least.

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.

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

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

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

People are always complaining about Electron for shipping along with every single application, but actually, modern Linux desktop is not that far away from this just by itself. On a relatively standard desktop installation I currently have

- webkit-gtk2 - webkit-gtk3 - qtwebkit - qtwebengine

Additionally I have two Geckos for Firefox and Thunderbird. All of them use skia, which then also gets compiled 6 times in total.

Using Gentoo, I'm a bit sensitive to this sort of thing ;)

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

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

I'm glad to see that you are considering the Qt component. Qt looks good on Gnome, KDE, and other desktops. It is also relatively lightweight for what it offers.

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

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.

No - that's built on webkit, which is apparently becoming the next IE.

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.

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.

random and probably irrelevant spotify tip:

I absolutely hated how slow and buggy the app was, until I realised it was down to it attempting to index music locally all the time

my app speed increased massively by going to settings > local files, and turning off all of the options of where to show songs from

>Spotify app, almost crashing my system by playing music

Apparently the debate has matured from focusing on technical downsides to making unfalsifiable claims about technical downsides.

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.


Blows my mind we're still debating this.

> Nobody

This is like claiming nobody wants to write C because no one wants to manage their own memory in 2019, or miss out on all the cool new packages in the JS ecosystem.

Evidently _some people_ do. I can assure you there's at least number _n > 1_ of people who care more about app size than either of your points.

I personally wrote a side project in system web-view, because I don't want my macOS-only system-tray application to weigh 115+MB to make sure I have APIs I don't need in platforms I don't support.

No need to go too far to find an example: Sublime Text and Sublime Merge.

While this route is probably not for quick app deployment, but boy can it kick ass when properly done in C++ with custom GUI framework.

I love Sublime Text and Sublime Merge. I love their philosophy towards software design. I love how they value user experience above everything else.

There are very few pieces of software that give you so much pleasure and joy in using them on a day to day basis.

Yet so many still migrate to VSCode which is electron based. So maybe the difference you value isn’t valued enough to be worth it for most authors.

I get the point you’re making, but you might be in the minority here.

Citation needed. How many exactly?

You are comparing apples with pears. Sublime can't be compared to VS Code because the former is basically an advanced editor while the latter is an IDE (like PhpStorm or Atom).

And I highly doubt that many users switching from Sublime to VS Code. They use one or the other for a specific reason, like a blazing fast and distraction free editing experience in Sublime - something you do not have in VS Code or any other IDE, imo.

The line between advanced text editor and lightweight IDE is basically non existent.

Plenty of former sublime users are on VS code now.

I use VSCode for programming (Typescript), but it's also become a great replacement for my usual native text editor (Notepad2). I love how performant yet, feature-packed and extensible it is, and since I keep my notes in Markdown format, the `yzhang.markdown-all-in-one` extension is really useful.

So? Plenty of former VScode users are on Sublime, Vim or Emacs now.

I really don't get your point.

The person I responded too was saying that Sublime and VS Code are incomparable because they are different types of software.

I was disagreeing with his distinction between advanced text editors and lightweight IDEs.

This is a bit of a surprising thing for me to hear, because I found Sublime Text's user experience to be rather poor, and certainly inferior to its Electron-based competitor VS Code.

I would never say “poor”, although I found myself moving from Sublime Text to VS Code for most of my projects. However, ST is undeniably so much faster. If I need to edit large files or do something quickly, I am happy that I can use it.

Have you tried searching commands with the "command Palette". It makes everything discoverable for me. I personally LOVE the UX

Sublime feels like a marriage between TUI & GUI. * Everything is controllable by keyboard * Mouse based menus for one-time usage * Command Palette is awesome and very useful * FAST * Scriptable

Really hope they can keep being profitable.

fman (fman.io) for a dual pane file manager. Utilizing Qt, proprietary, cross platform, and follows the design philosophy of Sublime Text.

I mean, fuck the users. Will nobody think of the poor poor developers?

Never heard a non-programmer user complain about the Spotify or Slack desktop apps, but that’s just me.

I have absolutely heard non-programmer users complain about the Slack desktop app. They may not be able to diagnose why it is being slow or unresponsive, but they can still tell when it's being slow and unresponsive. And while the term "power user" has fallen out of favor, there are still users who aren't programmers, per se, who nonetheless understand concepts like memory and CPU usage.

non-programmer users don't complain because they don't know how bad they are fucked.

A few weeks ago my non-technical neighbours told me that their computer was "a bit slow" and if I could "install a new antivirus". Here's what "a bit slow" meant :

- windows took 7 minutes to boot

- IE took more than a minute to open

And of course it wasn't always like that, but the proverbial frog was boiled long enough that it took a lot of time for them to be pissed enough to look for help (the poor guys had 4 antivirus programs running concurrently - on a machine with 2 gigs of ram).

In contrast, if my browser takes more than 3 or so seconds to open I start looking for what's wrong.

Horror. 4 antivirus programs in 2G RAM

That makes me think of what school and uni digital illiteracy should look like.

given that the aforementioned neighbors are more than 60 years old I don't think you can really blame school and university

That's a result of the crazy acceleration current technology is moving with. My comment was kinda addressing the future.

That's because programmers know that it could be much faster if done with native technologies.

Non-programmers assume this is normal and now they are used to slow apps. Also, they don't know that the reason their whole system is very slow is slack.

Maybe you don't listen.

"Apps" like Slack are on my hate list even above desktop Java apps. Seriously, I can't understand how come it's acceptable to use >1GB of RAM to display 10 lines of text.

It's easy. The text is marked up, mixed in with images, video and other miscellaneous rich content, and includes remote resources and third party embeds.

There is no native UI toolkit that can do this properly, nor is there a cross platform way for 3rd parties to integrate even if there was. So web it is, with a runtime designed for being able to rapidly page in/out the entire UI from one screen to the next, even if that is entirely unnecessary for a single app.

Grouches have been shitting on the web, not entirely for bad reasons, but it's made them miss the fact that web has been stealing their lunch for a reason. If you live inside a terminal, your needs have diverged from the majority, and you're likely relying on crutches that are considered impossibly clunky by most.

The only ray of hope here is what FB has done with React and React Native, but I imagine it will take another 10 years before the unix geeks will want to admit there is something in that "webshit" worth looking at.

macOS Messages (aka iMessage) has been rendering text chat using HTML views for years, and it doesn't use gobs of memory.

The problem isn't that the text part is rendered using HTML. That actually makes sense - multiple desktop applications that compose/render user generated rich content rely on HTML (or something converted to HTML) and a web view of some description to render that content: mail, chat, etc.

The problem is rendering the entire application's chrome using Web technologies, and then running all of that inside a web view from a browser that is known to have the resource usage of a porcine creature with an eating disorder.

> The only ray of hope here is what FB has done with React and React Native

No. The ray of hope is that people realise web technologies are not the best choice, and the way they're used in Electron is fucking atrocious.

> macOS Messages (aka iMessage) has been rendering text chat using HTML views for years, and it doesn't use gobs of memory.

Keep in mind that the OS and the hardware it runs on comes from the same company that does iMessages. You shouldn't discount the amount of control that brings.

Contrast that to people who have to work with different OS platforms and hardware specifications.

Adium did exactly the same thing - rendering chat contents using HTML. It also didn’t use gobs of memory.

The hard work of optimisation has been done by apple, any app can embed a web view for content and take advantage of the optimisations in the system html renderer.


I refuse to use Electron apps - they clearly work in JS so the web version will work fine, and I get to keep the sandbox protections, content blocking etc of Safari.

And I use IDEA Ultimate almost daily. Yes, it uses a ton of RAM - but it uses a ton of RAM and is powerful.

I've not yet seen another IDE with the same capabilities (i.e. built in static analysis of dynamic languages like PHP, with refactoring support, etc).

I have oodles of memory (64GB) so I could of course run Slack and not "run out". But the key thing here is that Slack doesn't just use memory, it wastes it.

IDEA uses memory to make me more productive

Why would you even use the slack "app"? I don't like Slack but I have to use it, so I open it in a browser tab. Same crap, less memory use.

What do you think about intellij platform?

Spotify I can understand but Slack's client is hot garbage. Discord has more features and crashes less...

Which is a shame, because they are both awful.

It is unfortunate that this unsaid sentiment has pervaded all the engineering organizations I've worked for... except the one that made software for developers. Funny that.

It's not that difficult. You ship products to specific usergroups and don't need to exceed their tolerances. That 5% of users really hate Electron - or even know what it is - simply just doesn't matter to Slack.

And besides, of that 5% of people who hate it, a large percentage of them use it anyway because they have to.

Overengineered products for the minority don't do well unless you charge a huge premium for it, something my field unfortunately does a lot of and I have to deal with.

Developers are users too.

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

The point is that developers don't want to be testing against multiple browser/rendering engines--hence why Electron was built.

Maybe having multiple engines is good (although maybe the benefits are overstated since nowadays most engines align with the spec instead of implementing non-standard extensions like ActiveX), but it's not good for people for who want to quickly, and with low effort, develop desktop applications.

The point of the parent comment was that developers chose Electron over other frameworks for reasons such as speed of development, and DeskGap does not align with those reasons.

What developers want is important, but what users want is even more important. If a lightweight app is what users want, that's a good enough reason for at least some companies to consider DeskGap over Electron.

I'm sick of sluggish "native" apps on my i7 PC with fast SSDs and 32GB of RAM. I don't even want to imagine how those apps perform on low-end devices.

> but what users want is even more important

Only developers and very tech-savvy people bitch about Slack. Your average person working in Sales, HR, or operations cares not for the memory footprint of Slack.

It's also not nearly as bad as people make it out to be. Yeah, it's slower than mIRC, fair enough. But IRC is dead to almost everyone and Slack took over, so it is what it is.

They do, but they misdiagnose it as "my computer is slow" or normalize it because that's all they're used to.

Anecdata but I never heard of that complaint for people I know that use Slack.

Maybe the circle I am in simply has great computers. But who knows.

Users don’t want a “lightweight app”. Users want an app with <a list of features>.

Exactly. If users are held at gunpoint and have to choose between a fast app and a feature rich app, I would bet they will choose the latter.

Given what counts as "feature rich" these days (and it seems some developers are constantly removing things that users used to use), I doubt that.

Software used to be both fast and "feature rich" (relatively speaking), designed so users could "grow" and learn increasingly more of it. Now almost everything seems to have idiotically dumbed-down "flat" UIs that look simpler yet still manage to consume more resources than before.

The new Skype is a great example. Compare to something like this: https://www.microsip.org/ Yes, I know they're different protocols, but the point is that IM and audio/video call functionality doesn't need to take as much resources as Skype does.

The new Skype is a bad example. It's a perfect example of a designed-by-a-committee-of-managers product that tries and fails to understand the moving part of alternatives such as Slack, Facebook Messenger etc.

The cost savings here is in download/package size, and not runtime performance. Chances are latest chromium is faster than the system web-browser.

Startup time matters. Chances are the system web browser is already cached in memory, whereas every Electron app wants to load its own Chromium runtime.

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.

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

“M$”? Really? This isn’t slashdot.

It's good that you are advocating for render engine competition. But I think you think you are getting off tangent.

It has nothing to do with the point that trying to make your code work in multiple browsers/rendering engines is painful.

Wanting a project to work with multiple rendering engines just because is an idealogical decision.

All software is political, so ideology is relevant.

The political ideology in play for the majority of software development is capitalism so we loop back to "if i can't get it done asap using this tool, i'm not going to use this tool"

Externalities matter even in capitalism.

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.

A Slack written with DeskGap wouldn't run on Linux. I'm using Slack in the browser anyway but maybe not supporting Linux could make some software fail compared to a competitor supporting it.

> 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 fringe of css at this point, which most of us aren't bothering to use. Also, many people builting on top of electron (and presumably this platform) are using css toolkits like blueprint, and most of those take care of most of your cross browser issues anyway. So, largely not a concern.

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

> least efficient chat app ever

I dunno, Discord might be gunning for that prize.

Do you find it weird that you think these are the least efficient apps in their domain and yet they are both extremely popular with the majority of users out there?

Music and chat apps have an extremely high barrier to entry, which makes it quite difficult for others to compete.

> These are the least efficient chat app and least efficient music app ever

Which 99% of users never care about. The idea that large memory usage is a negative business driver is almost laughable at this point, yet for some reason it is a huge pet peeve among lots of technologists.

They care about it a lot more than you imply, they just don't know that it's something they care about.

I partly manage a team of end-user support people, and the number of tickets they get with "my computer is slow!" is astonishing.

The number of times it's found that they have Slack eating over half the RAM of their corporate-issued laptop (read: wimpy specs) is huge.

The number of people who understand that Slack being an insane resource hog is a large part of what is making their daily computing business painful is the inverse.

Have you never had a non-technical person ask you to help because their PC is slow? Non-technical people care, they just don't know how much better it could be for them. They understand that their PCs are slow, and they understand how to close apps they aren't using to stop the computer slowing down. This habit even transferred over to phones where developers had to teach people that it's not necessary to habitually swipe background apps closed any more, because they were so used to doing it.

Users absolutely care if their app runs slower. Even marginally slower in the order of 1/10 of a second. Even subconsciously users will choose the app that runs faster and smoother, this is why google.com first page is optimized and compressed saving individual bytes sometimes. This is why all big websites use servers all over the world to save 10ms in ping for users which are near them.

The only debatable question is whether the exact memory overhead (of electron for example) on the specific user machines existing out there today will make a noticeable loading time or lag difference. For many users it seems it does, not everyone has the lastest hardware.

This is a completely arrogant view of users.

People quite obviously care about speed and latency issues, but they might not be able to pinpoint slack or discord, etc as the root cause.

People care about latency and sluggish interfaces on their brand new PC.

Maybe I'm just spoiled having doing web dev back in the netscape 4 era when things were _really_ bad. These days it seems like a reset stylesheet and a couple polyfills and you're good to go. I don't doubt that certain problem spaces still run into major cross browser issues, but I guess I've been lucky enough to avoid those problems for the last couple of years.

There are definitely areas of the browser API that are quite problematic, especially when it comes to things needed in a UI like Spotify and Slack use. A brief look into the drag and drop implementations in browsers should be illuminating enough.

The desire to use new features as soon as possible is driver enough I feel. Imagine having to wait years for parity between 6 different operating systems before being able to use classes, a language feature introduced years ago and that still isn't fully supported today.

I'm just gonna link the actual Slack author who's already commented on this before and exit the thread.


The apps you mention are available on the web, so they have to do these exact things anyway.

What they really want to do is make that web app installable in the OS, no? I use WebPin to "install" websites (until this works natively in Firefox with PWAs) a lot of the time, even when they offer electron bundles (with the browser I already have, nodejs I already have ...).

I'd consider slack/spotify to be the outliers and I don't think this is targeting them. For the rest of the webdevs that just want to make a web app, Electron is appealing to them too and we shouldn't pretend the only reason they pick it up is browser compat issues.

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.

Nice. What did you switch to? I'm watching that space so i can recommend alternatives everywhere I work. Must be F/OSS. Top of the list currently are Rocket.chat and Matrix.

We switched to IRC. Most of the team uses irccloud, and a handful of us use pidgin or hexchat or the like.

Try mattermost

Nah, definitely not Mattermost. It's open core, which is kind of dubious, and not better than Rocket.chat - we switched away from it to Rocket.chat at a previous job.

As somebody who deals with HTML and CSS often I like the idea to be able to use these layout skills in a desktop GUI.

But size and speed matter (you don’t see much elektron based games..). We as a humanity can’t just always build faster and more powerful computers and then let developers throw these gains away by building more elaborate Rube-Goldberg-machines, that take 100 times the space they need, running more things taking the same old time we are used to wait, with dependencies no single human ever checked at once.

Many of same people who waste tremendous amounts of energy and collective human time writing ineffective applications might end up to be really pro-environmentalists outside their job, but when it comes to computers suddenly we don’t care. As long as it is acceptable on a new machine, who cares, right?

It would be entirely possible to write perfectly fast and efficient GUI applications using HTML and CSS as layout engines without dragging whole browsers into this. Using system webview might not be the solution. But maybe something that doesn’t feel like it has been taped together with duct tape would help. A fully fleged browser engine for a desktop app is overkill in most common usecases and while I understand why one decides for Elektron, I’d rather see a really thought out solution than one that has been duct taped together.

> Many of same people who waste tremendous amounts of energy and collective human time writing ineffective applications might end up to be really pro-environmentalists outside their job, but when it comes to computers suddenly we don’t care. As long as it is acceptable on a new machine, who cares, right?

This is such a privileged thing to say. I would guess there are far more important environmental problems to worry about. There are also more things that can be done that have more impact.

> It would be entirely possible to write perfectly fast and efficient GUI applications using HTML and CSS as layout engines without dragging whole browsers into this. Using system webview might not be the solution. But maybe something that doesn’t feel like it has been taped together with duct tape would help. A fully fleged browser engine for a desktop app is overkill in most common usecases and while I understand why one decides for Elektron, I’d rather see a really thought out solution than one that has been duct taped together.

Convince platform owners to agree on a common spec for GUI that's implemented consistently. Otherwise, what you want will ever remain a pipe dream.

> 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 doesn't mean to be a complete replacement for Electron. But after a glance of Electron Apps[1], I suppose many simple apps do not require start-of-art features.

[0] https://blogs.windows.com/windowsexperience/2018/12/06/micro...

[1] https://electronjs.org/apps

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

Mmmhmm. That's cool, although not original.

As I noted in an above comment...


Projects like DeskGap make this out to be a simpler problem than it actually is. ;P

I get that writing tests often isn’t fun but it’s as much a part of responsible development as writing useful error messages and not using experimental features on production builds.

What really blows my mind is that we’ve reached a point in computing where the developers laziness now outranks the customers needs.

> Since I can already see the litany of armchair-quarterback-desktop-app-authors

I think you’ll find those who are offering counter arguments aren’t just armchair critics. Eg I’ve been writing software since the 80s. This includes a considerable amount of desktop software. So I’d like to think my opinion is just as valid as your own. ;)

I'm actually wading back into the comments here for this specific comment, because it's ridiculous.

It's not developer laziness. This is 100% a business decision, and if you've been doing this since the 80s, I'd expect you to know this by now.

Do you really think Slack & co chose Electron because it's making developers lives easier? Companies and people choose it because it. just. works. across platforms. This has a direct translation to money, no matter how much you stick your head in the sand about it. Less resources, less platform-specific wizardry, more focus on core features with faster turnaround time. _That_ is all that matters here at the end of the day, because programming is not - nor has been, for the majority of roles, for some time - been about coding and tinkering with bits. It's about increasing revenue for the company/product/whatever.

When you (the general you, not you specifically) rant about reimplementing everything Electron gives you on three platforms, you gloss over the wealth of shit a web browser provides for free. I have actually implemented some of this stuff outside of a browser, and I wouldn't do it again if you were paying me.

_Furthermore_, very rarely does anyone compare implementing something via Electron to native... but native is a landmine-filled problem area of it's own. macOS alone is horrendously undocumented these days for a good portion of stuff, and you'll end up with a litany of platform specific hacks for the most basic things.

Hell, the easiest response to this comment is this: neither of our opinions needs to be valid, because the market's opinion is that Electron is the better choice.

I do get that point of view but there are as many exceptions to that rule as there are examples.

Take mobile app development: half the products that run on Electron on the desktop will still have native apps on mobiles. And even those that don’t would still have to use the native renderer on iOS and Windows Phone thus you’d be testing your common code base across multiple rendering engines anyway (which was the argument against the tool in this discussion).... and I’ve not even meantioned the slew of cross-platform applications that exist which have successfully avoided using Electron.

There are quite a few cross platform frameworks out there these days and different languages that can leverage them, however the next point I think is the real crux of the problem:

I will grant you that Electron does lower the barrier for entry (which is ironic because I personally find the web stack more awkward to develop in than native widgets - but each to their own). And maybe that’s where the biggest cost saving comes for the business; you can hire cheaper engineers to build and support your desktop software?

In any case, I’m not blind to the appeal of Electron; I just don’t agree with how important it is in the same way as the GP does.

Eh, no - nowadays most Electron-based apps would opt for a React Native app on iOS, so they can reuse most of the JS logic from their web counterparts. The big players (Slack, Spotify, etc) will introduce native things because it makes sense to, but there's no reason the small players will do this.

Multiple rendering engines in this case also makes sense because the form factor you're designing for is inherently different. As a result, the usability factor comes into play... you're never writing one UI at that point anyway. The point of Electron is that you turn building and testing 3 rendering engines into testing 1.

> Less resources, less platform-specific wizardry, more focus on core features with faster turnaround time.

Where can I request the "core features" of performance and usability?

You and I have done this specific dance many times, in case you haven't realized. You've failed to convince me that native wins on this for most devs... we've gone pretty in-depth on this before re: macOS, too. ;P

Slack migrating to Electron was by far the worst decision they’ve ever made for UX. That one migration introduced a ton of bugs and platform inconsistencies, most of which are still around.

One I just complained about the other day is Electron apparently doesn’t handle font fallback properly, so if I type an emoji that Slack doesn’t support, such as [frozen face], it just renders as a placeholder square in desktop Slack even though it renders as the emoji on both the website and in the iOS app.

Edit: Apparently HN strips the emoji from the comment [facepalm]

Slack doesn’t pick up my system dictionies correctly so I keep getting American English suggestions for words correctly spelt in GB English. It’s very annoying and I have no idea how to fix it.

Wouldn’t have this problem with a native app.

Having built this kind of thing natively, you actually might! macOS, for instance, has a few race conditions that can (easily) occur when using the built-in spell/grammar-checking functionality on text field/view instances.

...which is exactly the kind of thing that nobody wants to deal with when trying to ship a product. ;P

This myth that you get these things for free with native apps is just that: a myth.

> Having built this kind of thing natively

As have I :)

> you actually might! macOS, for instance, has a few race conditions that can (easily) occur when using the built-in spell/grammar-checking functionality on text field/view instances.

That forces it to load the wrong dictionary (one which differs from the system dic) and do so repeatedly each and every time you use the application? That doesn't sound much like a race condition to me...

> This myth that you get these things for free with native apps is just that: a myth.

Is that actually a myth though? Because I've never heard anyone suggest that - least of all uttered that nonsense myself.

I've had it load the wrong dictionary, surprisingly, yeah (I keep en-us and en-jp handy). It's a classic case of Apple abandoning macOS like they have for multiple releases now. ;P

There are bugs for NSSpellChecker going back as far as 2009 regarding automatic language detection (they're, however, now annoying as piss to link to... because all the old mailing lists/archives have been seemingly nuked. Thanks, Cocoa community!). This in turn hits Electron apps, since they're just passing back to the native API anyway.


Fair enough.

For reference I was referring to Linux where Chromium and my DE all have their dictionaries set up correctly. I only ever seem to have this problem with Electron apps too. It's very annoying though.

These two "nobody" reasons is why we are tettering on the edge of a browser monopoly, which will likely hurt desktop apps too if they use electron.

Monopoly = IE6, closed source, controlling the web.

Monopoly != multiple large vendors contributing to Chrome/Webkit/etc.

Chromium is still only a single engine under majority control by Google. Almost noone else contributing to Chromium does enough that they could maintain the engine as a fork indefinitely.

I think Azul is definitely promising, but it's still alpha level, when I first tried to run it on OSX Mojave I got a nice black screen: https://github.com/maps4print/azul/issues/35

The next time I ran it, it worked on release mode, but panicked on debug mode.

I've just tried again from master and it works, which is an improvement!

This probably has something to with layer backing (and changes in OpenGL, if they're using it).

It was really pleasing to read about this steady progress!

These projects are admirable, but people severely underestimate just how much work goes into building a true GUI solution. The insane amount of stuff required to wrap is bonkers-level crazy - you cannot easily match the millions of developer hours poured into the APIs used by MSFT/Apple/Linux, or the sheer complexity of a web browser.

You hands-down could not build Slack, Spotify and so forth in a solution like this. You would end up refactoring it very quickly when users start walking away because you can't have a feature they want (playing video, gifs, etc).

looks very promising

> Blows my mind we're still debating this.

Maybe you should consider that a sign that it's not as black&white as you tout it to be? I mean, what a way to just dismiss everything..

I'm dismissing it because the collective energy wasted on people complaining about Electron's rise is getting really old. Until a native environment offers feature-parity with Electron, the discussion won't change, and the sooner people start paying attention to that the better.

So yeah, it's pretty black and white. ;P

Should we consider the anti-vax movment as a sign that all is not black and white with vaccines?

Of course not.

Just because people are still having the conversation it doesn't mean the conversation is worthwhile.

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

Right on, this generation has no right to complain about IE only web sites. /s

IE only websites was an issue when the engines were closed source and intentionally held back. We're well past that point with modern browser engines.

Yeah right, Chromium is not the same thing as Chrome.

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

You mean like when building websites?

I build websites, and I don't want to be testing against multiple browser/rendering engines. I do it cos I have to, not for the hell of it.

I and most people work, because to not starve we have to, not for the hell of it. So the original statement is truism. Nobody wants to do the hard work in 2019.

It's not "hard work", it's monotonous and not worth the time. When even Microsoft realizes that, there's possibly some truth to it.

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

Speak for yourself.

I hate to break it to you, but in the real world there are multiple browsers.

Not testing in more than one is lazy, standards ignorant and an insult to your users.

Let’s not repeat the MSIE-fiasco again. We know better. We can do better.

>Not testing in more than one is lazy, standards ignorant and an insult to your users.

Slack et al are more successful with users, and have delivered more value to them, than 99% of the work people who post here are doing. Pretty sure this isn't insulting them.

And for the last time, this isn't the MSIE-fiasco all over again. The primary engines used today are all open sourced, it's not vendor lock in on the level it used to be.

> Since I can already see the litany of armchair-quarterback-desktop-app-authors

I'm so very sorry our 20 years of experience that causes us to reject the subpar monstrosities you like to call "dektop apps" rubs you the wrong way.

20 years of dev experience, yet people stick their head in the sand when the topic switches to why Electron is so successful. ;P

So yeah, it does rub me the wrong way. The people who argue against Electron are the programmer's programmer: they like tinkering, they care about the code, and so on. Most businesses don't. Users never see the code. If you want better, you need to beat Electron and stop ignoring or decrying why people opt for it.

I want small app package. By not bundling webview, deskgap looks perfect to me.

That would be an argument for Microsoft switching to Chromium, albeit 'Edgium' might not entail the bleeding edge 6 week Chrome release cycle.

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

Soon they'll all be WebKit or Chromium.

And where does Firefox go?


Doesn't anyone who makes a webpage need to test it in different browsers?

This is a thing that's really specific to web-design, though. People writing desktop apps want it to "just work", which is why Electron is a godsend (in this regard).

Why do people not think that cross platform GUIs don't 'just work'? The effort to get something that already works to another platform really isn't much.

Also electron doesn't 'just work'. A simple program being 300MB with a laggy sluggish interface is not 'just working'.

I wonder how all those commenters from HN who always say “we should have more competition in the brower engines” feel about your sentiment.

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

Nobody does. CSS is pretty mature, a difference in rendering between modern engines is extremely rare

That just isn't true. You only need to browse caniuse.com for 5 minutes to see there are significant differences between browsers even for mature CSS features. If you want to use anything new it's a minefield.

>If you want to use anything new it's a minefield.

That’s true with any platform. But if you stick with tried and true stuff, it’s hassle free.

I don’t remember the last time I had a layout rendering issue and I write this stuff everyday all day.

Not sure why your ADHD fuelled shiny seeking is an excuse for the shitshow that is electron. Just don't use new stuff?

I'm also unsure how it is even supposed to solve that specific issue considering my laptop is currently running at least two versions of electron for different apps, both of which render text as their primary directive.

The parent comment was stipulating that CSS is mature.

The reply was that it isn't because there are lots of features that are not available to all browsers.

A mature platform would be one where the features are consistent in whatever environment it is in. So in that regard, CSS is not mature.

"Just don't use new stuff" is not an excuse.

I never said it was an excuse. I said it was a valid approach, so are polyfills.

My issue isn't really with that my issue is that the issues with CSS and the valid workarounds are not painful enough to validate electron as a solution.

If electron did what it promised I wouldn't have a problem.

just don't differentiate from your competition using new features, instead focus on features users don't value at all - like memory consumption and being browser agnostic

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.



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

and the presentation slides https://fosdem.org/2019/schedule/event/godesktopapps/attachm...

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.

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?

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

I mean, the easy answer is make the web view send messages to Node instead of doing the node integration.

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.

> 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_... and something like Sublime Text

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

Native UI frameworks don't have a 1:1 match on features and UI components, and a cross-platform library would have to compromise on the lowest common denominator or use so many conditionals that you would be maintaining three different codebases anyway.

There's actually plenty of them. Off the top of my head: (C) libui; (C++) wxWidgets; (Java) SWT; (JavaScript) ReactNative; (Pascal) Lazarus. Then there's the non-native toolkits that either emulate the OS: (C) GTK; (C++) Qt; (Java) Swing. There's also Tk (Tcl) but I'm not sure where that falls.

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

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

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

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.

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.

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

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.


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

...as if that's an excuse.

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.

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

If you’re concerned about RAM, using this approach makes a lot of sense. Every process of your system browser running, (different tabs, different apps with web view), the OS can share memory between since it’s the same binary. With electron, each app bundles their own browser and memory cannot be shared since it’s different binaries.

https://github.com/cztomczak/phpdesktop, same concept without memory leak. Please, check it out

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

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact