Electron and the Decline of Native Apps
daringfireball.net
daringfireball.net
For what it is worth, developers are voting with their feet and have been for quite some time. Native development is rarely worth the trouble any more. Native development is tedious and expensive and you have to repeat the effort across different platforms for desktops and mobile. It's been a long time since I came across job vacancies for desktop UI development. This stopped being a thing as soon as browsers started running Ajax applications.
The problems with Electron are mainly related to performance, which could be described as adequate for a lot of stuff but typically not great. That's a solvable problem though. Actually Electron as a run time is basically a short term solution to ensure web applications have somewhere to run that isn't a web browser. As web browsers evolve to support PWAs, the need for bundling separate things like Electron goes away. The real progress is continual improvements related to things like wasm, low level browser rendering optimizations, etc.
These days most normal users do most interesting stuff on a computer via web apps. E.g. Office 365 can be used in a browser. There's no native app for Google docs at all and many people happily read their email in a web browser. Popular applications like spotify, slack, skype, etc. are all glorified web applications either running on electron or something similar. Increasingly it's the native apps that look dated and out of place. On mobile especially, a lot that passes for native is in fact running mostly in web views. It's more about the packaging, appstore presence, and access to system services than it is about using the right UI toolkits.
Some open questions in my mind for this are
1. Will the browser evolve to cover every use case? (Like AAA games, high performance IO)
2. What does this do for hardware vendors? Think over the years the hardware vendors had a good working relationship with Operating System vendors to surface new ISAs / APIs and make them available to developers, who could build killer apps for end users. For client workloads now new ISAs dont do anything unless they somehow get exposed through the browser.
3. If you are not a browser vendor what options do you have for introducing new computing paradigms ?
4. As the number of developers doing native development reduces to engineers who are implementing browsers the market for debuggers / profilers for native client development reduces. What effect does this have on tooling quality.
Would love any thoughts / speculations / ideas about the above.
Games have no native look and feel because they typically roll their own UIs. That makes them suitable for running in a browser sandbox. However, performance tends to be critical as is low level access to e.g. 3D hardware. So a lot of games where this is important will likely stay native for as long that that is the faster option. However, as wasm improves and access to relevant features from browsers improves, that will become an interesting target for more game developers. Portability of games is important and a source of a lot of overhead. Targeting e.g. xbox, playstation, windows, osx, android, and IOS requires doing a lot of platform independent stuff. Most of the mainstream game engines are effectively doing a lot of similar stuff as web browsers and there's an increasing overlap in terms of technologies. I expect wasm to be a key enabler here.
2 and 3 are interesting because this vastly simplifies creating new formfactors. Look e.g. at magic leap launching their AR platform and partnering with Firefox to get their VR browser going on a completely new HW and SW plaform for AR. I'd say this creates lots of opportunities because this stuff is open source and standardized to the point where competing implementations are interoperable to a very large degree. So, for magic leap that means a lot of stuff out there, should just work (barring UX issues resulting from AR).
4, again merit. This stuff is happening because developers are voting with their feet and also raising the bar in terms of tool quality. Wasm means that there is actually a renaissance in tool quality and innovation for native development. Just look at what the Rust community is doing for WASM and embedded development. Lots of new tools, libraries, and technology aimed at supporting both.
Free beats getting all the keyboard shortcuts right.
It is the same as having shared GTK or QT libraries (both with embedded web engine BTW - so plenty of engines already), or having a shared global python deployment with shared global packages (from these you sometimes need two: v2 and v3)
So you will have one extra component per system.
In Windows world maybe you will have one additional electron component per app, but there, it is the "normal" way (you have qt dlls in every qt app etc...) anyway, so not much difference compared to other frameworks there too.
Also, the platform for a PWA gets upgraded more regularly, which can be good (security patches or bad (breakage).
On Windows(UWP) and ChromeOS/Android, PWAs have the same rights as other apps if properly signed.
I don't know about Android / ChromeOS.
https://developer.chrome.com/apps/api_index
As for Android, the "What Web Can Do" PWA displays what extensions are currently available, https://whatwebcando.today/
Chrome apps do use HTML and JavaScript but aren't PWA's. The API's and sandboxing is different.
There are many useful HTML5 API's, but they don't require code signing as far as I know, and they don't have the same permissions as Android apps. (The permission system is entirely different.)
PWAs are supposed to check the avaialbe sandbox APIs and adapt accordingly.
So if a PWA is running on Windows on an UWP context, it can check it and then access UWP APIs, if they are running on Chrome OS instead, then check accordingly and act upon it.
Finally if only play old HTML 5 APIs are available, then make the best of it.
That is the whole point of Progressive, to enhance the experience depending on the surrounding context.
Browser specific APIs are a thing since the Web became a platform instead of plain hypertext documents.
If that’s the case, then why aren’t we collectively here on Hacker News celebrating Microsoft’s decision to ditch Edge in favor of (some flavor of) Chrome?
Monoculture is unambiguously bad, so anything that contributes to the destruction of the Tower of Babel is good.
We should all boycot Electon in favor of native solutions specific to each platform. Budget be damned.
No, it’s not. Like all things, it’s a trade off. In this case, the benefit is that monocultures are efficient by way of economies of scale.
Native user applications are not disappearing, but they are becoming rarer, and that is to be expected.
Related: https://dwheeler.com/blog/2018/10/23/#no-mobile-apps
Smalltalk had what was both an utopian and a dystopian story and experience when it came to cross platform. For most Smalltalks, the abstract runtime memory model ran bit identically across all platforms. Essentially, everything ran the same ISA and runtime memory model as implemented by the Virtual Machine. Squeak Smalltalk runs bit identically across many dozens of combinations of hardware and OS.
The dystopian part came primarily from 1) lack of polish in the deployment tools, 2) high resource requirements at first, creating a poor performance reputation that never went away, and 3) a development culture that never prioritized UX and look and feel.
EDIT: And it's not just Smalltalk that had those pitfalls. It's also Java Swing. Tcl/Tk. Also, to one extent or another, any number of cross platform tools and libraries. Given we've been at it so long, and the same mistakes have happened so many times, the pitfalls for cross platform GUI must be quite severe and hard to see.
While I’m in full-on you-kids-get-the-hell-off-my-lawn mode here, let me mention another Mojave gripe that is clearly the work of young developers at Apple. The Finder’s File → Show Original command has had the shortcut ⌘R since, I think, System 6. (Select an alias or symlink and this command will reveal the original file.)
This is exactly the kind of arrogant, smarmy stuff which alienates power users. "Who uses that stuff anymore?" Well, quite often, it's power users and influencers, and quite often, there was zero research done to see if that's the case before the feature is removed by young devs.
My guess is that the platform creators tend to put a lot of money into look and feel for their native components. This is hard to match for a small open source project (or anyone, really).
The web platform gets around this by being flexible enough for the application creator to create a polished look and feel themselves, and ubiquitous enough for many designers and developers to know how to use it. That's also part of what makes it so resource intensive.
It sounds like you have an unspoken assumption that only the web has that degree of flexibility. That's false, however.
The web platform gets around this by being flexible enough for the application creator to create a polished look and feel themselves, and ubiquitous enough for many designers and developers to know how to use it. That's also part of what makes it so resource intensive.
Smalltalk was flexible enough for anyone to create such a look and feel. Everything above the border of the VM itself was in the class library and was modifiable in Smalltalk, and most everything was in the class library. However, as a member of that community I can attest that many felt the need of this, but no one wanted to do it. Everyone who needed that level of polish was on a professional project and couldn't afford to devote that many resources to it, and everyone else was fine with the "developer" level UI.
The Web after the "Web 2.0" period grew both a developer and user culture emphasizing good looking interfaces with great UX. This was also increased by the aesthetics of smartphones and tablets after the appearance of the iPhone. The tools on the web are a bit less flexible than what was available to many earlier environments. However, there were more people with more motivation to make things look good.
It's not about flexibility and technical superiority. It's about numbers and motivation.
I wonder whether the problem for cross-platform GUI can be solved by brute force. Swing had a terrible reputation for being slow and ugly, yet today I find Intellij (which is based on Swing) fast and good looking.
I think Smalltalk (or something similar to what I've heard about Lisp machines from the 1980s) is the perfect environment for creating such a dynamic environments, and I think Smalltalk would have been better received had it been molded into an operating system instead of sitting on top of another operating system with the whole impedance mismatch between the host and Smalltalk environments.
Actually, it started out as an OS and was molded into a development environment.
The main change I see is 2 things...
1. Companies now write all internal software using the web both for deployment and accessibility reasons and for storing things in the data center. 2. Consumers have mostly moved on to mobile devices.
Honestly, if you need a desktop platform at home for anything other than hard core use cases (photo editing, software development, music production, etc.) those tools have largely been written and established.
Yes, and many of them do not make a convincing case for "native=high performance"
The justification for pure native apps just isn’t there. Engineering effort + maintenance costs are too high.
That, and NS* frameworks just kind of suck. Apple is trying to change that with the UIKit port to macOS but the apps that use it look and feel terrible (Home being one example) right now.
I've been working on a desktop app which is a document manager for PDF and cached web content.
The "native" desktop experience is insanely important and I think you can get there with Electron but it's not going to do it for you out of the box.
First. The bloat issue is definitely a real problem. Expect a 100MB app and 100-200MB of RAM usage. You wouldn't want to build calc or anything in Electron.
Additionally, things like context menus are next to impossible to implement properly as they require you to jump back and forth between the node and chromium processes and it's an insane hurdle to jump through.
The upside is that you can do amazing things that you couldn't do before like REALLY nail web content rendering and manipulation and also use frameworks like React or Angular which your team might already have experience with.
If you're an app like Discord being able to ship a desktop app on Windows and MacOS without having to hire native teams is a huge win.
If done right, the UI widgets can 'feel' native but they're never going to be there 100%.
What we can do in the mean time:
- build something like Electron or Flutter that takes into consideration ALL platforms - not just desktop or mobile but BOTH at the same time.
- supports native features when necessary. Electron TRIES to do the right thing but often fails just due to the complexity involved.
It’s so stupid that we keep on re-inventing the UI libraries that are already built into the operating system. They arare accessible, high performance and use very little extra memory since the resources are shared.
The problem is electron, not JavaScript. V8 folks work very hard to make JavaScript nimble and fast.
So Electron runs two copies of V8?
Since Electron in control of all the components, why wouldn't they try to merge the Node part into the Chromium process, to gain faster data exchange and lower RAM footprint? Has this been attempted?
Is the benefit of getting your app out on multiple platforms faster worth the downside of having your app be a shitty citizen of every platform unless you put significant effort into platform-specific tweaks that make it not suck? The cross-platform editors that are the most obvious rebuttals to my observation in the last paragraph are Emacs and Vim, which have cross-platform cores with platform-specific GUI code. It seems like, if being cross-platform is important to your product/team, that old-school approach will nearly always get you much better results.
Yeah, like everything, Electron is all about trade offs. It’s incredibly expensive and difficult to implement every new feature 3 different ways for three different clients. It’s very nice (and probably worth it) to just do it once, even if you lose some performance or small details that most users won’t notice.
All things being equal, I'm sure companies would love to develop their apps using native tooling and have them simple, beautiful, accessible etc. Doing this 3 times for 3 times the cost, as opposed to once some sacrifices is the obvious reason for this widespread adoption.
That's undoubtedly still more expensive than doing everything Electron, sure. But it's going to produce a nicer application: lower resources, faster performance, working better with platform-specific features (e.g., macOS's Services menu). Maybe that's not worth it for all applications, but if Electron-style frameworks that lock their applications to the lowest common denominators become the norm, the overall quality of software drops.
Electron provides a means to handle all of those environments with some admitted drawbacks on desktop. I'm not a proponent of Electron, just stating (IMO) the likely reason for it's adoption.
There are good "non-native" frameworks - Qt comes to my mind first, but Flutter and the now seemingly revived WPF are also good contenders. Those are pretty great.
You can also do Electron well (VsCode), but almost no devs do it, which makes me question whether doing it well might require just as much effort as using something else.
Are there any stats that back this up? It wouldn't surprise me if it was more than 3 times the cost given you'll likely have a larger team to coordinate.
Do people not realize that you can use cross platform C++ libraries and essentially get the same program to compile on three different platforms, then just write it once? It really isn't that difficult. Use Qt, or Juce, or FLTK, the standard library and a couple of cross platform libraries for things like networking and you are in the clear.
The idea that anyone is actually maintaining three separate versions of a program is completely detached from reality.
And like Discord or Finda[1] did, wherever you need some parts of your software to be really fast or to interact with the OS you can use Rust under the hood. And you have the best of both worlds. Using knowned technologies with CSS/HTML and React/Redux for fast UI/UX iterations, with “native access” and performance with Rust.
[1] https://keminglabs.com/blog/building-a-fast-electron-app-wit...
Embedded web with a native underpinning but not electron, totally custom made just like Spotify but their own creation.
And for what it's worth, I have never been dissatisfied with Spotify's client performance on any platform (Win/Mac/Gnu+Linux+XOrg/iOS).
I barely recognize VSCode as an Electron app, btw, it's so fast. They're doing something right.
Not to mention you have to install and update an app now. It's not even as convenient as the web.
Sublime Text is fast and cross-platform.
They're all good reminders that being cross-platform isn't the issue; it's the way Electron does it that's more of a problem. (Qt-based apps are a lot more performant, although in my experience they stick out like sore thumbs among apps using the native GUI toolkits.)
But then of course the question arises why have different platforms at all?
Using a QT app within a GTK window manager always sticks out in numerous ways (though probably less than most Electron apps), just like these bloated web wrappers do to long time Mac users.
If I were a Linux user, I'd rather a well-thought out App using the native toolkit that adheres to the platform interface guidelines than this Wild West any day.
I agree if this is a choice. But the reality is often a non-existent Linux app, because "it's not worth it" to implement it for Linux or an app which comes much later than the windows version and is of subpar quality.
If that is the choice then I'd rather have a non-native app than no app at all.
Linux desktop usage is 1-2%, so in practice most apps won't be implemented for Linux if it has to be done natively.
You can't even CMD + CTRL + D words to look up their definition, which is such a basic expectation of any native text input area in any real Mac app.
This doesn't excuse Apple, but it's hardly a good example to the contrary of what is terrible about Electron. Maybe for an IDE it matters less since almost all of them have terrible interfaces and the advantages of being able to write extensions for anywhere being more relevant than most apps, but Electron apps like Slack are still hot garbage compared to a native app for any platform.
I do think it has a lot to do with Electron and I also think their acquisition of GitHub had a lot to do with this also. But maybe not for the reasons this author is thinking. I don't think they're thinking of it as a scourge or a performance problem but the opposite, a savior of the desktop so to speak.
To understand why I say this I think we have to go back and talk about the history of .NET, XAML and their relationship with Windows. It's interesting to note that XAML was originally created by shifting a lot of developer resources away from IE6 and onto the WPF team, this was why IE6 sat stagnant for a long time, the developers were gone! What they then made was the windows presentation foundation for what later became known as Longhorn, which ended up being a pretty large disaster. Longhorn largely failed because they attempted to rewrite the windows shell using .NET and WPF. At the time (and still frankly) WPF had lots of really bad memory leaks, memory consumption issues, GC issues and a variety of other bugs and performance issues. This is why Longhorn was scrapped and what they ended up doing is to straight up revert the Windows codebase back several years to pre-longhorn and then subsequently worked overtime for another 3 years to crank out the gem known as Vista. Some people don't remember Vista fondly but frankly it was a Hurculean effort and a genuine evolution considering the prior turmoil that caused it. Or, in other words, it could have been worse.
So ever since Longhorn the Windows team has had an extremely bitter attitude towards .NET. I don't think its completely fair as they essentially went all in on a brand new technology and .NET has done a lot of evolving since then but nonetheless that sentiment remains among some of the now top players in Microsoft. So effectively there is a sentiment that some of the largest disasters in Microsoft history (IE's fall from grace and multiple "bad" versions of Windows) are, essentially, totally the fault of gambling on .NET and losing. And that sentiment can sometimes show in decisions like this.
So when Microsoft went to make their new metro apps for windows 8/10, they almost didn't even support XAML apps but only C++ and javascript. It was only the passion of the .net developer community that pushed it over the edge and made them let .net into the store as a first class type of app in the app store.
But here we are now and the store is not super successful and writing html+js applications for the Windows Store Apps is very unpopular and painful and here they are virtually retiring WPF and acquiring new html desktop technologies and freeing up a lot of js+html developer resources...
So what I think they intend on doing is adding features to electron and windows store which would enable developers to easily ship electron apps directly to their store. To do this they're going to have to add in some significant work into electron to be able to access the sandbox store api's and make it as transparent as possible to the api's that are already there. I think they see this as _revitalizing_ desktop applications. Because right now one of the major complaints people have is not that its hard to make a windows app but its hard to make a windows app and a mac app and a linux app... If you have enough resources and those individual experiences are important enough to you then fine, make 2-3 native apps, but for a small operations it's just not wise for anyone tether themselves to a technology that only lets them deliver on one platform.
There is nothing wrong with web apps being used as UI for desktop apps. In fact Apple uses that approach in Apple Music since it's a web app made in Ember.js.
The problem with Electron (and similar projects like NWJS) is that it embeds Chromium and Node resulting in bloated apps.
It is perfectly possible to create a desktop app using WKWebView and Swift which are super performant and efficient.
For the consumer it's great, of course, each of the three big OSes basically allow you to run the same stuff and judging by VSCode performance can be okay.
The more apps like this, the more they erode the UI vocabulary that the Mac has built up.
Most users will only need to install the device shim.
There must be a better solution.