
Ask HN: Is there still a place for native desktop apps? - Jaruzel
Modern browsers these days are powerful things - almost an operating system in their own right. So I&#x27;m asking the community, should everything now be developed as &#x27;web first&#x27;, or is there still a place for native desktop applications?
======
userbinator
As a long-time Win32 developer, my only answer to that question is _" of
course there is!"_

The efficiency difference between native and "modern" web stuff is easily
several orders of magnitude; you can write very useful applications that are
only a few KB in size, a single binary, and that same binary will work across
25 years of OS versions.

Yes, computers have gotten faster and memory and disks much larger. That
doesn't mean we should be wasting it to do the same or even _less_
functionality we had with the machines of 10 or 20 years ago.

For example, IM, video/audio calls, and working with email shouldn't take
hundreds of MB of RAM, a GHz-level many-core processor, and GBs of disk space.
All of that was comfortably possible --- simultaneously --- with 256MB of RAM
and a single-core 400MHz Pentium II. Even the web stuff at the time was
nowhere near as disgusting as it is today --- AJAX was around, websites did
use JS, but simple things like webchats still didn't require as much bloat. I
lived through that era, so I knew it was possible, but the younger generation
hasn't, so perhaps it skews their idea of efficiency.

In terms of improvement, some things are understandable and rational, such as
newer video codecs requiring more processing power because they are
intrinsically more complex and that complexity is essential to their increase
in quality. But other things, like sending a text message or email, most
certainly do not. In many ways, software has regressed significantly.

~~~
thdrdt
I recently had to upgrade my RAM because I have Spotify and Slack open all the
time. Today RAM is cheap but it is crazy those programs take up so much
resources.

Another program I use a lot is Blender (3D software). Compared to Spotify and
Slack it is a crazy complicated program with loads of complicated
functionalities. But it starts in a blink and only uses resources when it
needs to (calculations and your 3D model).

So I absolutely agree with you.

I also think it has to do with the fact that older programmers now more about
the cost of resources than younger programmers do. We used computers without
harddisk and KBs of RAM. I always have this in my mind while programming.

The younger programmers may be right that resources don't matter much because
they are cheap and available. But now I had to upgrade my RAM.

~~~
ljm
It really surprised me when I downloaded Godot only to get a 32MB binary.
Snappy as hell.

Web apps masquerading as desktop apps are terribly slow and it's a surprise
we've got so used to it. My slack client takes a few seconds to launch, then
it has a loading screen, and quite often it will refresh itself (blanking out
the screen and doing a full-blown re-render) without warning. This is before
it starts spinning the fans when trying to scroll up a thread, and all of the
other awkward and inconsistent pieces of UI thrown in there. Never mind having
to download a 500MB package just to use a glorified IRC client.

I'm really enjoying writing code outside of the browser realm where I can care
a lot more about resource usage, using languages and tools that help achieve
that.

~~~
TeMPOraL
It's interesting to compare Ripcord[0] to Slack. Ripcord is a third-party
desktop client for Slack _and_ Discord. It has something like 80% of features
of the official Slack client and a simpler UI (arguably better, more
information-dense), but it's also a good two orders of magnitude lighter and
snappier. And it also handles Discord _at the same time_.

\--

