
Native desktop apps are far superior to Web/Electron - me551ah
http://ajit.dhiwal.com/2020/02/world-wide-web-is-worst-possible-user.html?m=1
======
dang
When there's a major thread on a topic, like
[https://news.ycombinator.com/item?id=23211851](https://news.ycombinator.com/item?id=23211851)
which is currently at #9, it's better to post follow-up links in the thread
rather than as separate submissions. Otherwise the front page gets repetitive.

[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20follow-
up&sort=byDate&type=comment)

Also, please don't rewrite titles to make them more baity - this is in the
site guidelines:
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html).

~~~
me551ah
Author of the article here and the one who made this post. I did post this as
a comment on the post you mentioned, but given that I'm already late I haven't
seen any upvotes to it. So I decided to make a submission. Sorry about adding
to the clutter.

Sorry if the title now appears to be more baity, I was actually intending this
to be a response to the Ask HN post on the front page. I figured it would be
okay for post Authors to change the title since I can always change it in my
original post. EDIT: I have changed the title of my original post.

------
redleggedfrog
I'd take it even further.

Browsers and things like Electron are just run-times. The browser's main
advantage is cross-platform compatibility. But only kinda-sorta as any web
developer can tell you. Your code is usually targeting 3 different run-times
at a minimum and there are always problems with anything non-trivial.

