
Electron and the Decline of Native Apps - _hztt
https://daringfireball.net/2018/12/electron_and_the_decline_of_native_apps
======
jillesvangurp
Electron is a stop gap solution on a path away from natively compiled
applications against the proprietary UI frameworks that come with mac or
windows or any of the complex matrix of UI toolkits, window managers and other
crap that essentially cause Linux to be a perpetually inconsistent UX
nightmare. That stuff is increasingly less relevant for new applications.

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.

~~~
dman
Yes this has been a rather interesting development - it seems the purpose of
the native apis is now becoming just to bootstrap the browser with the browser
implementors being the sole users of the native platform apis. Will be really
interesting to watch what happens here long term.

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.

~~~
jillesvangurp
A lot of this stuff is simply happening on merit. Nobody is being forced to
use web based platforms, it just so happens to be a convenient option for a
lot of developers.

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.

------
_jezell_
Electron isn't the end game, it's a flawed, but workable solution to the
problem of having to support too many platforms on a limited budget. I can't
wait till we have something better, but I haven't seen a better solution yet.
There are not many companies that can afford to build first class native apps
for every platform.

~~~
butz
Progressive Web Apps are better solution. Chrome and Edge have PWA
installation on desktop, and work is already under way for missing native
features, like file system access. In a year or so they will replace need for
Electron completely. Although they will never be as good integrated or
performant as real native apps.

~~~
paxys
Progressive Web Apps + missing features like file system access is _exactly_
what Electron is.

~~~
wmf
Do N Electron apps consume more RAM than N browser tabs?

~~~
szemet
It maybe does not mean that much, but at least code memory can be shared among
electron app instances if it is deployed with shared libraries by a
distribution package manager e.g.
[https://www.archlinux.org/packages/community/x86_64/electron...](https://www.archlinux.org/packages/community/x86_64/electron/)

~~~
wmf
Of course the main markets for Electron are Windows and Mac where it's
probably not shared (although MS may try to fix this).

------
dwheeler
I think the issue is straightforward, it is simple economics. Nobody wants to
spend a lot of money to rewrite applications three or more times. Sure, there
are some people who really want a very specific user interface for their
specific system, and there are a number of cases where a non-native
application cannot do the job. But most users frankly don't care that much,
they just want things to work. A vast number of applications can be done using
web technologies, without rewriting the application multiple times, and that
saves a pile of money. That kind of focus also makes it a lot easier to make
one good product instead of three bad ones.

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](https://dwheeler.com/blog/2018/10/23/#no-mobile-apps)

------
stcredzero
Electron really needs to heed the experiences of the past, if they want to
really thrive.

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.

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

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.

~~~
stcredzero
_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)._

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.

~~~
scroot
Pharo's new graphics system, Bloc, is going to change some of this. Already
the guys rewriting GToolkit are experimenting with much better looking and
more interesting UIs. And one of the backends is the same framework mozilla
uses in their browser.