[0] - [https://cancel.fm/ripcord/](https://cancel.fm/ripcord/)

~~~
MivLives
I wish so much that 3rd party clients weren't directly against the TOS of
Discord. I sorta miss the old days where it seemed like anyone could hook up
to MSN/Yahoo/AIM.

~~~
tumult
Where in the terms of service does it say that third party clients are
disallowed?

(It doesn’t.)

~~~
MivLives
While it does not explicitly state that, it does say:

"(ii) copy, adapt, modify, prepare derivative works based upon, distribute,
license, sell, transfer, publicly display, publicly perform, transmit, stream,
broadcast, attempt to discover any source code, reverse engineer, decompile,
disassemble, or otherwise exploit the Service or any portion of the Service,
except as expressly permitted in these Terms;" [1]

Given that the API is not public if you are not using a bot key, I would think
that using it with a third party client would take some form of reverse
engineering.

The devs also stated that other client modifications like betterDiscord are
against the TOS.

[1][https://discord.com/terms](https://discord.com/terms) (Under Right To Use
The Service)

~~~
tumult
Ripcord isn't a modification of their software. It's an original
implementation. I didn't look at any of their code.

------
jrockway
Native desktop apps are great.

The reason that people don't write them is because users aren't on "the
desktop". "The desktop" is split between OS X and Windows, and your Windows-
app-compiled-for-Mac is going to annoy Mac users and your Mac-app-compiled-
for-Windows is going to annoy Windows users. Then you realize that most users
of computing devices actually just use their phone for everything, and your
desktop app can't run on those. Then you realize that phones are split between
Android and iOS, and there is the same problem there -- Android users won't
like your iOS UI, and iOS users won't like your Android UI. Then there are
tablets.

Meanwhile, your web app may not be as good as native apps, but at least you
don't have to write it 6 times.

~~~
jcelerier
> Meanwhile, your web app may not be as good as native apps, but at least you
> don't have to write it 6 times.

I must be living in a parallel world because I use a ton of desktop apps that
aren't "written 6 times" \- and write a few, including a music & other things
sequencer ([https://ossia.io](https://ossia.io)).

Just amongst the ones running on my desktop right now, Strawberry (Qt),
Firefox (their own toolkit), QtCreator (Qt), Telegram Desktop (Qt), Bitwig
Studio (Java), Kate (Qt), Ripcord (Qt), all work on all desktop platforms with
a single codebase. I also often use Zim (GTK), which is also available on all
platforms, occasionnally Krita (Qt) and GIMP (GTK), and somewhat rarely
Blender. Not an HTML DOM in sight (except FF :-)).

~~~
_bxg1
In my experience Java GUIs are consistently even more laggy and unresponsive
than Electron apps. They may be lighter in terms of memory, but they never
feel lighter. Even IntelliJ and family - supposedly the state of the art in
Java apps - feel like mud on a brand-new 16" Macbook Pro.

~~~
nv-vn
I've definitely noticed the same on IntelliJ but weirdly enough Eclipse feels
just fine. IIRC both are written in Java, so maybe it comes down to the design
of IntelliJ moreso than the limitations of the JVM?

~~~
_bxg1
I used Eclipse for a while before switching to IntelliJ around ~2015 and it
actually seemed like a vast improvement, not just in terms of features but in
terms of performance. It still wasn't "snappy", but I figured I was doing
heavy work so that was just how it was.

Fast-forward 5 years and I've been doing JS in VSCode for a while. My current
company offered to pay for Webstorm so I gave it a try. Lo and behold it was
still sludgy, but now unbearable to me because I've gotten used to VSCode.

The one other major Java app I've used is DBeaver, which has the same problem
to an even greater degree. Luckily I don't have to use it super often.

------
ilrwbwrkhv
Every single app that I use, I try and make sure it is native. I shun electron
apps at all cost. It's because people who put in effort to use the native APIs
put in a lot more effort in the app in general based on my anecdotal evidence.
It is also more performant and smaller in size, things that I cherish. It also
pays homage to limits and striving to come up with new ways of overcoming
them, which hackers would have to do in the past. I don't think not worrying
about memory, CPU, etc are not healthy in the long run. Slack desktop app is
almost 1 gig in size. That is crazy to me, no matter the "memory is cheap"
mantra.

~~~
seventh-chord
The "<resource> is cheap" mantra also really only makes sense if you are
writing server code, where you yourself pay for all the memory your code will
ever use. If you deploy code to a large number of users it makes little sense.
If a million users start your app daily, and your app has a 5 second load time
and uses 300mb of ram, you are wasting over 50 days of user time, and hogging
close to 300 terabytes of ram.

~~~
hobofan
So you are telling me that I can easily exchange development time which I
would have to pay for end-user resources, which I would not have to pay?
Sounds like a great deal.

~~~
dialamac
In a fair society it should be taxed as an externality. There is a real
environmental cost associated with software bloat.

~~~
pkalinowski
People pay with electricity, uncomfortable temperature and fan noise, wasting
time working on slow apps.

Apparently, they trade off still worth it, as many electron apps are popular
despite these issues. Many times there is electron app or nothing.

~~~
p_l
Your last sentence hits the nail - many users don't have a choice in selecting
the application, and due to industry fads can't expect to have a better
option.

I can make a great chat system that uses fast native client, but it won't
change the fact that Corporation A paid for a slack license and won't switch
to mine.

------
ridiculous_fish
I will come at this from a different, philosophical perspective:

Web apps come from a tradition of _engaging_ the user. This means (first
order) to keep people using the app, often with user-hostile strategies:
distraction, introducing friction, etc.

Native desktop apps come from a tradition of _empowering_ the user. This means
enabling the user to accomplish something faster, or with much higher quality.
If your app distracts you or slows you down, it sucks. "Bicycle for the mind:"
the bicycle is a pure tool of the rider.

The big idea of desktop apps - heck, of user operating systems at all - is
that users can bring their knowledge from one app to another. But web apps
don't participate in this ecosystem: they erode it. I try a basic task (say,
Undo), and it doesn't work, because web apps are bad at Undo, and so I am less
likely to try Undo again in _any_ app.

A missing piece is a force establishing and evolving UI conventions. It is
absurd that my desktop feels mostly like it did in 1984. Apple is trying new
stuff, but focusing on iPad (e.g. cursors); we'll have to see if they're right
about it.

~~~
sbergot
What a perfect HN reply. Webapp bad. Native good. No justification. Just a
bunch of generalizations.

Gmail empowers me. Wikipedia empowers me. Github empowers me.

Of course native application are important. You don't need to rely on those
moralistic justifications.

~~~
saagarjha
You may not be aware of this, but the person you replied to has worked for
years on a native UI toolkit. And they provide justification, too: skills
don’t transfer between websites as readily as they do between apps. And while
I wouldn’t associate we applications are somehow morally inferior, the fact is
that many of today’s issues with increasing friction to drive engagement
originated on the web and are easy to perpetuate on the web.

------
ZoomZoomZoom
I'm going to be slammed for using these two words, but for any _real work_ you
need to have as few layers of indirection between the user and the machine as
possible, and this includes the UX, in the sense that it is tailored to the
fastest and most comfortable data entry and process monitoring.

I don't see any `web first` or Electron solution replacing Reaper or Blender
in a foreseeable future. One exception I'm intrigued with is VS Code, which
seems to be widely popular. May be I need to try it to form my own opinion.

~~~
burke
As an Electron hater, I’m constantly surprised at just how much VS Code
doesn’t suck.

~~~
PopeDotNinja
My personal evolution has gone from Sublime Text 3 to Atom to VS Code to
Sublime Text 3. I've never been a heavy plugin user, mainly sticking to code
highlighting. The thing I really like is speed. Sublime Text rarely chokes on
me. I love being able to type `cat some_one_gigabyte_file | subl` and getting
it to open up with little difficulty. VS Code chokes on files of non-trivial
size, and that was the thing I liked about it the least.

For anyone wondering why I'd open up a 1 GB file in a text editor, I guess the
answer is largely because it's convenient. Big log file? No problem. Huge CSV?
No problem. Complete list of AWS pricing for every product in every region
stored as JSON? No problem.

~~~
cgrealy
>> VS Code chokes on files of non-trivial size

VS Code isn't really designed as a general purpose text editor. It's meant as
a development environment.

If MS choose to optimise the experience of 99% of the use cases (i.e. editing
source code, which should never even approach 1GB), then that's the correct
call IMO.

>> For anyone wondering why I'd open up a 1 GB file in a text editor, I guess
the answer is largely because it's convenient.

I can completely appreciate the use of a text editor to open a massive log
file, etc, I just don't think that's something VS Code is designed for. You
can always use Sublime or Atom to open those files; while getting the nicer
(IMO) dev experience with VS Code.

~~~
fomine3
This. VSCode isn't Vim and vice versa.

------
bhauer
I prefer well-designed desktop applications to web applications for most
things that don't naturally involve the web:

* Email clients (I use Thunderbird)

* Office suites

* Music and media players

* Maps

* Information managers (e.g., password managers)

* Development tools

* Personal productivity tools (e.g., to-do lists)

* Games

As Windows starts on-boarding their unified Electron model (I can't recall
what they have named this), I suspect we'll see more lightweight Electron
desktop apps. But for the record, I like purpose built, old-fashioned desktop
applications. I prefer traditional desktop applications because:

* Traditional applications economize on display real-estate in ways that modern web apps rarely do. The traditional desktop application uses compact controls, very modest spacing, and high information density. While I have multiple monitors, I don't like the idea of wasting an entire monitor for one application at a time.

* Standard user interface elements. Although sadly falling out of favor, many desktop applications retain traditional proven high-productivity user interface elements such as drop-down menus, context menus, hotkeys, and other shortcuts.

* Depth of configuration. Traditional desktop apps tended to avoid the whittling of functionality and customization found in mobile and web apps. Many can be customized extensively to adapt to the tastes and needs of the user.

Bottom-line: Yes, for some users and use-cases, it still makes sense to make
desktop apps. It may be a "long-tail" target at this point, but there's still
a market.

~~~
WilliamEdward
Email doesn't naturally involve the web? What?

~~~
PNWChris
I believe they’re referring to the web as port 80/443 http(s) traffic. It’s
the old World Wide Web vs internet distinction, if you will.

Email really is just a protocol for message sending, and it lives on it’s own
port with its own server. If you have an email client and access to an email
server (POP/SMTP/however), you can use email over the internet but without the
“web”.

Basically, the web email client ought not be the only email client.

~~~
WilliamEdward
It was the ambiguity of the word 'web' that tripped me up. You still need a
network of computers for email to be useful.

~~~
Jtsummers
`Web`[0] is shorthand for `World Wide Web` which is specifically about
HTTP/HTTPS and/or the applications built on that protocol. It is an entirely
unambiguous word in this context.

`Internet`[1] is distinct, and that's the general purpose network of networks
that you refer to which the Web is built on top of.

[0]
[https://en.wikipedia.org/wiki/World_Wide_Web](https://en.wikipedia.org/wiki/World_Wide_Web)

[1]
[https://en.wikipedia.org/wiki/Internet](https://en.wikipedia.org/wiki/Internet)

------
fbelzile
I make a living developing software only available on Windows and macOS. That
said, if I didn't need to interact so much with the operating system, I'd be
making a web app. It all depends on what you want to make though. Video
editing software? Native app. CRUD app? Web app.

You may also want to consider pricing implications of both. Desktop software
can usually be sold for a higher up front cost, but it's tough sell to make it
subscription based. SaaS would make your life a lot easier if you have a
webapp. People are starting to get used to paying monthly for a service
anyway.

Pro tip: If you decide to make a native app, don't use Electron. Instead, use
the built-in WebBrowser/WKWebView components included in .NET and macOS.
Create the UI once using whatever web framework you want, and code the main
app logic in C#/Swift. Although the WebBrowser control kind of sucks right
now, Microsoft is planning on releasing WebBrowser2 which will use Blink. I
think they might also have it where the libraries are shared between all apps
using it, to further reduce bloat. The old WebBrowser component can be
configured to use the latest Edge rendering though by adding in some registry
keys or adding this meta tag:

<meta http-equiv="x-ua-compatible" content="ie=edge">

~~~
OkGoDoIt
I understand the concept of making a native app to include using the native UI
platforms. What you described is hardly more native than electron, which is
basically a web app at heart.

Or maybe there needs to be a consensus on terms. Do people consider electron
apps to be native? I would put them in some weird middle ground, but
definitely closer to web technologies than native development.

~~~
neurostimulant
The main complain about electron app is due to their bundling of complete web
browser runtime, which is over a hundred of MB, not to mention the big memory
requirements. By using platform's built-in webview component, your app size
will hardly any bigger than the total size of the zipped html+js+css of your
app. If you're going to use web stack to develop your desktop app anyway,
might as well try using native ui webview first if you don't need any
electron-specific feature.

------
dmitrybrant
I specialize in data recovery / digital forensics tools, which require very
low-level disk access to be able to read physical media at the block level. I
doubt there will ever be an HTML5 standard for low-level disk access.

But aside from my particular specialty, I also prefer any other software I use
to be fully native. I'm surprised that's such a controversial thing to ask for
these days. All I ask is so precious little:

* I want the software I use to be designed to run on the CPU that I own!

* I want software that doesn't require me to upgrade my laptop every two years because of how inefficient it gets with every iteration.

* I want software that isn't laughably bloated. I think we have a real problem when we don't bat an eye upon seeing the most rudimentary apps requiring 200+ MB of space.

~~~
umvi
I remember hanging out in /r/Unity3d and some newbie posted a download for
their completed game. It was super basic - just a game where you move a cube
around a grid, but the size of the game was insane, like half a gig.

The dev who posted it seemed perplexed when people told him the game was 100x
bigger than it should be.

~~~
peteforde
I hope that you did the kind thing and showed them how to adjust what gets
compiled into their package, depending on whether they are targeting a
development or production build.

Nothing worse than people who mock beginners showing their first work. We were
all there, once.

------
alasdair_
There are still a lot of fields where performance matters. This is especially
true with apps that need low latency, like most games. Something like Stadia
may be fine for a casual gamer but it still feels laggy to many, especially
those used to gaming at 144Hz+ with almost zero input lag and gsync.

VR is another area where native desktop is still superior.

Then there is anything that is dealing with a lot of local data and device
drivers. Video editing for example.

Development tools that work in a browser are getting better but native (or
even just Java-based like IntelliJ stuff) still seems superior for now.

Stuff that doesn't use TCP, like network analysis tools, either need to be
done as a desktop app or need to run a local server to point the webapp used
to control them to.

I guess what I'm getting at is that if you need low-level access to the local
device or if you care a lot about things like rendering performance then
native is still the way to go.

~~~
jfkebwjsbx
Stadia's games do not run in a browser.

The client you use to interact with the stream is a web page, yes, but the
actual game running in their servers is a native Linux application.

~~~
bartread
Yes, but I think that's the point isn't it? Of course the game runs on a Linux
server because it couldn't possibly run in a web page due to performance
reasons. Hence the complaint about lag.

You either get lag from the network roundtrip or lag from the crap performance
in a browser (or you choose to degrade the experience, e.g., by reducing
graphics fidelity), but one way or another you're experiencing lag (or a
compromised experience).

Ergo the same game implemented as a native app running locally is going to be
better[1].

 _[1] At least technically. It could of course still be a rubbish game._

------
zadjii
I mean, we built the Windows Terminal as a native application because we
didn't want users to have to be saddled with 40MB of a webview/Electron just
to boot up a terminal. It might take us longer to make the terminal as feature
rich than it would have with JS, but no amount of engineering resources could
have optimized out that web footprint. When we think about what the terminal
looks like in 5 years, that's what we were thinking about.

~~~
bhauer
Thank you. As you say, in the long haul, Windows Terminal is considerably
better than it would have been thanks to that decision. It _feels_ responsive
and lightweight; unlike any Electron app, and that is greatly appreciated by
many users, myself included. I look forward to each new version.

~~~
sebazzz
Didn't they eventually did some crazy optimizations to keep the terminal in VS
Code performant?

~~~
Cthulhu_
They still do; for years now I read the patch notes and every time there's a
segment dedicated to the terminal with things like font support or sane
selection, things that IMO are both basic features and which should be in
native terminal emulators already.

also I've never used the VS Code terminal, iterm works better for me. Also
because it's its own dedicated app, so I can actually alt-tab to it instead of
having to learn whatever shortcut it would be in the editor.

------
feifan
IMO desktop apps aren’t quite equivalent to native apps. Native apps look and
behave in a consistent way. They have

• Familiar UI primitives: \- Controls and chrome are in the same place \- Font
sizes are the same across apps \- Consistent icons and button shapes

• Support standard keyboard shortcuts (including obscure ones that developers
re-implementing these UIs might not know about) \- All the Emacs-style
keybindings that work in native macOS text fields but are hit-or-miss in
custom web text fields \- Full keyboard access (letting me tab and use the
space bar and arrow keys to interact with controls)

• And consistent, predictable responsiveness cadences \- Somewhat contrived
example: In Slack (browser or Electron app), switching between channels/DMs
(via ⌘K) has a lag of about 0.5–1 second. If I start typing my message for
that recipient during this lag, it actually gets saved as a draft in the
channel that I just left and my content in the new channel gets truncated. I
don’t think that kind of behavior would happen in a native macOS app, which
renders UIs completely synchronously by default/in-order (so it might block
the UI, but at least interactions will be in a consistent state)

~~~
pbhjpbhj
Consistency is maybe overrated?

I purposefully make my FF unlike the other apps on my system. I use a couple
of workarounds to prevent OS level keybinds from working in some apps.
Sometimes a completely purpose made UI is better, sometimes.

In general, consistency [in desktop UI] is good, but there are good reasons to
break it.

~~~
feifan
The difference is _you_ breaking consistency for your use cases, vs some
product designer somewhere breaking consistency for all of their users for
whatever reason without the end user having any say in it.

Pithily, the cost of a product designer’s novel portfolio piece is
externalized onto their captive users.

------
implicit
If you are going to expect me to run your software in an always-on manner, I
would greatly appreciate a native application.

I frequently do light computing on a Surface Go. It's a delightful little
device and I love it, but it is not powerful enough that I can leave gmail,
Slack, and Discord open all the time.

I don't have enough RAM to run another web application but I could very easily
afford a native app or two.

~~~
znpy
I have an old ThinkPad X200s that I turn on from time to time. I keep a fedora
installed and updated just in case, and since I'm there, i also sync my
nextcloud stuff.

E-mails using claws-mail are not a problem. It generally runs fast enough
until I open firefox and web stuff in general.

~~~
squarefoot
Claws Mail on an old Atom is a lot faster than webmail on pretty much anything
else. This probably illustrates best the difference between the two
approaches.

~~~
pmlnr
I remember times when webmail basically meant squirrel mail. It was fast over
an 56k modem, but desktop was always better.

[http://www.squirrelmail.org/](http://www.squirrelmail.org/)

------
hermitcrab
Yes, I hope so. I have just released a new data transformation/ETL tool for
the desktop (Qt/C++ app for Mac and Windows). The advantages of desktop are:
-performance/low latency -richer UI (e.g. shortcuts) -privacy

But there are trade-offs: -the user has to install/upgrade it -less insight
into what the user is doing -harder to sell as a subscription

I wrote this in 2013 and I think it is still mostly true: 'Is desktop software
dead?' [https://successfulsoftware.net/2013/10/28/is-desktop-
softwar...](https://successfulsoftware.net/2013/10/28/is-desktop-software-
dead/)

~~~
samanator
Cool article!

------
roel_v
Lots of software would be better (from the user's POV) as a desktop app.
However as a developer and as a software business owner/investor, it's (much)
better to write web apps. So it depends on what you're asking here. Should you
invest in desktop dev skills to further your career? No. Should you write your
software idea as a desktop app if you want to make a business of it? Not if
you can avoid it. If you're asking something else, well I guess the answer is
'maybe'.

~~~
chadcmulligan
> However as a developer and as a software business owner/investor, it's
> (much) better to write web apps.

Why do you say that?

~~~
rohan1024
I think he is saying that because with webapps you have

\- control over your software and updates

\- no one can pirate your software/service

~~~
ken
How do you have more "control over your software" with a web app? With a
native app, I can do virtually anything. With a web app, I can really only do
what (Google ∩ Apple ∩ Microsoft)'s web browser teams decided to prioritize,
and allow, and optimize.

As for 'pirating', is that a serious concern these days? I've only ever heard
about it being an issue at big companies selling software to other big
companies, where it's solved with "license servers".

~~~
hellisothers
I think they mean rapid, continuous deployment. If it’s a web app you can push
out changes every day to near universal adoption. With a native app you have
to cajole users to update

~~~
ken
There are auto-updaters for desktop software, too.

------
WaltPurvis
If you develop an application that runs in the web browser, I won't use it.
That's not some dogmatic principle of mine, it's just an empirical fact.

I use only one browser-based application: Gmail.

I've never used another browser-based application and I can't imagine that I
ever will unless there's truly no alternative and it's forced on me by an
employer.

I've happily paid for dozens of desktop applications, and I'm even semi-
happily paying for around ten of them that have switched to a subscription
model, but I never have and likely never will use browser-based applications
even if they're free.

~~~
kleiba
I don't get the downvotes: the original question asked about opinions on web-
based vs. native apps, and this guys is giving exactly that. And what else
could you do, you can either cite some usage statistics or give personal
assessments.

~~~
kleiba
What, and now even my own comment gets downvoted?! If there was at least a
reason given... coward.

------
Ingon
In some (most) cases, desktop apps could be better - performance, latency,
offgrid capabilities, and even privacy. In most cases, I prefer offline
desktop apps, then their online counterparts.

One area which is really tough to nail is cross-platform support though.
Getting a good app on one system is hard enough, getting it in all three -
rarely done. This is one of the things where web shines.

From business standpoint, I think web-first with an eye on native works for
majority of cases. That is, as long as the majority of users don’t care about
the above. In some future, if we start valuing efficiency and especially
privacy more, this could turn around. But it feels like, even then, web will
probably find a way to make more sense for most people.

~~~
funcDropShadow
But building a good app on all three major operating systems is not solved by
an abstraction layer, neither by a cross platform gui toolkit nor by a web
layer. Different operating systems have different conventions, metaphors and
standards. A portable application will usually feel foreign on all, but the
developer's primary platform. Unless, the developers invest in adapting to the
differences of the platforms.

------
Youden
Yes, there's definitely still a place for them.

I'd say that that when you're writing an application which is fundamentally
just a pretty wrapper (e.g. it exists to take user input and pipe it over HTTP
to some web service or use it to generate a command for some other binary) and
your users don't care about performance, resource usage or reliability, it
makes sense to use a browser. Your application is very UI-focused and if
you're already familiar with HTML, CSS and JS, use what you know.

However if you're working on an application that has strict resource usage,
reliability and/or performance requirements like say a control system for
industrial equipment, a 3D game, a video encoder, photo editing software, or
software that's going to be run on an embedded system, you're going to find it
difficult to do what needs to be done with a browser/wrapper. It can be done
for sure but it'll be something you work around rather than with.

~~~
hellisothers
100% this, it depends on the context, and as one other person mention it
depends on your goal.

------
egypturnash
I like to take my laptop out to a park and work with all the radios off to get
the best use out of my battery. I also like to do complicated things with a
lot of files that need to be organized in a real filesystem, the directory
structure of a graphic novel can easily match the complexity of a program’s
source tree.

Your web app, which requires several extra levels of indirection between the
code and the bare metal, an online connection, quite possibly is built on a
framework that tends to suck down a significant percentage of my CPU even when
it’s idle in the background with all windows closed, and its own weird file
management that’s probably a giant hassle when I need to get my work into
another program, has no place in my world.

------
Slartie
We're building POS applications for major retailers, and for this kind of
software, native is king and will stay for the foreseeable future (with a few
exceptions confirming the rule, of course). These applications need tight
integration with exotic hardware, must satisfy weird fiscal requirements often
written with native applications in mind, must run rock-solid 24/7 with daily
usage and predictable response times for weeks without a restart, must be able
to provide core functionality without interruption in offline situations while
syncing up transparently with everyone else when back online and usually run
in an appliance-like way on dedicated hardware (start with the system, always
in foreground, only major application on the system, user should not be able
to close or restart it, updates and restarts triggered by remote
support/management).

All of this is much easier to do with native applications, running them in a
browser just adds the need for crazy kludges and workarounds to simulate or
enforce something you get for free if running native. Also you end up with
managing hardware boxes with periphery attached and software running on them
anyway, so whether managing a native application that is a browser which then
runs the POS application or whether directly managing the POS application does
not save you any work; if anything it even gives you an additional thing to
manage, which increases maintenance effort and potential for failure (which
quickly is catastrophic in this business, POS down today effectively means the
store can close its doors).

Back-office applications in the same space are actually pretty well-suited for
a web application, and frequently implemented as such today.

~~~
kanwisher
A lot of ATM machines and POs systems are glorified web apps. Not sure why a
web app can’t be rock solid. Certainly easier to go native since you only have
one platform, but I don’t see it being required

~~~
Slartie
Notice that I didn't say anything about that being impossible. I just said
it's harder to meet most of these requirements with a web app, because you
have to solve problems that you simply wouldn't have otherwise while gaining
practically no advantage whatsoever, which is why most people decide to keep
building native applications. Some people happily shooting themselves into the
foot does not invalidate this assertion.

Also especially ATMs are notorious for hanging inexplicably for seconds, not
reacting swiftly to user input, and generally providing a rather poor UI
experience. The performance and quality standards for POS systems, at least
our standards, are quite a bit higher.

------
robbrown451
I'm all for web apps, unless you need to do things they don't do well. If you
are doing, say, video editing -- yeah I want a native desktop app for that. At
least currently.

But those things are getting fewer and fewer. And it annoys me to no end that
I can't, say, run my favorite screencast/video editor (screenflow) on my
Windows or Chromebook machine, since it seems pretty deeply tied to the OS. I
don't want to have to learn another one, and I don't want to replace my Mac
which is on borrowed time.

That said, I use a lot of apps like Gimp and Inkscape on my Mac, and they may
be technically native, they can be really awful about "feeling native." I
don't mind inconsistent user interfaces so much, as long as it is mostly
cosmetic. But I've spent SO much time in both of those searching for lost
windows, etc. (OMG Inkscape devs, has anyone even tried it on multiple
monitors???) Things you never run into with "true" native apps (those two use
GTK toolkit).

So, I certainly recommend web apps if you app can run sufficiently fast or
otherwise can get away with being a web app.

------
alkonaut
Take any app that uses all cores nearly 100%, maybe maxes out the GPU eats
3-5GB of ram, and is a 2-100GB install.

Those will always be native.

These are your Cad programs, your video editors, your AAA games.

You can make a cad program in a browser too. But you trade a chunk of perf for
convenience, and thats only rarely acceptable.

Anything that could ever be done in a mobile app (chat, media consumption, ..)
those might be possible to do in a browser. But you didn’t even really need a
computer for them to begin with.

~~~
ComputerGuru
Tell that to Autodesk. Fusion is like 70% web, slow, and bloated. They don’t
even have a good excuse since the whole UI is just a shell around a canvas and
could easily be made native, it’s not as if they’re actually benefiting from
the DOM or CSS.

~~~
alkonaut
That’s the one I was referring to. That is, Fusion is a tradeoff that isn’t
always a acceptable (and still it’s not completely web based).

------
shams93
Well the browser is still not good at things that say Blender or Protocols can
do. Media pros still need desktop software for example audio latency in chrome
is far too high to use it for any serious pro audio applications.

------
pier25
It's true that many apps could be replaced today with a website, specially
those that are basically capturing and showing data.

But there are still many areas where native is king.

\- Games

\- Audio / Video work

\- Adobe type of work (photo editing, motion graphics, vectors, etc)

\- 3d

\- Office. For me Google docs is enough, but not for heavy users.

\- Desktop utilities (eg: Alfred, iStatMenus, etc). You could certainly use a
web UI for those, and it would probably be fine , but you'd still need some
native integration.

------
derision
The web versions of Office software still feels way less polished than the
desktop version. It just doesn't feel quite right

------
gfxgirl
It really depends on the app.

A 3d modeling package? Although Clara.io exists most of the time I'm dealing
with 100s of megs of data so native wins. Creating a game? Mostly same though
I can imagine some limited online game creation tool even the small sample 3D
platformer for unity is 3gigs of assets so a game editor native seems to win.
Photo editing, when I get home from vacation there's 100gig of photos so
native wins for me. Video editing same thing.

On the other hand there are apps I have zero interesting in being native.
WhatsApp, Line, Slack, Facebook, Office, Email, Discord, etc. I'm 100% happy
with them in a browser tab. Native apps can spy on way more than browser apps
(maybe less on Mac). They can install keyloggers, root kits, scan my network,
read all or most of my files, use my camera, mic, etc.

I also use 7 machines regularly. Being able to go to any one and access my
stuff is way more convenient than whatever minor features a native app would
provide.

------
apatheticonion
Installable web applications are an incredible concept that have saved my
customers and myself countless hours (and money).

The experiences are fantastic. The applications look native to the platform,
with coloured title bars and OS specific window decorations.

The performance is not noticeably different than the equivalent native
experience. I am taking advantage of multi-threading through web workers, web
push notifications (sorry iOS), and the (single) code base is maintainable and
easy to work with.

I don't see how a GUI framework like QT or several native applications would
make a more effective alternative either aesthetically or financially.

I'd consider it uncontested once installable web applications have deeper
system access (filesystem, etc).

The addition of web assembly bindings for direct DOM manipulation and directly
importing wasm binaries via a script tag would complete the browser as the
most sensible customer facing front-end environment.

RE performance, look at Figma.

------
nikivi
Browsers have one huge problem and that is they override important hotkey
space (like cmd+w, cmd+f for searching etc). So native apps will always
provide a better experience.

~~~
rbinv
Google Docs actually hijacks CMD+F.

~~~
kroltan
And nowadays even websites that don't hijack the shortcut itself are non-"find
in page"-able, due to the trick of disposing unused/out-of-view components
(which is actually I suspect what Docs is doing, too, but they made their own
find so people wouldn't get stuck)

~~~
samanator
Yup you're right, ay least for Google Spreadsheets. GS is a canvas app so what
you see is exactly - and only - what is rendered.

Though, I think Google Docs is not a canvas app.

------
davinci26
Controversial opinion: Yes, native desktop apps are the future.

Msft is pushing on react-native-windows and macOS has project catalyst. React-
native is making cross-platforms native apps viable.

Apps are way more immersive than the browser and it allows the developer to
give a gamification experience.

~~~
Hackbraten
What do you mean by “gamification experience?”

~~~
davinci26
I had revolut or wealthsimple in mind that both make trading/exchanging money
more like a game and a wholesome experience.

I think because of the app the user is "forced" to concentrate and use the
whole screen of the app (especially for the phone) it enables a more immersive
experience. Whereas most browser apps feel like a transactional thing.

------
perilunar
What a crazy mixed-up world: on desktop we ask if there's a future for native
apps, while on mobile we ask if there's a future for web apps.

------
JKCalhoun
No internet? No web-app.

I suppose I am increasingly frustrated with the inability to use my computer
if it has no internet....

~~~
chrismorgan
This needn’t be true. You can use a service worker to make the code load when
offline, and IndexedDB to store data.

As a trivial example,
[https://jakearchibald.github.io/svgomg/](https://jakearchibald.github.io/svgomg/)
(which has no data storage requirements) works just fine offline.

Offline support is a banner feature of the PWA (progressive web apps)
movement.

~~~
ken
I was excited to see how this worked, so I visited the page, clicked around to
see what it did, disconnected from my network, and tried opening the page
again in a new window. I got the usual browser error page: "You Are Not
Connected to the Internet". So I connected to the network, loaded the page,
_then_ disconnected from my network, clicked the Demo button, and got:
"Couldn't fetch demo SVG".

So by trial and error, I found that I need to load the page before
disconnecting, and only use the 1st of the 5 buttons on the side (even "About"
requires network connectivity). Then it works offline. Which is pretty cool!

But _every_ native application I have works perfectly offline, and I don't
need to do anything special ahead of time, or worry about which parts might
not be available. There's a big difference between "some parts may work
offline sometimes" and "entire app will definitely work offline always".

From decades of experience, when a "trivial" app struggles with demoing a
feature, there's little chance it'll be widely supported among real apps. PWAs
have been "any day now!" for 10 years now.

~~~
chrismorgan
Sounds like the service worker didn’t register for you.

The logic that decides whether the browser accepts service workers is a little
bit iffy. My vague recollection is that browsers default to something like
“when you access the site for the second time, keep the service worker”.
(Don’t quote me on that, and if anyone knows better, please correct me.) “Add
this to your home screen” functionality will definitely make the service
worker go. (That’s mostly for mobile browsers only at this time, though
desktop browsers will _eventually_ get it consistently available, as we’ve
been promised for… hmm, about 8±2 years, I think.)

Privacy and blocking extensions may block service workers from being
registered, too.

If the service worker is loaded, then it loads just fine with no internet
connection, and the demo works too. The contribute and about links, being to
GitHub, still don’t work.

I first actually discovered this completely by accident: I was offline, and
thought “I need to shrink this SVG file, so I’ll open a tab to the SVGOMG URL
and that error page will remind me to do it when I reconnect; huh, it _loaded_
, must have a service worker. This is _really great_.” On later reflection, I
realised that it being by Jake Archibald (a big mover in the service worker
space) pretty much guaranteed it was going to work offline.

------
40four
I‘ve always been on the fence about this. I can see both sides, and don’t have
a strong opinion either way. But answering is there still a _place_ for
native? I think yes for sure! I guess it comes down to if it is really
important to your philosophy as a developer, or your type of app could really
benefit from native capabilities.

A good example of a recent app that chose to leverage native platforms is
Table Plus. They are developing native apps on Mac, Windows, and Linux. I
respect the effort/skill and dedication required to pull this off!
[https://tableplus.com/](https://tableplus.com/)

------
zabil
Not yet for music production. DAW's, software synthesisers, drum machines,
latency matters here.

~~~
slyzmud
Funny that the other day I discovered bandlab. It's not professional but for
my hobby usage it's the best I've found

~~~
dantheta
Same here - I was a Cakewalk user back in the 90s, and decided on a whim to
find out if it was still around.

------
spenvo
Native apps can take advantage of OS APIs that are much richer than those via
the browser (or Electron) pass-through APIs.

For example, I've made a Mac app that lets you customize your Spaces (virtual
desktops), assign names to them, jump to specific ones, track your time spent
across them, and trigger custom events when you move to specific ones. None of
this would be possible via a web app or electron app. Project homepage
[https://www.currentkey.com](https://www.currentkey.com), app link:
[https://apps.apple.com/app/apple-
store/id1456226992?pt=11998...](https://apps.apple.com/app/apple-
store/id1456226992?pt=119982183&ct=yc&mt=8)

And as long as there is differentiated hardware between platforms, there will
be opportunities for innovative native apps. For example, though I personally
don't love the Touch Bar, there are interesting native app projects around
that like Pock:
[https://github.com/pigigaldi/Pock](https://github.com/pigigaldi/Pock)

~~~
ahmedbaracat
Checking your app, sounds very useful :) Thanks for building it

~~~
spenvo
Enjoy! And thanks for the kind words

------
fxtentacle
A naive desktop app is the deluxe option. It'll always be more efficient than
even the best web-technology based app, because it can skip tens to hundreds
of layers of abstractions (e.g. Javascript, HTML, CSS, DOM) if done right.

So the questions are:

\- do your customers care about performance? (gaming, 3D animation, music
editing)

\- are resource limits relevant? (embedded systems, mixing desks, broadcast,
dvr)

\- are people concerned about battery life? (pagers, medical equipment)

If none of these reasons for native apply, you can probably make your users
suffer through a web app, which will be much cheaper for you to produce and
maintain.

That said, people definitely notice the sluggishness that all web apps have. I
mean those 100ms from click to screen update. So your customers will most
likely be able to intuitively feel if your app is native or not, with native
feeling better.

For some groups of customers, this premium feel might be a decision factor.
For example, Apple TV (super responsive) versus Netflix (objectively slow
website).

------
naikrovek
The amount of ignorance in here masquerading as experience and knowledge is
staggering.

My father was right about so many things. The one I have in mind right now is
when he said "age is another form of strength against the nitwit, because
those with experience see straight through those with misplaced confidence."

He was right. I'm not calling anyone here a nitwit or anything, please be
clear on that.

It's just amazing how _wrong_ some of you are, while sounding so absolutely
sure of yourselves. A few don't even get easily researched technical details
correct, while trying to sound authoritative.

My point is that maybe this is related to why software development is in the
sorry state it is in today: the ignorant are confident they know it all, and
the knowledged are confident that they know very little.

------
flarg
IMHO native applications represent a valuable class of niche software tools
that deliver very highly specialised functionality in concert with desktop
software. Add ons for MSProject and Excel abound and there really isn't an
equivalent for online tools or indeed a viable or stable market.

------
chipotle_coyote
Whenever this sort of question comes up, I always look over at my macOS dock
and see what's running or permanently docked there:

\- Marked (Markdown previewer/converter): native.

\- Transmit (file transfer): native.

\- PDF Expert: native.

\- ImageOptim (image optimizer): native.

\- Fantastical: native.

\- MailMate: native.

\- Terminal: native.

\- iA Writer: native.

\- Safari: native.

\- CodeKit: native.

\- Dash: native.

\- GitUp (GUI Git client): native.

\- 1Password: native.

\- Telegram: Electron.

And a few that aren't running now but I run very often:

\- Slack: Electron.

\- Visual Studio Code: Electron.

\- BBEdit: native.

\- Nova[1]: native.

\- MacVim: reply hazy, ask again later[2].

So, I mean, I can't speak for everyone, but it doesn't seem to me like native
apps are going away in the near future, at least.

[1]: Nova is a still-in-beta code editor I'm trying out as a possible
replacement for VS Code. Code still "wins" on features for me, but Nova is
pretty cool, and still in beta, so...?

[2] I mean, MacVim _is_ a native "GUI," but it's, you know, Vim.

~~~
zelly
Telegram is Qt

~~~
chipotle_coyote
Oops. Thanks!

...although I realized just now that I'm actually using the native client, so
it should actually have been another "native" in my case. D'oh.

[https://github.com/overtake/TelegramSwift](https://github.com/overtake/TelegramSwift)

------
bArray
I think there are some applications or problems that are likely to be
favourable to native desktop apps for a long time. For inspiration, simply
look at what hasn't already become web based. Some things I thought of:

1\. Heavy lifting - As others have mentioned, running some code in a browser
is quite a few times slower than locally. As Moore's Law comes to a screaming
halt we're going to be need to get better at creating efficient software
rather than relying on the underlying hardware to get faster.

2\. Capability - Some things are inherently difficult to do in the browser,
such as custom networking, calling kernel functions, accessing various
hardware, etc, etc. You can always have your native app launch a web-based
front-end, but going back the other way is not possible by design.

3\. Hardware Access - Sometimes you need to access a camera, USB device, GPIO,
I2C, SPI, run architecture specific instructions on the CPU, access the GPU,
etc, etc. Again, the browser typically won't let you access these by default.

4\. Security - This comes in a few parts: (a) You're able to bypass "most"
security and do what you want within reason. As long as the user ran your
application you usually have the same privileges. (b) Now that you're dug-in
you can enforce a level of security that may not easily be available
otherwise. (c) Features such as app signing mean that the user can more easily
guarantee the app came from you, rather than relying on their ability to read
the exact URL in some email at 2am. If I run `apt-get install <X>` or
equivalent in other OSes there is a chain of accountability.

5\. Memory - Put simply the browser adds massive overhead to any application
and typically has inefficient data structures. Compare something like Atom [1]
to any equivalent native editor for example. (There is some existing efforts
in comparing editors [2].)

[1]
[https://en.wikipedia.org/wiki/Atom_Editor](https://en.wikipedia.org/wiki/Atom_Editor)

[2] [https://github.com/jhallen/joes-
sandbox/tree/master/editor-p...](https://github.com/jhallen/joes-
sandbox/tree/master/editor-perf)

------
photawe
Oh yes there is. For one, thinking "desktop" is very very different than
thinking "web".

Dealing with "state" is much better/easier/clear in desktop than in web.

An app on desktop, if well made, will be insanely more responsive than a web
app. That's one thing - the other thing is there are cases where
speed/resources will dictate that the app should be desktop. A simple example
is a video editor (such as, the one I'm developing, but that's besides the
point). Sure, you can have a video editor as a JS app, but that will be
incredibly trivial compared to a desktop app.

I'm not saying that you can't match any desktop feature on to web. I'm saying
that some will take 10x+ time and resources (and thus, an insanely higher
complexity) than desktop. And some features, they are simply not feasible to
do on the web. Let me give you an example: time-remapping for a video editor
(one thing that I'm gonna implement soon). This is such a complex issue,
requiring advanced caching + lots of RAM + fast rendering, that implementing
it in a browser is simply unfeasible TODAY.

As things become feasible on the web, lots of them begin by being 10x+ more
complex than desktop (this gets lower in complexity in time), for one thing.
And for another thing, that basically means more things that were unfeasible
for desktop will now become feasible there (but still not feasible on web).
And this cycle continues.

In conclusion - there will always be a place for native desktop apps IMHO.

------
neya
I have a slightly different take - I wrote my own CMS based on Elixir. It's a
static site solution, which means it generates, static HTML files that are
then uploaded to a CDN (Eg. Netlify). My UI is done in VueJS and my database
is actually inside of my application. I wrote a simple electron wrapper
combined with docker in the background to deliver my CMS solution to my
clients and it has worked really well for me. The reason being, I don't first
of all need to collect my clients' data and store them on a central server, at
the same time, my clients don't need to bother finding a hosting provider to
maintain the site. They can just run this thing off their desktop and publish
and be done with it. What's nice is, if they need updates and new features,
they got to pay, which supports me and my work as well.

In fact, the whole project started out as writing a replacement for Wordpress
from scratch. At least 6 of my clients' websites got hacked and one of them
had a million visits a month. Simply because of stale plugins (it's easier to
accumulate them than you think). So, long story short, I absolutely believe
there is a place for desktop apps even in 2020.

BTW, I plan to open source my CMS soon :)

(and I do write about my journey here - [https://medium.com/build-
ideas](https://medium.com/build-ideas))

------
feifan
Finda’s architecture[0] is great for this discussion.

On the one hand, you can say “look, an Electron app that’s actually fast!”

On the other hand, you can say “wow web apps are slow; it takes ~50x longer to
render a basic list than to regex search across tens of thousands of strings”.

From a performance perspective, the JS part of the stack certainly isn’t
helping.

0: [https://keminglabs.com/blog/building-a-fast-electron-app-
wit...](https://keminglabs.com/blog/building-a-fast-electron-app-with-rust/)

------
theredbox
If computers get significantly faster then no...but at this point I always
reach for a native application if I have the choice.

The only non-native app I dont detest that much is VS Code but it still feels
painfully slow compared to something like Sublime Text.

Lets look at the chat apps that provide a similar functionality.

* Teams

Takes between 600-800MB on my PC. It's sluggish as hell and will often choke
to re-render if I click on something.

* A native chat app Takes 15MB...Is just as eye candy as Teams and yet i dont care if it's running or not.

------
bullen
In the short term 3D MMO's are desktop only. In the long term everything goes
back to being desktop because the abstractions waste energy. Everything beyond
vanilla HTML + CSS + .js for GUI is going away!

I'm also going to burn some karma and re-iterate that there are only two
languages worth using: JavaSE on the server (build everything yourself) and
C(++) on the client. We need this to be understood so that fragmentation can
be reduced!

------
mdrachuk
It does feel better to use a native app. Marketing as a "premium" product
could work.

------
bwindels
I share the frustration with everything moving to slow and bloaty electron
apps.

But wrt to electron apps and using web technology instead of native
frameworks, I think it depends a lot as well how well the web code is
designed. I've been prototyping a Matrix chat app [1] in a very minimalist
way:

\- no framework or library used for UI, "state", ... to have complete control
on how and when things are updated and rendered.

\- use indexeddb optimally to keep as little things in memory as possible.

My 2 main conclusions from this are:

\- Web technology can perform very well. The chat client uses only 3.5mb of
Javascript VM memory on a 200 room account. It visually outperforms some
native apps as an installed PWA on Android on a low-end device. I attribute
this to the fact that web browsers are very optimized.

\- It takes more time to engineer an app properly like this, even in a
language like javascript. I can imagine it's hard to justify the expense, when
most people don't know who to blame when their computer is slow.

1: [https://github.com/bwindels/brawl-chat](https://github.com/bwindels/brawl-
chat)

------
hootbootscoot
I would simply say that the OP should reverse the question: "in which cases
can an electron app suffice for a desktop application" and not presume the
death of desktop apps.

It's a very web-dev-centric view to imagine that this model is right for
everything and will eat all software. There are clear performance and
efficiency tradeoffs.

If you KNOW the constituent bits of the software stack of an electron style
app, you will be horrified at what you are doing in the name of being 'normal
cool and popular'.

It would be considered extremely bad engineering if you whiteboarded the
actual layers and proposed it sans the singular justification of "there are
lots of JS devs and this is considered easier than QT which requires a bunch
of picky expensive C++ devs'

More's the pity that the eventual use case is not first priority in such a
decision making process.

"Background communication channel that should be kept open while the users
main productivity software is afforded the computers resources for actual
work" that would suggest that Slack would be better written as a native or
near-native app. Hello, McFly...

------
namelosw
There definitely niches for native apps, but they're just niches. It's like
massive C++ vs others debates in the 90s. Eventually, people only use C++
where it suits the niche, instead of using it for most of the things like it
was in the 90s.

Economically, it's basically 'web first' or at least web by default. Not only
it's cheaper, but also faster to iterate, since major clients' logic could be
unified.

Development wise, most non-desktop developers hate native desktop development.
There are too many quirks in different platforms.

PS: There are so many Electron hates in this thread. Sure, there are a lot of
crappy Electron apps, but they're more likely assembled in like one afternoon
either because it's a personal hobby project tool or their company wanted only
a working software and demanding their developer to release it within one
week. Given the same amount of investment, I believe Electron wouldn't be too
much short than native apps.

VSCode like everybody mentioned is pretty slick. And personally I feel
Discord's Electron app and the React Native app are pretty nice as well.

------
cpach
IMO: To some extent, yes.

Here are some desktop applications I enjoy and have gladly paid for:

Acorn (image editor) / 1Password / Evernote+Skitch / Pingplotter / djay

------
arkanciscan
Just to add a counter-point to the readily expressed opinion here on HN that
the web is terrible and we should all go back to programming Coltran; the only
place for desktop apps is testing new APIs for new technologies which the Web
can adopt once they've stabilized. So if your phone gets some new breathalyzer
sensor or something, and you can't interact with it via WebUSB or WebBT then
yeah, you're gonna have to drop down to the OS runtime to play with that until
the standards bodies finish arguing about what WebBreathalyzer API should look
like. Or more likely, that never happens because it turns out that few people
need a phone with a breathalyzer. The web is the common denominator, the
platform that runs on the most devices supporting their most common features.
That makes it clearly superior for applications which need to reach the
broadest audience. That only grows as more and different platforms emerge. But
there's always going to be something new to play with, and that's fine too.

------
nikofeyn
it's crazy that we've reached the time where this is a question. it just feels
like web browsers are just worse operating systems but that's somehow where
everyone thinks things should be.

i generally hate using web-apps. the usability and performance just isn't
there, and the web was not built for this use case. even now, it's a terrible
experience.

for industrial engineering, scientific, creative jobs and more, almost
everything you use aside from confluence is a desktop application. visual
studio, visual studio code (line is blurred, but it's still a desktop app),
solidworks, opera, other modeling software, xilinx vivado, matlab, visio,
simulink, houdini, touchdesigner, unreal engine, logic, pro tools, studio one,
VSTs, office suite, control applications, perforce visual tools, git gui
clients, custom internal tools, etc.

all the real work gets done in desktop apps and yet people keep saying desktop
apps are a thing of the past.

i truly don't understand what people's end game with web browsers and
applications are.

------
zelly
I'm going to take the contrarian position here and say No, there is no place
for native desktop apps. If a user has enough resources to run a graphical
operating system, then they have enough resources for an extra copy of
Chromium.

The exception to this is something either so simple that it only has one
button (e.g. some file format converter) or so large (e.g. Photoshop,
Bloomberg, AutoCAD, Mathematica, Visual Studio) that it surpasses the
capabilities of the web platform.

Most things like chat, music, or word processing absolutely can and should be
done with Electron or (imo) a WebView.

The reason Slack etc. is slow is not because of Electron but because the
JavaScript is probably very poor, bloated, and not optimized. I used to hate
Electron for being slow but after using it have changed my mind. The
bottleneck is never on the Electron side; it slow because of your code. VS
Code is an Electron app and is snappier than many "native" editors.

~~~
adrianN
Maybe your native editors just suck.

There are many people who have older hardware. For example I write this on a
2009 Macbook. My parents use older hardware still. And we're relatively well-
off in a rich western country. These machines are perfectly fine to use for
almost all tasks, but they're not powerful enough to run ten copies of Chrome.
We might easily be able to afford that newer 500€ laptop, but for many people
that multiple months of income. Not to mention the unnecessary waste the churn
produces.

~~~
liendolucas
And also sometimes there is absolutely no need to buy new hardware! I find
appalling that we need to upgrade our machines just because software gets more
and more resource hungry. My parents as well use old hardware to browse, edit
documents and write emails. Back at I home I still run a 10 year old PC with
Linux and it just keeps running very well... No need to upgrade! I just think
about the golden age of videogames and the software tricks developers came up
with to make them run and the hardware those used to run on. Today basically
you need to constantly upgrade your GPU if you want to play the latest cool
game. Ridiculous.

------
me551ah
Native apps are far superior to Web/Electron apps. Got 60 upvotes on HN before
it was flagged so sharing it as a comment.

[http://ajit.dhiwal.com/2020/02/world-wide-web-is-worst-
possi...](http://ajit.dhiwal.com/2020/02/world-wide-web-is-worst-possible-
user.html?m=1)

------
blackrock
Adobe seems to have achieved the combination of SaaS and Native.

They got data lock in with Photoshop and Lightroom. Admittedly, the free
alternative just doesn’t work as well as Photoshop or Lightroom.

The SaaS is on a monthly or annual subscription. So spending $20/month, if you
only use it for 1 month, is far cheaper than spending $800 outright for a
Photoshop license. And now, Adobe has the potential to reach a global audience
of 7 billion people.

Of course, there is some risk that your code will be pirated, decompiled, and
reassembled, to remove the ET-phone-home feature, but this is only a minor
annoyance. It’s better to get your product pirated, than another competitors
product. That way, the people using the pirated copies, who are likely poorer,
or kids, will learn your program, and eventually pay for a full commercial
license eventually, when they get a job professionally using the product.

------
hootbootscoot
Of course!

I would rather reverse the question: In which situations is it acceptable to
use Electron, for example? Something like Balena Etcher makes sense, but Logic
Audio not so much.

Don't let hype and popularity on HN (not to mention market share of JS as
pertains to the amount of web front-end work vs desktop work) serve as a
surrogate for noting actual performance given a specific application.

Wrap-a-browser approaches and bloaty non-native frameworks are good for
configuration ware, and things that don't need to engage in high amounts of
real time processing saturating the CPU and RAM.

Many applications continue to squeeze required performance out of each
platform. Cross platform approaches can serve just fine if there are zero-cost
abstractions.

Audio/Video/3D/Image production software, for example. CAD, not to mention
developers tools and compilers, just for the tip of the iceberg.

------
phendrenad2
Native applications will always have an edge, because they can do several
things that are difficult or impossible in a browser:

1) Rich key combo support. When running your app inside a browser, many key
combos are reserved by the OS (and they differ by OS), and many are reserved
by the Browser (and they differ by browser). As a result, your app has to
avoid a huge number of key combos, because some OS or browser uses those.

2) Latency. It's not impossible to make a fast web app, but you're already at
a disadvantage, due to the inherent overhead of the browser and JS runtime.
Put it this way: making a user experience that feels slow and sluggish in a
native app requires a lot more mistakes than doing the same thing in a webapp.

3) Filesystem support. It's just better with native. Especially on Windows
where you can fully customize the file-open dialog box with app-specific
business rules and warnings.

4) Hardware. You'll always be at the mercy of the underlying browser's support
for hardware. Need to allow the user to switch between sound devices? This is
easy with a native app, but it may require going to the browser control panel
if you're a webapp.

5) Leaky abstractions. As a user, I want to open an app and do everything
inside of that app. When using a webapp, I may have to fiddle with browser
settings, key combos may break me out of the immersion as I accidentally open
some browser toolbar or help feature, and the browser toolbars and window is
always there to distract me.

6) Updates. With a desktop app, it can show me an alert when it's time to
update, and I can choose to update now, or do so later. With a webapp, the
updates are normally locked to a browser refresh (I need to refresh the page
to get the update, and the update will happen whether I want it or not once I
reload). Sometimes, the app decides it's time to update and just force-reloads
itself (in the case of an app window I've left open for too long - days or so,
while working on something important).

------
ComputerGuru
See, everyone likes to complain about electron but when I did a market study
asking “would you pay for a full-featured native Slack app that was
lightweight and designed with functionality in mind” the answer I got was
mainly “yeah but no.” As best as I can figure, it was mainly feeling they were
entitled to it for free as it’s what Slack _should_ have developed, so they
were not about to pay to correct a mistake they’re “not responsible for” never
mind that they’re the ones paying the price for it.

(I wrote a fully native iMessage client for Windows 10 [0] and enjoyed it
enough to consider building a product around the code, minus the iMessage
component.)

[0]: [https://neosmart.net/blog/2018/imessage-for-
windows/](https://neosmart.net/blog/2018/imessage-for-windows/)

~~~
mintplant
I paid for Ripcord.

[https://cancel.fm/ripcord/](https://cancel.fm/ripcord/)

------
ahmedbaracat
I am constantly annoyed by the web apps, not only because they consume so much
resources, but because of the noticeable UI lag that drives me crazy. For
example, I have been entertaining the idea recently of building a native Todo
app for macOS because of how slow Todoist has become in the past few years.

~~~
nikivi
I'd check [https://www.2doapp.com](https://www.2doapp.com)

It's super fast and featureful

~~~
ahmedbaracat
Thanks for the suggestion. Looks very interesting, but a bit expensive.
Looking to see if there is a trial somewhere...

------
AnonC
It depends on what you’re developing, who the target users are and how much
you need to charge to sustain yourself. It also depends on your skills and how
much time you’re willing to invest in creating a desktop application (doing
one that’s cross platform, that performs well and works like a native app on
each platform would take a significant amount of effort).

Native desktop apps targeted at the average user are better done on macOS,
since that platform has a higher percentage of users who will pay (compared to
the percentage of users who’d just pirate it).

Applications targeted at professional users, corporate users and developers
can get an audience that’s willing to pay on any platform.

If your application is better done as a service, and you’d like better control
on managing versions, a web based SaaS might make sense.

~~~
hermitcrab
>Native desktop apps targeted at the average user are better done on macOS,
since that platform has a higher percentage of users who will pay (compared to
the percentage of users who’d just pirate it).

That was always the standard wisdom. However I have released the same software
on Windows and Mac and seen significantly worse piracy for the Mac version.

------
thr0waw4y5555
I always go for a native app over a web app/electronjs app. Native will most
likely have the familiar idioms of the OS, lower overhead, and take advantage
of platform specific features. I happily pay money for native apps. I
generally don’t pay for blobs of JS in app form.

------
Optimal_Persona
O God, please no! I can't see anything requiring true low-latency real time
performance (like audio production DSP) ever being fast enough on the web
compared to native. Also, when everything went 64 bit in recent years,
developers got really lazy about memory management.

------
flowerlad
As things stand now there is no place for native desktop apps.

You have to give users a reason to prefer native desktop apps. But today,
thanks to Flat UI, most end users can't even tell a native Windows app from an
Electron app. If users don't demand native apps then developers have no reason
to limit their customer base to Windows users (or Mac users).

For users to demand native apps, native apps must have a distinctive look and
feel that is loved by end users. Before Apple switched to Flat UI, Mac OS X
apps did have such a look & feel, and developers were making OS X native apps
even when users could use a Web version.

If Apple or Microsoft dropped the Flat UI stupidity — which is both ugly and
has usability issues — then one day demand for native apps may return.

------
jwr
Definitely, for apps where you can invest the money. Desktop development is
_really_ expensive, even more so if you want to support more than one
operating system.

This means either apps with general mass appeal, or niche apps in specialized
markets, but not small markets either.

Taking a quick look at my computer right now, I have a bunch of specialized
apps that are considered "expensive" by many, and there is NO WAY I would want
to use them as web apps: Ulysses, Camtasia, 2Do, Bear, Fantastical.

The other side of that coin, however, is that people do not appreciate how
expensive desktop development is. For my SaaS, I would love to offer desktop
apps (as in, not Electron apps), but the cost is prohibitive and this will
likely never happen.

------
codr7
I've been going back and forth on this for quite some time. I find that I
often end up compromising when choosing an implementation language based on
availability of the kind of libraries/UI I want.

What I would really like is to completely separate application logic and UI so
I'm free to choose whatever language fits best and potentially add several UIs
on top of the same core without being forced to write it in C.

I recently started playing around with the idea of implementing application
logic as a separate server that reads/writes a simple line based protocol
from/to stdin/out. Simple enough to be tested from a shell, and easy to map to
JSON for a web server or drive from a GUI.

------
red_admiral
On Office 365 (desktop version), sometimes when you click a dropdown like the
"different kinds of bullet lists" the whole application freezes for a couple
of seconds while it builds the menu content or something. This didn't happen
with earlier versions, if memory serves me right. I'm not sure if this is web
tech or some other kind of new framework under the hood, but it makes me sad
that with the speeds and cores we have on modern processors old-fashioned
things like word processing have got slower than they used to be.

Native Applications in the platform's toolkit (not some cross-platform
abstraction on top) will always squeeze a little bit more performance and
usability out of the corners.

------
Avi-D-coder
I wish I was not writing this, but no.

Outside of niche use cases you get two much with electron. Computers are so
dam fast most users just don't care and those of us that do care use Linux
anyway. If your app also runs nearly identically in a browser not just
electron, on boring users is so much easier. I won't install an app just to
try it, but I will use a website and reluctantly upgrade to electron.

A sand-boxed stripped down electron replacement as a system library, ala Deno
for UI will replace electron in the next few years. Web-Native frameworks
targeting WASM, WebGPU for responsive components and Dom for everything else
will replace JavaScript, but the web will win.

------
Schnitz
I will use a native desktop app over the other alternatives every time given
the chance.

------
elorant
For me the simplest example is e-mail. I need an e-mail client on my PC where
I can browse all my e-mails even when offline. Nothing that runs inside the
browser could match the speed and efficiency of a native app.

------
ironmagma
I crave native apps, especially ones that get out of the way. Web apps take up
screen real estate, and are cumbersome if they involve login details or if you
want to access the API (if one even exists). There is definitely a place for
more native apps, and more creative designs as well. Creatively, I am always
seeking inspiration, and web apps are just the same design patterns repeated
everywhere. A fresh app like TweetBot or OmniFocus is valuable for its
creativity and sleekness, it's just something you could never find in a web
application.

------
kup0
I prefer native apps ALWAYS when possible as a user. I get that it isn't the
direction the world is moving, and that's unfortunate.

With all the computer resources in the world (tons of RAM, NVME drives, etc)
it's still easy to tell the difference between native and anything else. It's
amazing with these resources that apps can just be ridiculously slow-feeling.
It's just painfully obvious.

Just another hell we have to accept living in. Overly dramatic? Sure, but I
wanted to express how much disgust I feel for non-native apps.

------
gwbas1c
The big advantage of web applications is that they don't have an installer,
and they don't need to deal with pushing updates.

Many comments here explain the advantages of full desktop applications. (And
there are many.)

The thing to always keep in mind is, does your application justify an
installer? There's so many tiny utilities that run in a browser that I can
find with Google. These are utilities that I probably use once a year and
don't care to install.

But if I use the application heavily, I want a desktop application even if
it's just an application specific browser.

------
teddyc
I like a desktop app for uploading / syncing large files or directories to the
cloud.

I'm sure there's a good web implementation out there for the Dropbox-style
sync thing, I just haven't seen it yet.

------
oscar_franco13
Yes! at some point I got tired of web stuff, I try to use small native apps
for the day to day stuff, cramming everything into the browser completely
kills the benefits of the desktop environment.

I created a small macOS native app, it is a menu bar app for monitoring CI
pipelines [https://tempomat.dev](https://tempomat.dev), something like this is
not possible on the web because everything is running on the same browser but
native features are so much better

------
nakodari
I am running a native desktop app Jumpshare
([https://jumpshare.com](https://jumpshare.com)), a remote working
communication tool that helps you share your work and ideas through instantly
shareable links. Basically, it combines video recording, screenshot capture,
and file sharing - all in one app. This is not something you can build using a
modern browser or Electron because it does not have tight integration with the
operating systems.

------
liendolucas
Of course there's still place for native applications: movie players (VLC),
audio players (Winamp), animation software (like Blender) come now to my mind,
and if you look around you find more and more. The web has shifted long time
ago its initial purpose: displaying and sharing documents to be a common
platform to run full fledged "desktop" applications in the browser. The
problem is what you want to develop and the intended audience of your
application.

------
prepend
I run a native desktop app called Moneydance. Syncs files, encrypted, to
dropbox, and everything runs locally on whatever machine runs Moneydance.

I use this because I don’t like the idea of financial account info being
stored by a third party has has no liability for breach. And also because I
have over 10 years of transactions in the ledger and running this remote can
take a long time. I’m not even sure if there are any services that store for
10 years and let you do text searches.

------
oblib
I've been working on a sort of hybrid of the two by configuring a web app to
use CouchDB installed on the user's desktop pc to store the user's data.

The app code is delivered by a web server and runs entirely in the user's
browser and with service workers configured it runs offline too.

Personally, I think it would be cool to have a sort of secure "runtime engine"
on the client side that could manage permissions to system functions for
client side web apps.

------
allie1
Yes, I detest Electron and how its adoption has made apps that would otherwise
be great, clunky (looking at you Microsoft (vs code) :/ ). I love Sublime Text
by comparison.

I'd pay good money for a native Evernote alternative.

I think no cross-platform solution will ever compare to native, and in the
long run, native will prevail.

Electron might be good for quick development and deployment, but that's for
the developer's benefit, not the consumer's.

------
lern_too_spel
Barely ever. If I have to install an app, even (especially) an Electron app,
you've already lost me unless you provide something I can't get anywhere else.

------
jonny383
Sure there is, but the place isn't with small - medium business. Only large
corporations that can afford to develop native cross-platform applications
will do so. Hence why there's an influx of Electron applications, etc.

I think you'll also find that the typical non-technical users simply don't
care whether or not Electron is powering a piece of software. They just want
something that looks modern and works "well enough".

------
thayne
Given the choice between a native desktop app available on my OS (linux) and
webapp of similar quality, I'll almost always choose the desktop app.

------
gherkinnn
OS extensions like command line tools, Alfred or Little Snitch will remain
native by necessity.

As will applications like Final Cut Pro and Logic Pro. As I see it, the web
platform is neither adequately performant, nor are its timing mechanisms
accurate enough.

So no, native is sliding. I argue that >95% of users are happy with browsers
and/or electron apps.

Either that, or those peeps move over to iPads. Which by design forces native
or psuedo-native apps.

------
LockAndLol
Sure, there's a place but it's been my experience that native apps have very
complicated frameworks using complicated (and unsafe) languages. Qt and GTK
both use C++ with other languages as am afterthought.

Web apps have an incredibly flat learning curve with an equivalent entry
barrier. If the same were made for native apps, they'd be more popular.

Web apps aren't displacing things, they're filling a void.

------
julosflb
One trivial benefit of web app worth to be considered is that they do not
require installation. When targeting business users, this can big a big plus
as it turns out that installing/running unknown software in corporate
environment is usually not permitted. Most users will give up testing if it
requires getting IT to install the software.

------
lexx
As a user, I really miss native apps. The difference in UI responsiveness is
huge. Not to mention battery and memory usage.

As a developer I understand why the native app road can become a more
expensive solution, especially for startups.

But, I have to express that I am really tired of glitchy super heavy
javascript apps, online, mobile and desktop. I would choose old clanky but
lightweight UIs everyday.

------
paulmooreparks
I'm mixing a song in Pro Tools right now, and earlier I edited a video in
VideoPad. I can't fathom doing either on a web app.

------
unnouinceput
Good luck using peripherals that requires physical access to them. The day web
browsers will have full physical access (well, they technically do but you
guys understand what I am saying, right?) is the day hackers will transform
internet into that dystopian world from the old movie with Keanu Reevs -
Johnny Mnemonic (the short novel is even better btw).

------
dusted
I think there is, and as the "desktop dies" I think we will be left with a
higher percentage of users expecting high performance native apps, when
"normal people" migrate to tablets and smartphones for all of their tasks. I
see the possibility of a resurgence of native apps based on that. or maybe it
is just wishful thinking.

------
emddudley
Yes, there is still a place for native apps.

Anything that communicates with devices using serial, UDP, or custom layer 2
protocols.

Also anything which needs to be used in a lab environments with networks that
can't access the web or corporate network.

Also anything that needs to run in a manufacturing environment, where precise
configuration management, predictability, and reliability are crucial.

------
jasonhansel
Native apps are better than web apps in terms of UX, but few companies have
the budget to maintain both a native app and a web app (unless they can share
code, as with Electron). Since most companies need a web app anyways, they
have little incentive to spend the time/resources needed to develop and
maintain a separate native desktop app.

------
srikz
Any discussion about desktop GUI toolkits should be preceeded by this article:
[http://blog.johnnovak.net/2016/05/29/cross-platform-gui-
trai...](http://blog.johnnovak.net/2016/05/29/cross-platform-gui-
trainwreck-2016-edition/)

------
thewebcount
I go out of my way to avoid web apps. They're uniformly awful. They also have
a tendency to require an internet connection, even when they don't need to.
Some can use local storage, but the other problems with web apps don't make up
for it. I don't want an OS running on my OS. I want to just use my apps.

------
begriffs
Anybody here ever create graphical apps with Motif? Care to share your
experience?

Motif appears to have an old and stable API. Its visual style looks grey and
blocky, but has a rich widget toolkit.

[https://www.oreilly.com/openbook/motif/](https://www.oreilly.com/openbook/motif/)

------
JKThanassi
Look at the difference between things and todoist on macos. Things is much
snappier and better looking while simultaneously using fewer resources.
Todoist is an electron app whereas things is native. It really does make a
difference and I wish there were more truly native apps out there.

------
mantas
Place? Absolutely. Developers will to provide quality apps and customers will
to pay for them? Not so much...

------
crazygringo
After using Photopea (web) as a virtually full replacement for Photoshop
(desktop), I'm starting to think that these days, all _interfaces and business
logic_ should be web-first. JavaScript is fast, other languages can compile to
it or WebAssembly, and HTML+CSS is a lingua franca. Obviously PWA's are
required, designed to run offline.

Where brute-force performance is a #1 concern I think it diverges. For things
like Photoshop filters or rendering, WebAssembly _may_ still be fine (it
depends). But for real-time processing that needs timing guarantees or more
direct access to hardware (games, DSP, etc.) the code has to be native running
in dedicated threads. Still, it would be nice if those operated essentially as
native browser plug-ins that still interfaced with a browser environment,
rather than a totally separate executable.

I'm seriously ready to let my web browser just be the GUI to my operating
system. I want my file manager and terminal and system preferences just to be
tabs next to my Gmail and Docs.

~~~
heyoni
Speed in relative terms means that JavaScript in the browser is not fast. The
language runs on top of just about as many abstraction layers as possible and
I do not envy this world you describe. I wish we’d move away from it.

~~~
crazygringo
But it's fast _enough_. JIT compilation means algorithms run decently fast,
and when it deals with the DOM it's fast _enough_ for everyday interface
tasks.

Nobody's saying it's elegant. But it's cross-platform and it's a standard that
lots of people know. Wishing we move away from it seems like a lost battle at
this point -- at least unless we somehow invent a brand-new computing paradigm
that replaces browsers, the way browsers have replaced apps in many cases. But
I can't even imagine what that might ever be.

~~~
heyoni
It’s not though. Not even close. And I know this partially a matter of taste
but I have one of the fastest computers you can buy and I can’t even
participate in text chats without input lag and delays in interaction. It’s
not a good user experience for me at least but that’s ok, we’ll keep stacking
more cpu power until it’s all in the cloud anyways.

~~~
crazygringo
That just sounds like server latency to me or some kind of bad programming
like relying on polling.

Obviously if you build a chat client in the browser and communicate between
windows then it's instantaneous. Faster than human perception.

Certainly doesn't seem to be a CPU issue to me. I mean, we run _videochat_ in
the browser which works fine. Obviously text chat can be instant.

~~~
heyoni
I’m talking about the native slack app. I used to use the irc gateway and now
go back and forth between desktop and unofficial gateways. I use keyboard
shortcuts to navigate between chat windows and nothing about it is
instantaneous...even when there’s nothing but text. Same thing applies to
discord, and less so with WhatsApp and signal. Messages on the other hand is
silky smooth, and terminal irc couldn’t get any faster.

------
mrkramer
Wasn't Steve Jobs' idea to have Web Apps for Iphone but Iphone team talked him
into native apps for various reasons such as performance and security and he
finally gave in.

I would assume the same for desktop versus web apps but as time goes on I
think web apps will prevail.

~~~
vb6sp6
The webapps thing was a stall tactic because the infra wasn't ready before
release.

The original iPhone didn't even have a call log.

------
graynk
I've been moaning about it for years now. I really hate the experience that
web-apps provide. Electron is not much better in that regard. I want my apps
to be native, I'm willing to pay for it, please stop moving everything to the
browser

------
thrower123
Fuck no, everything should not be a webapp. Most things that are webapps
should not be, it's just that nobody knows how to do anything else.

It's really about time for the pendulum to start swinging back, as processors
aren't getting much faster anymore.

------
zmix
I prefer desktop apps and I pay license fees for those, which I use as
standard for the task or daily. Nothing beats them. I especially like it if
they are made scriptable, preferably by using a scripting host provided by the
OS (if available).

------
razster
For the company I work for, our software is preferred offline to secure
sensitive data. We, and they, cannot afford data leaks like online “cloud”
services.

We’re a very unique niche software that could be design online only, some
have, but they slowly fail.

------
mister_hn
Until the day the Professionals will use more mobile devices than desktop
ones, the desktop native apps will simply rock.

Think to Photographers (Photoshop?), Designers (3DS Max, Blender), Gamers
(Steam & co), Administrators (VirtualBox)

------
kgin
What a crazy world where for desktop/laptops, we're not sure we even need
native apps even for complex use cases.

But for mobile, there is an almost religious insistence that even text-based
CRUD apps need to be compiled binaries.

------
egecavusoglu
I believe desktop apps are relevant when they are for apps that are frequently
used and need high performance that the browser can not necessarily provide.
Also I am more focused on the task when using desktop apps.

------
htk
I would say it depends on complexity. Either algorithmic or UI complexity. Web
apps just aren’t as efficient as Desktop apps, and at this moment this is
still relevant in various cases, probably in many less in the future.

------
dmitrygr
Yes! There is a place! My machine! Please keep writing them! Offline
experiences that launch in ten milliseconds and use kilobytes (not gigabytes)
of RAM, are better than any website or electron "app"!

------
qwerty456127
Absolutely! Clean classic desktop apps (still common on KDE and Mac) provide
the best UX so far - they are easy (intuitive) to use, they look tidy and they
work fast. I choose such whenever it's available.

------
stephc_int13
A quite well-known rant from Casey Muratori about a very similar issue:

[https://www.youtube.com/watch?v=kZRE7HIO3vk](https://www.youtube.com/watch?v=kZRE7HIO3vk)

(For those who never saw it)

------
mellosouls
Whatever contemporary technical arguments for and against are, it's worth
bearing in mind that people were asking the exact same question, with similar
arguments at least 10 years ago (and probably more), so I would say:

Yes.

------
intrepidhero
The lines between the two have been slowly blurring for some time now. My
crystal ball says that will continue as the need for cross platform support,
especially desktop versus mobile, gets bigger. I think we'll see more and more
emphasis on 3rd party VM type frameworks, like JVM, unity, and electron.
However with Moore's law reaching an asymptote I believe that writing for
performance will also become more and more important. I think these forces
will result in a high demand for the skills needed to improve performance on
all types of apps.

What I'm hoping for is a pendulum reaction to the recent trends of UX design,
where we see a renaissance in really solid interfaces that focus on discovery
and speed. But I'm not seeing signs of that yet.

------
keyle
Well yeah. For example I run an app that monitors my internet connection all
day long. How do you run that in the browser?

Have you tried compressing videos professionally or producing 3D content
without a native app?

------
vncecartersknee
Pretty much all the jobs I've had as a software engineer have been working on
desktop apps.

There's tonnes of random enterprise applications that look like they're
straight out of 2005 out there still.

~~~
coronadisaster
Why fix what is not broke?

------
jacobcritch
Native apps are totally necessary. Why abstract everything to the browser?

------
pjmlp
Life sciences laboratory monitoring, trading dashboards, factory automation
panels, car infotainment systems, graphics, audio and video processing tooling
are all largely desktop applications.

------
sys_64738
I want native apps not webpages that run in their own 'app'. If I want a web
app then I'll run it in a web browser. Things like Electron apps are something
I simply refuse to run.

------
uttamk
The key advantage for webapps is distribution. I can create a new version and
almost instantly distribute to all my users. Therefore webapps can change much
faster than native ones

------
squarefoot
Web last, badly, and only when needed. Having tons of resources at disposal
shouldn't be an excuse to add layers of unnecessary stuff where native code
always perform better.

------
benibela
I use Lazarus for that

In theory it is great, you write the app once and then it runs on Windows,
Linux, Mac, using a wrapper around each native GUI.

Unfortunately it is written in Pascal, so the community is tiny

------
johnchristopher
There's still a place. But not for reinventing wheels and half bake a new take
on a "solved" problem (mail reader, music player, personal task manager,
etc.).

------
binky
Productivity and true isolation, even somethingas as minor as window
size/placement... wouldn't replace VS Code, Slack or Spotify clients, they
simply do more.

------
Osiris
I sell a native Windows program for monitoring battery life and health. It
wouldn't be possible to build as an electron app, at least the battery
monitoring part.

------
curyous
Native desktop apps are simply better. Cross-platform solutions promote
mediocrity. Someone has to make good software otherwise our civilisation will
fall.

------
znpy
Native desktop apps already are one of those fields that very few people can
master. Such niche will probably become super lucrative in the upcoming years.

~~~
madhadron
They're not that hard. They're just unfamiliar to Unix command line users. A
lot of people managed to write desktop apps in Delphi, Cocoa, and Win32 for
many years.

------
tinus_hn
Even though people have been forced into accepting memory bloated turds like
Electron apps, they can only be cheaper, not better than native apps.

------
anta40
"is there still a place for native desktop applications?"

What if your program needs to directly access some kind of hardware, say EDC
machine?

------
room505
CAD and BIM

~~~
preommr
webgl and wasm?

Edit: I presumed that the context of the discussion was apps in a general
sense. Obviously not every application is going to be on the web and there are
a lot of niche software that will never make the switch. I was thinking more
qucad or sketch 3d for woodworkers to plan their desks, not solidworks and all
its plugins to handle complex fluid simulation in mission critical areas.

~~~
kroltan
Still wishful thinking at this point.

~~~
TomMarius
Do you know OnShape?

------
m4r35n357
Web last, please!

------
goatherders
I use a number of native desktop apps. For email. For music. For projects. For
saving files. For instant messaging.

------
jtwigg
God I hope not. Web apps have come a long way. Some SPAs I've used feel native
and provide just as good as an experience as any desktop app. Having said
that, I feel that (IMO) a well designed desktop app is just more pleasant to
use than any web site. I've written software for both scenarios and I enjoy
developing native desktop apps over websites so I am probably biased in that
respect.

------
suyash
Use JavaFX to build cross platform desktop apps, lot's of enterprise client
apps are written in it.

------
thosakwe
HNers don't seem to get it, but the average, non tech-savvy really doesn't
care whether an app is native or not. It just doesn't really matter, unless of
course you're doing something performance-intensive.

But most people are probably not saying "ugh, Slack is made with Electron, I
should completely avoid it."

------
dirtylowprofile
I mean look at Telegram. I wonder why big companies can’t follow with all them
dollars.

------
nikanj
Yes. If nothing else, the web browser is a native desktop application.

------
throw7
Well, I don't have a epic games account. Does that count?

------
rptr-web
Webassembly is slowly taking over and i believe native apps days are numbered.

If legacy apps like AutoCAD ported to WASM can give similar performances and
experience as web app this is just inevitable now.

------
zzo38computer
I would prefer command-line programs, actually.

------
peignoir
Anything relying on DLTs has to be on desktop

------
lucis
You might wanna check Oni2 [1]

[1] [https://github.com/onivim/oni2](https://github.com/onivim/oni2)

------
dzonga
as a Linux desktop user. I believe, having web applications is preferable to
desktop ones. however, the problem is talent is lacking around the industry to
make performant web apps. Not every company can produce a high quality
products such as Figma. things on web are not tied to walled gardens or any
other stupid shit. easily accessible.

------
webscalist
Sure, if you want to drain battery

------
mike50
Speed of light is still fixed.

------
soapdog
In my opinion, I suspect that many people shipping electron-based apps would
gladly switch to a native toolkit if there was a dead easy way to develop
cross-platform GUIs.

In the 90s and early 00s, there were many easy language products like Delphi,
VB, and others who were much easier to use than C++ and friends. Cross-
platform could be done with REBOL, REALBasic (aka Xojo), Runtime Revolution
(aka LiveCode) and many other languages. Users didn't expected fancy flat
animated user interfaces made of 100% custom controls, people were fine with
normal native standard stuff as long as the app worked.

Now, there is no easy way to build cross-platform apps that is easier than
electron. Languages like modern C++ and Rust are extremely powerful but they
require more experienced developer to be used effectively. GUI toolkits like
Qt and wx, are good but a ton of UX professionals now are trained to ship UIs
in tools like figma, skewing all the native controls and creating beautiful
masterpieces that are easier to do with HTML/CSS than implement with a native
toolkit.

Native apps got harder to do not because we don't have access to the tech we
had, but because of added friction. It is like death by a thousand paper cuts.
You make the professionals designing the UX/UI create interfaces that are
harder to reproduce with native technology, then you select a GUI toolkit such
as Qt/wx and try to reimplement that using whatever language is best. It takes
longer than developing an electron app, requires more expensive developers.
Don't get me wrong, it will be a better product, but it will take longer, be
more expensive, and will need to be done with more care. And after the app is
done, there is the need to deal with all the sandboxes and crazy stuff that
Apple requires these days if you're shipping a native mac app. Many electron
apps sidestep a lot of this by simply being thin clients for some SaaS company
and doing the hard stuff on a server (which also opens an opportunity for
mining the data for our capitalists overlords).

The barrier for entry for developing an electron app is so low. JS is an easy
language to start. There are so many ready made UI kits. You can have a small
app running before a new developer can understand how the new pointer stuff
work on modern C++.

All that text is to say that I think we need easier languages and toolkits
that target native experiences. Something like Lazarus, LiveCode, are all
steps in the right direction for me.

------
me551ah
The whole idea of web first has actually made things worse. Let's compare web
apps to native desktop apps, shall we?

Memory Usage

A few years ago while trying to figure out why I was running out of RAM, I
stumbled upon chrome’s task manager. Gmail was using up 700MB of RAM and all I
had open was the Inbox. No fancy search box or Compose, the Inbox was taking
up 700MB of RAM to display lines of text in a Tabular format. I’ve been a
heavy user of Email clients and if you pick any of the native clients
(Thunderbird, Outlook, Apple Mail) and open a bunch of searches and compose
windows the memory usage will still stay below 100MB.

I used mIRC a few decades ago to connect to multiple chat servers, run my own
bots, serve files over DCC and run scripts all while staying under 20MB of
Ram. 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. And the most common solution to running out of
memory is to close chrome windows.

Battery/CPU Usage

DOM is slow. Updating layout and repainting is even slow. Javascript being a
dynamic language is slow. Web apps are anything but simple these days and
since they have to work under the limitations of all the slow components, the
CPU ends up making up for it. Chrome is almost always present in my Macbook’s
‘Using significant energy’ tab. On the other hand, I rarely if ever see native
apps in the battery bar unless I’m doing something which should actually
consume a lot of CPU cycles like running multiple synths in Ableton or
Compiling. When apps are built for mobile, battery usage is a major area to
optimize on. But nobody even gives it a thought for web apps

60 FPS

Mobile apps run on 60fps, Native desktop apps run at 60fps, Games run ( or at
least are designed to) run at 60fps. Instagram on chrome starts at 2-3 fps and
usually hovers around 30fps. My laptop which is supposed to be more powerful
than my mobile phone is only able to churn out half the frame rate even though
they are both running at the same resolution! Web apps are not buttery smooth
and can be jerky at times. Sure somebody can work really hard and optimize a
website to run at 60fps at all times, but it needs a lot of effort. Mobile
apps run at 60fps out of the box without much effort. Mobile and native apps
use the GPU a lot more efficiently. Since they have a lot more information
about which controls are being used, they can recycle items a lot better and
do a much better job at hardware acceleration via the GPU. Not to mention that
you have access to raw graphics APIs in case you want to push UI performance
even further.

Development Environment You can build desktop apps in a plethora of languages
and even for mobile apps you have many cross-platform frameworks. But building
for the web(and electron) forces you to HTML/Javascript(and derivates).
Javascript is a dynamic prototypical language that was not designed for the
scale of apps that are being built in it today. It has no type safety, memory
leaks are common and it’s slow due to its dynamic nature. While there have
been many efforts to improve performance like V8s JIT, it still lags behind a
lot of major languages. WASM seems promising, but it’s still has a long way to
go. 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. You can store data, run complex relational
queries and do more with so less. But it is not available on the most widely
used platform on the planet, the browser.

With the rise of electron apps, big and bulky web apps have started making
their way onto the Desktop. There are some who are even trying to get the same
apps on mobile via PWAs. While the web has the advantage of easy
accessibility, IMO we have sacrificed too much in terms of user experience for
that one convenience. If you built an app with the same UI and functionality
in a native language and as a web app, the native app will run circles around
it.

------
signaru
Modern browsers these days are powerful things... just a curiousity, are there
non native browsers?

~~~
nodelessness
What's a non-native browser?

~~~
mrkramer
Any browser that is not running on a host machine then for example on Virtual
Machine.

------
kokizzu
this just like asking: do you prefer to use native/high performance
applications? yes do you like developing native application? no if the
performance and memory usage of web app already equal to native desktop app,
which do you prefer to use? web

XD

~~~
yrio
You also don't like developing web frontends, you only like developing
backends & games :p

------
tuananh
always prefer native desktop apps if there's choice.

------
freepor
You need a desktop app when 1) you’re spending a ton of time in the app or 2)
you need every ounce of performance and feature set that you can obtain and 3)
you’re willing to pay for it.

If you’re not building something like this, don’t build for desktop.

------
gdulli
Not having a real native desktop player is why I won't subscribe to Spotify.
When I'm going to use something more than lightly, I hate using applications
that feel like web tech. But I realize I'm in the minority.

~~~
zacharycohn
_Reads comment. Cocks head, curiously. Closes eyes, listens to the music
coming from his computer. Opens eyes, alt-tabs to the Spotify app. Closes all
web browsers. Music continues, uninterrupted except by ads. Shrugs, goes on
with his day._

~~~
CORBLIMEY-19
Spotify on the desktop is just a big Chromium Embedded Framework frame, thats
what makes it not-native for the purposes of this discussion

------
osrec
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". 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 would
feel even more obsolete.

I know your question was only about 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.

------
creativecupcak3
I will try my best to be nice about this. But what the HECK are you talking
about? Yes, of course there is. There will always be.

Electron(or whatever web-based nonsense somebody comes up with six months from
now):we've optimized your insane garbage collectors. We've optimized your GPU
insane modules. We've optimized data structures to get a 10X performance
increase. We've cut down memory usage by half, which still rounds down to AT
LEAST 100MB in most cases. Look at me now...

Desktop/Native:Good for you! But did you know my code runs on bare metal? The
only thing stopping it is cache misses and dirty TLB entries. Sometimes I can
use registers, but there's just a few of them. And, well, stupid RAM sometimes
takes over 100 nanoseconds.

Web:What in the world is cache? TLB? Are you on something right now? What is a
nanosecond?????

 _Web cannot perceive what a nanosecond is_

Native:There, there. You'll figure it out one day.

I don't want to come off as snarky, but this feels like a dumb question. And
yes, I know, from a "business" perspective writing the code "once" and have
run everywhere makes more sense. But let's be real, one of the main reasons a
lot of these tech companies like Discord/Slack is jumping on the Electron
wagon is money. It's cheaper to have one team of developers, than 3 for each
platform. But even that argument feels a little weird to me when stuff like Qt
that is 100X more mature than Electron will ever be exists. And before anyone
asks, as long as you open source your app, Qt is completely free.

I do think that in SOME cases an Electron app MIGHT make sense. But cluttering
native platforms with all this bloat is like riding a horse to work on your 40
mile commute instead of your Honda. Even that's a horrible analogy because
your Honda is terrible for the Earth. But hopefully you get my point.

This lack of concern for computational resources by us programmers is utterly
discouraging. As has been mentioned before in this thread, people that do
ACTUAL work on computers will not take the bloated nonsense. Go ask the
struggling artist if they prefer to use Krita or the new "modern" app that
takes 600MB of RAM and the entire system gets bugged down to the point where
they can't do research on their browser while drawing because Windows10/macOS
plus the "modern" app takes 90% of their RAM because they have a 4GB/6GB
computer.

Well shit, I guess I need a 1500 dollar computer to just draw a few sketches.
I already have crippling debt, what's some more debt under my belt gonna do?

------
user_50123890
Don't care, i'll take a good web app over a shitty native app any day.

Since native apps take much longer to develop and the UI toolkits are stuck in
the 90s, it's pretty much given nowadays that new ones are shitty compared to
the equivalent web one.

~~~
kleiba
Please take a look at actual screenshots from the 90's to quickly disprove
your assessment.

The only other argument you mention is that native apps take much longer to
develop, and that from that somehow follow that they are "shitty". I'm not
even convinced the premise is correct, but I certainly don't see why longer
development times would imply worse outcomes...

Intuitively, I would assume the opposite: something that is put together all
too quickly should have a higher potential for being half-baked.

I'm not criticizing your preference, I just don't buy the arguments.

------
manquer
Not anymore, the security model for native applications is broken, OS does not
sandbox applications as effectively as browsers do. Pre Web 2.0 you constantly
had all sorts of installed in your system because of installers just doing as
they pleased, Applications like Adobe CC abuse the root rights have critical
security flaws because of this, run many system services, mess up registry,
Oracle put adware on the JRE installers. Large and small companies constantly
abused this. 5-6 months you would reinstall your OS just to get a clean base,
the performance boost on a fresh install was always strange experience, you
felt happy on the boost but you also sad will not last even few weeks.

While there are high performance and graphics heavy tools and niche products
that still require native apps , with tech like WebGL , WASM , WebAssembly
this limitation is also going away. Unless your application falls into this
category where the gap between Browsers and native is still very big, do your
users a favour and build a non native application.