It is easy to imagine something much better, where your code runs on a nice
tidy runtime native to the OS, with relatively easy layout tools and a
language that is better than JavaScript (and really, what language isn't?).
It'd be nice and fast, and rewarding to develop in.

If we are starting anew, with fresh eyes, and we were handed browsers, with
JavaScript, CSS, and the DOM, we'd be like, "This is complete BS. Visual VB
for _DOS_ has this beat."

But because it grew organically, with instantly built in lock-in, and we're
now thoroughly indoctrinated, the Stockholm Syndrome lives on.

If you can just take 3 steps back it's fairly obvious. But people would rather
just keep making the next React or Bootstrap and digging the hole deeper than
make something better.

Someday, make my words, there will be a cross-platform runtime that doesn't
suck, that doesn't use JavaScript, and won't the stupid mistakes of the JRE,
and developers will abandon web browsers as a platform in droves. I mean, can
you really see this as the state of affairs in 2030? 2040? That'd just be sad.

Edit: typo

~~~
arkanciscan
> It is easy to imagine something much better, where your code runs on a nice
> tidy runtime native to the OS

Yeah, cause that's how every native platform has been since the begining. Yet
the web still needed to be invented. Why?

~~~
thayne
The biggest reason is probably that you don't need the user to explicitly
download and install your app. Also, a web app works on all the major OSes
with a single GUI environment. And then of course the fact that webapps run in
a more secure sandbox. A standard cross API and sandbox could potentially
solve the second two. But I'm not sure how to solve the first outside of a
browser.

------
felixrieseberg
Look, I get it, "less web apps" is an easy post to write these days, but all I
ask is that we tone down the FUD. Let me just pick off the inaccuracies that
will likely stick the most:

> But building for the web(and electron) forces you to HTML/Javascript(and
> derivates).

This is incorrect. Electron supports Objective-C, C++, Rust, and obviously
WASM (amongst others). If you want to build native code (and native UI) in any
of these languages, go for it. Countless Electron apps have native components.

> It has no type safety, memory leaks are common and it’s slow due to its
> dynamic nature.

TypeScript has been a thing for a while now. [Citation needed] for the
statement that memory leaks are more common than in, say, C++. Slow: Yes, it's
slower, but probably by _a lot_ less than you think[1].

> And it’s laughable how weak the browser platform itself is. SQLite is
> available on raspberry pi, embeddable systems, mobile platforms and just
> about every other platform on the planet.

I agree, SQLite is fantastic. We don't really have to argue whether IndexDB
will get thee job done, because native bindings to use SQLite with Electron
exist. Just... use it.

And lastly...

> These days to send a text message over Slack I need over 1GB of RAM. [...]
> Even basic apps with all of their trackers, external javascript scripts and
> doms take up 100s of MBs in memory.

We're always working on performance and we're quite far from the place I'd
like us to be at, but it'll send your message just fine if you have less than
one GB of memory installed in your whole machine. Even if you're a heavy user,
your memory _should_ be below one GB. To be clear, I'll say it again: Yes,
things should be better and we'll keep working on performance. The post
mentioned Instagram earlier, which I'd say goes a bit beyond the most basic
app, and it's using a humble 40MB on my machine.

Disclaimer: I'm one of the maintainers of Electron and an engineer at Slack.
I'm not here to argue opinions or which tool is better for which job, but we
should get the basic facts right.

[1]:
[https://www.youtube.com/watch?v=81CECdKCJNc](https://www.youtube.com/watch?v=81CECdKCJNc)

~~~
guilamu
Hello,

I just like to add that I never understood how when I just try to edit one of
my Slack message (Windows client) it literally takes 100 % of 4@4ghz i5 cores
and freeze my system for 2 seconds.

I mean, come on, I'm not asking the impossible here, just editing a single
line of text.

I hope one day you go native like Telegram for example which is blazing fast,
ultra light and also has clients on Android, Mac, etc.

Bests,

~~~
entha_saava
There are some alternative slack clients.

------
on_and_off
> When apps are built for mobile, battery usage is a major area to optimize
> on.

I worked on some heavy duty mobile apps like music streaming and unfortunately
battery usage is the last thing we optimize for.

The platform even provides us with some ways to measure it, but it is just so
remote from the metrics we do optimize for that except for major problems, we
don't focus on it in the slightest.

>Mobile apps run at 60fps out of the box without much effort.

Technically fps is not the best way to measure this (we tend to focus on
dropped frames instead, unlike most video games engines; mobile will not
recompose your UI if nothing moves, saving cycles and heat) Lots of efforts
have actually been made to optimize mobile apps. We are starting to reach a
point where we do have a top to bottom approach for reasonable performances
(try to scroll any app insanely fast .. you will drop frames, but in regular
usage; dropped frame are not too noticeable on recent top of the line phones).

Agreed on the article though. Nothing more irritating than running a
legitimately demanding application, seeing that it does not have enough
resources and realize that a small web app in the background is using 37 cores
and 50% of your cpu while you are not even using it (that was whatsapp just
now).

------
polote
The name of the post should be "We need a better alternative to Web(&
Electron) apps". As the article doesn't talk about the current title at all,
and only encourage flame war discussions

------
pier25
Electron apps aren't made because the end result is superior but because of
budgets and schedules.

Not even a company like Slack wants to get into the headache of maintaining a
couple of native desktop apps, even if they probably have the money to do so.

~~~
Qasaur
I've never really understood this way of thinking. In my experience, it is
trivial to maintain cross-platform applications if you encourage code-reuse in
the logic layer and tailor the UI/UX experiences for the platform you are
targeting. In practice this usually means writing the client business logic in
a high-performant language that can target multiple platforms (I've only used
Rust for this, but there are other languages out there that would work well
with this approach as well), and using FFI when interacting with the UI layer.
Combine this with good message passing practices (to homogenise
serialisation/deserialisation and avoid the complexity of having hundreds of
different FFI functions with various parameters) and you've got something that
is easily integrated in platforms with little headache.

I've seen great success with this approach for most platforms including mobile
as it provides the end-user with a great user experience (you can use all the
native UI APIs which provides an experience that the user is already familiar
with) as well as extremely high performance with a high degree of code reuse.

~~~
MattGaiser
But why bother even setting up different build environments for the different
platforms?

Even that part makes it already more work than Electron and I can't think of
any meaningful business benefit to not using Electron.

~~~
entha_saava
How do you measure "meaningful business impact".

Because everyone optimized for "meaningful business impact" I have no space on
my SSD to install your app.

(and even if I install it, it would cause my laptop fans go wild and I go for
an alternative / use your app less.)

------
scottmcdot
I really don't like the lack of responsiveness that some Web apps have. I
remember coming from Teradata SQL Assistant to Cloudera's Hue and being so
frustrated by the latency of editing code (pushing the keyboard and seeing the
letters appear). It would often result in me inserting random characters.

------
osrec
From a previous comment of mine:

There is a need for native apps, however that need is shrinking and, in my
opinion, will continue to do so. I also happen to think that's a good thing.

The issue is that developing for a particular OS is, generally, more difficult
than developing for the web. The app delivery mechanism is also more
convoluted (for native apps) than simply entering a web address in the
browser. The web also seems to have more ubiquitous standards that abstract
away the differences between OSs - you can, with a high degree of certainty,
ensure that your app is usable by 99% of computer users, given the current
software they have on their device - with native apps, there is no such
guarantee, especially if you're relying on shared libraries.

Browsers are also becoming more feature rich. This has had a negative impact
on their memory consumption, but given it's 2020, some may retort "memory is
cheap" (I totally disagree with this way of thinking personally). And while
some browsers (Chrome, looking especially at you) do a _very_ poor job of
memory management, I believe the competitive nature of the browser market will
force a reawakening soon, where a lot of the inefficiencies in memory
management will have to be eradicated (or vendors risk losing market share).
Think back to 2014/15 when Node.js was really becoming established - the PHP
team suddenly felt a need to re-optimise their engine for PHP7 (and with
dramatic results)... Point is, only after ~20 years at the top did something
spur PHP's team on enough to do something about their inefficiencies.

Finally, I can see a future where the line between web and native apps is even
more blurred. WebAssembly is the first step, however things could get even
more elaborate. Perhaps we could end up with the ability to start docker-like
containers from within web apps (given the right permissions, of course) to
spin up servers for audio/video/image processing on the client itself, and
interact with them via a web page. If we get to this point, native apps may
feel even more obsolete.

I know this post relates primarily to the current state, but I felt the need
to talk about the future to highlight the marked difference in the rate of
innovation in the web ecosystem (fast) vs the native ecosystem (slower). It
would not surprise me if the web ecosystem ends up winning in the end. If I
was building an app today, and it only requires features I can deliver via the
browser, I would almost certainly go the web app route.

Now, if I was building a video processing app today, I'd almost certainly go
native, but in a couple of years, my answer may be very different.

~~~
andrekorol
I can see this containerized future that you've envisioned solving a lot of
the current performance problems of web apps.

~~~
osrec
Wouldn't it be amazing?!

You could even have the browser allocate a volume or two for the container to
use (with the user's permission, of course) to store data locally. And users
could be allowed to adjust how much space the volume may use (from some
default minimum to unlimited).

And with containers, the client should be reasonably safe even if executing
malicious software.

------
jwilliams
This is an interesting debate, but I don’t think this is useful framing:

“And it’s laughable how weak the browser platform itself is.”

Which begs the question of why then do developers use web/electron?

Ubuiqity, cross-platform, distribution, updates... and, yes, some developers
also prefer web api.

Perhaps the question is how do we bring a web/election experience to native
apps?

~~~
sanxiyn
I think Flutter is an attempt to answer that question. Whether it succeeds is
not yet clear, but what is clear is that it is trying to answer the right
question.

------
thethethethe
Seems like the only argument here is: “web apps are slow and use a lot of
resources”

This isn’t a great argument by itself. There are many reasons that web apps
are superior and more convenient than desktop apps. If this wasn’t the case,
then why are web apps winning?

I don’t want to download and execute a binary just to read my email, make a
video call, or read the news. Web apps are also cross platform. You can pretty
much guarantee that gmail will work the same on windows, Mac, Linux, Chrome
OS, and even iOS and android (with some idiosyncrasies). Web apps also update
themselves, they take up no space on your computer, and can be customized
using browser plugins.

I’d take these advantages over saving a few gigs of ram, which I have plenty
of.

~~~
pmlnr
> that gmail will work the same on windows, Mac, Linux, Chrome OS, and even
> iOS and android

Nope. This is the Java Virtual Machine promise all over again. It didn't work.
It doesn't work the same in Safari or Firefox as it does in Chrome.

~~~
thethethethe
Is chrome not consistent across operating systems?

~~~
pmlnr
Is it not. For example hardware acceleration is terrible under linux.

------
julius_set
I mean it’s pretty obvious, any abstraction that aims to consolidate multiple
platforms will come at the cost of performance

------
giovannibonetti
A good alternative that is coming to fruition is a modern alternative to Qt
called libui [1]. Description from the project page: "Simple and portable (but
not inflexible) GUI library in C that uses the native GUI technologies of each
platform it supports."

There are bindings for it in many languages, like Node.js, Rust, Swift, Kotlin
and more.

[1] [https://github.com/andlabs/libui](https://github.com/andlabs/libui)

------
thegreatpeter
Check out Revery UI: [https://github.com/revery-
ui/revery](https://github.com/revery-ui/revery)

This _is_ the replacement for Electron/Web.

Built on top of ReasonML which offers a JavaScript like syntax (and supports
your favorite libraries too)

Revery UI can successfully target web, native desktop for Mac, windows & Linux
with mobile coming soon. The case studies are great!

------
eludwig
Gosh, I’m really sick of this argument.

Sure, everyone loves hand-crafted, beautiful, native apps. But I will tell you
this: it is possible to build a great app using any technology. It’s just a
matter of taste & effort. My favorite tool that helps me get my day job done
is VSCode. Do I care whether or not the damn thing is native or not? NO! Do I
care that it gobbles some meager gigs? NO! Memory not being used is memory
being wasted. Use my RAM, dammit. I can buy more. Use whatever you have to do
to keep making this lovely thing that saves me so much time everyday and
practically reads my mind as a JS developer! It has a elegant, raw beauty to
it that totally fits my needs.

If it uses some hybrid web technology stack, what do I care? Is it great? To
me, yes!

Make great apps. I don’t care how you do it.

~~~
blondin
you have to understand one thing.

if you have been using computers and applications that come with them for a
while you have an intuitive sense how how big, how fast, and how much
resources some of them should take.

that's what is happening here.

most people who are disagreeing with you know intuitively that it is not
right, for a chat app -- going for an easy target here -- to grab all your
available resources.

------
andrefuchs
There are pretty good Chrome Desktop PWAs like photopea.com (a free Photoshop
alternative)

I also like that PWA and Electron made more tools on Ubuntu available. Postman
and Gravit Designer are great examples.

Memory consumption and performance are problematic though for a lot of them -
Electron apps especially.

------
k__
They are, just not in the ways most users care about.

Sure, Ableton Live and Final Cut Pro are pretty rad, but how much percent of
the population uses such tools?

I even switched from Photoshop to Photopea and from Sketch to Gravit Designer,
because they are good enough and much less hassle.

------
MattGaiser
Very little matters for most pieces of software besides time to ship.

If the average user isn’t technical/is forced to use it, there is no business
reason to care about user battery life. There is no business reason to care
about user cpu usage.

Any reduction in user resource use would require greater business resource use
(i.e one of their engineers needing to learn native). Are users willing to pay
more for software that saves their battery life? Generally not, as most don’t
even know why their battery is draining or their computer is slow.

They just blame it on viruses, Windows, or general belief that their computer
is getting old.

------
sanxiyn
JavaScript is not slow. Python is slower than JavaScript, but if you compare a
native desktop app written in PyGTK against an app written in Electron, you
will see JavaScript being slow is not the problem.

~~~
pmlnr
JS is not slow. Every effin JS framework is. If there was a real stdlib for JS
it might work as an actual language.

------
watersb
I believe that Microsoft has tried to build a better Electron for at least the
past ten years.

The latest attempt is WindowsUI hosting React Native.

I think. This past week, I have tried to walk through a "Hello World" for this
pre-release platform, but I have failed to get a build system actually
working. Its the "keep installing software until it works or until your system
breaks, whichever comes first" problem.

For now, I have chosen to preserve my ignorance of Visual Studio's build
targets and project structure. I can only learn five new tools at a time.

------
Bnshsysjab
As someone who agrees that every electron app appears bloated, but wants a
minimal fuss, feature rich, attractive, cross platform UI, what are my other
options?

~~~
samwillis
QT

------
Schnitz
Native apps always win, except in the race to the bottom.

~~~
arkanciscan
Always bet on JavaScript

------
vkhn
This is such a silly article. Of course they are technologically superior.
This is like saying bare metal is better than a virtual machine. Of course.

But they are not universal for several reasons you fail to account for.

I won't bother categorically defending anything in this article, but I will
leave a single statement:

good, fast, cheap - pick two.

------
muthdra
It's always been. But the web stack is the most widely supported, low
development effort target we know and even though it's bad, there's value in
integrating and expanding it.

------
underdeserver
You actually can use sqlite, compiled with Emscripten, in a browser (storage
is done via IndexedDB).

