Show HN: DeskGap – Like Electron, but uses the system webview (opens in new tab)

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.

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'

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.

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

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

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

As I noted in an above comment...

https://news.ycombinator.com/item?id=18763449

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

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.

Wouldn’t have this problem with a native app.

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

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!

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

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

Of course not.

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

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.

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.

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.