[lpsz]

Am I the only one unhappy with the trend of moving toward web-wrapper applications? As a developer, I also love the idea of cross-platform, and of more elegant frameworks, but it pains me to run things that are slower or hog the battery.

* JavaScript-heavy Spotify now vs. Spotify a few years ago

* Atom vs. something like Sublime Text

* Or, Slack that takes the cake especially if you log in to multiple Slacks.

It's cool for developers. It's not cool for the users.

[Mister_Snuggles]

It disappoints me as well.

Electron apps don't appear to play nice with the underlying API.

Take Spotify and Slack, for example. It makes sense that it should expose its API via AppleScript (on Mac), COM (on Windows), and DBUS (on Linux). These let you do neat things like, for example, use a PowerShell (or bash or AppleScript) script to update your Slack status to the name of the track that's playing.

Whether you'd WANT that specific functionality or not is beside the point, the fact that the functionality exists means that people will do cool things with it. More importantly, it means that people will do things the developer never thought of.

[jszymborski]

Except, the underlying backend of an electron app is a local node.js server. It's not only easy to open up a local API for an Electron app, it's platform independent.

[Mister_Snuggles]

Platform independence is nice, but generally that means it plays poorly on every platform.

Looking at Atom's API docs, for example, tells me that there's a very rich API that doesn't appear to be exposed in any way that's native to the underlying platform.

[marknutter]

> Am I the only one unhappy with the trend of moving toward web-wrapper applications?

No, you're not. In fact, every time any link shows up on the Hacker News front page that has to do with using HTML/JS/CSS to build native applications the comments on it are usually dominated by people who are "unhappy with the trend toward web-wrapper applications".

> It's cool for developers. It's not cool for the users.

Here's the thing, if it's not cool for developers, then it might not even get built, and that's really not cool for the users. So if I had to choose between less performant code but more software options for users and more performant code but some software people really want or need not being developed, I'd choose the former.

[TeMPOraL]

You're not the only one. I'm very unhappy with this trend myself. Just when you thought people can't invent any new ways of slowing present machines down to a crawl, this happens.

[damptowel]

I used to think faster computers meant faster programs...

[Aldo_MX]

well, the programs are faster to develop

[terda12]

Slack and Spotify are two examples of apps that have gotten worse and worse. Slack is CPU heavy as hell. Spotify is laggy and feels like a website rather than a native app.

[oceanswave]

Here's the thing: What's the #1 application that people use today on their desktops? Browsers.

There's a really high chance that you had another browser process open that was dedicated to writing your comment. Mobile included as the HA app is a Cordova-based solution.

But you feel compelled to say that thing that you used to accomplish your reading and commenting task was somehow slower and hogged your battery.

It got the job done didn't it?

Further, what's the #1 tech that some really smart people are focused on optimizing because of its usage. Yeah, again, the browser.

Show me another standards-based general UI stack that has had as much man hours dedicated to optimization... AWT/Swing/JavaFX? laugh. WPF, also really slow. WinForms? Not a lot of dev going on there at the moment.

[kedean]

The problem with Electron isn't just the fact that it's browser based. It's that it's a different browser. If I run slack, spotify, atom, and an actual browser all at once, my computer is going to slow to a halt. What electron needs is some way to run in concert with my actual browser, or some kind of hub process that coordinates them to reduce the absurd memory and disk space footprint.

[oceanswave]

generally Chrome and IE/Edge spawn separate processes per tab for isolation, but will sometimes group them based on some conditions. On the flipside I'd hate to have some 3rd party program bring down my browser.

So I get what you're saying, but the worst case is that your browser will do the same thing for each tab.

Software like Excel which will spawn a different instance of Excel for each workbook, even though it could theoretically be a single process... so it's not like native apps are a panacea in your argument.

[robenkleene]

An internet comment is a great example of a use case the browser is good for because it's low effort, low in specialized skills, and disposable.

Now we're talking about writing applications with web technologies for high specialized skill and high effort tasks, e.g., code editors, photoshop clones, etc... Which is what a lot of us are skeptical of. These "professional" applications are designed to reward a huge investment in muscle memory, if you are putting so much effort into learning an application, you don't want the return on that investment to be stunted by limitations in the technology the tool is built with.

[oceanswave]

Not following that last statement. There's no guarantee if I build my desktop application with XYZ framework that some technological limitation will crop up with it.

How much emphasis is being placed on JavaFX/Swing/AWT these days. Not so much. WPF? Microsoft has said that "...we are not investing in any major changes to WPF"

There is so much effort being placed in HTML/JS optimizations by WK, Blink, Edge folks that it's hard to find another framework with as much emphasis placed on it.

[robenkleene]

I'm talking about limitations in web apps that exist right now. For example with browser-based apps:

* Lack of data ownership, how do you export/backup?

* Poor keyboard shortcut support, e.g., constant conflicts between the browser itself and the app being run in the browser

With Electron based apps:

* Performance obviously, this might get better in the future, but that's a big bet of your time investment in learning and building on the tool. The fact that Atom is slow on a top-of-the-line machine is concerning. Sure that'll improve in time, but what if I also want to run it on more constrained device, tablets, etc...

* Electron apps still have a long ways to go to support basic platform expectations, e.g., on OS X Atom doesn't Services, AppleScript, or piping to the command line utility.

[rhodysurf]

Qt 5 and QML. GTK on Linux...

[seanclayton]

>Qt 5 and QML. GTK on Linux...

List one that is MIT licensed...

[cpburns2009]

Qt 5 is LGPL 2.1+ (not a problem unless you need to statically link).

GTK+ is LGPL 2.1 (not a problem unless you need to statically link).

[mwcampbell]

And wxWidgets is LGPL with an exception for static linking.

[lawnchair_larry]

It feels like the inmates are running the asylum to me.