Is there still a place for native desktop apps?

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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)

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.

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

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'.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

No internet? No web-app.

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

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.

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.

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/

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

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, app link: https://apps.apple.com/app/apple-store/id1456226992?pt=11998...

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

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

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).

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.

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.

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.

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 ` 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

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

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

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)

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.

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

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!

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

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

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.

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.

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.

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.

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

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.

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/

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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, something like this is not possible on the web because everything is running on the same browser but native features are so much better

I am running a native desktop app Jumpshare (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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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/

Any discussion about desktop GUI toolkits should be preceeded by this article: http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trai...

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

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.

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.

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.

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.

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

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).

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.

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)

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.

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.

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.

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.

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"!

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

https://www.youtube.com/watch?v=kZRE7HIO3vk

(For those who never saw it)

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.

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.

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

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?

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.

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.

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

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

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.

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

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.).

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.

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.

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

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.

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

CAD and BIM

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

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

Web last, please!

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

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.

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

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."

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

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

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

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.

I would prefer command-line programs, actually.

Anything relying on DLTs has to be on desktop

You might wanna check Oni2 [1]

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

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.

Sure, if you want to drain battery

Speed of light is still fixed.

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.

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.

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

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

always prefer native desktop apps if there's choice.

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.

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.

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".

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.

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.

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?

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.

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.

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.