------
jarjoura
If it's a competitive advantage for your desktop product to use the native
system frameworks with the platform preferred language (Cocoa/Swift or
UWP/C#), I believe its just as easy to justify the development time and cost
to build your product today as it was 10 years ago.

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.

~~~
zwieback
> 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"

------
burtonator
I've been heads down in the guts of Electron for the last 120 days so I can
definitely speak to this at length.

I've been working on a desktop app which is a document manager for PDF and
cached web content.

[https://getpolarized.io/](https://getpolarized.io/)

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.

~~~
nojvek
We just need a React native for desktop that works well cross platform.

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.

------
chipotle_coyote
I think it's possible to do a good Electron-based application: Visual Studio
Code comes immediately to mind (and Atom, although at least the last time I
looked at it, Code seemed both less resource-intensive and more nimble). But
after Code/Atom, there's...what, exactly? For that matter, I'm finding myself
spending more time in BBEdit and Sublime Text these days, both of which are
_much_ faster and less resource-intensive than their cross-platform
counterparts.

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.

~~~
baron816
Slack and Spotify are two other famous examples.

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.

~~~
purephase
This is the crux of the anti-Electron folks that I've never understood tbh.

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.

~~~
chipotle_coyote
Well, the anti-Electron argument is that you're _not_ necessarily doing it
"three times for three times the cost." If you designed your app with the
intention of being cross-platform to start with, you're writing it to have
some kind of platform abstraction layer. The bulk of most applications isn't
going to change.

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.

~~~
purephase
When I say three times the cost, I primarily mean for the web, mobile and
desktop. Not for the varying OS distributions.

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.

------
Apocryphon
It'll be interesting to see if Flutter, through Hummingbird, ends up getting
any traction as an alternative to Electron. Not to mention with Marzipan on
the horizon, what other cross-platform competitors will arise.

~~~
MarkMc
Yes Flutter could become an alternative to Electron, but it doesn't need
Hummingbird for that - Flutter can be directly compiled as a native desktop
application.

------
igotsideas
I recently tried to use new Swift features cause I wanted to build a native
app. Unfortunately, my MacBook pro is too old to update to the newest Xcode
which means I can't upgrade to the latest version of Swift. Fortunately, every
other language doesn't discriminate against my 2011 MBP. This made me switch
to building my app in Electron without any problems. Maybe this is far from
the subject but I found it relevant because it was the very reason I started
building in Electron and not a native MacOS app.

------
dmortin
If the decline of native apps means the apps will be available on all
platforms, because it's the same codebase then it's a welcome change. No more
this app works on Windows, but not on Linux,etc.

But then of course the question arises why have different platforms at all?

~~~
jeffbax
Maybe you are happy with a race to the lowest common denominator in regards to
quality and expectations, but IMO that serves any platform terribly.

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.

~~~
dmortin
> If I were a Linux user, I'd rather a well-thought out App using the native
> toolkit

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.

------
ianwalter
Kap and VS Code are Electron apps that prove you can get it “right” but it is
troubling that Apple’s own apps don’t seem to have the same quality that they
used to.

~~~
jeffbax
VS Code might be a nice editor and relatively efficient Electron application
resources wise, but it is definitely not native.

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.

------
mimixco
To decry the mass adoption of Electron because the apps it makes aren't "Mac
enough" is just crazy. Electron is a terrific solution for developers and
users. Nothing prevents you from writing a Mac-y app with JS and CSS. I think
what the author is really upset about is that not many people like Mac-like
apps! The whole idea of a boutique Mac UI that obfuscates most functions and
dumbs-down others simply isn't that appealing to anyone but noobs. Is there
anything Mac-like about iTunes, or ProTools? Even Apple doesn't care about
their boutique UI, as OP points out. If Electron can kill native apps, as a
dev and a user, I'm all for it.

------
justinmchase
As a former Microsoft employee who used to work on Internet Explorer (I helped
build the new developer tools), I will say I believe he's partly right here.

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.

------
pier25
I'm surprised by John Gruber's lack of technical knowledge.

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.

------
zwieback
What's a little confusing for an oldtimer like me is how developing for
electron will be different from developing for an OS - don't you make a
commitment to a platform that may or may not end up being your best bet?

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.

~~~
ridiculous_fish
Gruber's point is it's not "great." These apps do not feel like Mac apps and
do not obey Mac app conventions. Even in VSCode, there is hardly a single
interaction that behaves properly. Scrolling, cursor movements, menus, table
selection, resizing, drag and drop: they all behave wrong.

The more apps like this, the more they erode the UI vocabulary that the Mac
has built up.

~~~
mixmastamyk
Are the browsers on the Mac also that bad? What is the difference between say
Chrome and Electron?

~~~
ridiculous_fish
Mac browsers are much more Mac-like than Electron apps, because they use
native Mac APIs for these interactions. For example, Command-Z in Chrome
highlights the menu properly because it's handled via the Mac UI frameworks,
not intercepted by JS.

------
tambourine_man
As a user, I hate Electron. As a developer, I love it.

There must be a better solution.

------
imcotton
always bet on javascript

