Hacker News new | ask | show | jobs
by judah 105 days ago
Increasingly, there just aren't enough incentives to write native apps.

This isn't a criticism of the article, but rather a tangential observation about why so many people turn to the web instead of using native toolkits to build apps, and why so many of native toolkits feel uninspired and lacking any real innovation.

If I choose to build an app using web tech, I get:

- Universal distribution

- No download and install process

- No "please wait while we update this"

- Users can easily share my app

- Users can link to individual pages within my app

- Users get autofill for forms and passwords and credit cards

- Users can block ads

- Users can scale and zoom my content

- Users can find text on any page in my app

- No "SmartScan couldn't verify if this app is safe" because it wasn't signed with a cert.

- A clearer security model: web apps prompt the user for access to e.g. microphone, camera, or secure disk locations. Native apps can kinda do whatever they want.

Why would I give up all those things to write a native app? A knee-jerk answer is often "performance", but honestly, most web apps load faster than their native counterparts these days.

Another common answer is app store distribution, but web apps can now be published to the major app stores without Electron or other frameworks. Google Play and Microsoft Store both support PWAs, and iOS App Store supports web apps via web view.

There are some scenarios where a native app is warranted. For example, hooking into some native component or OS API; e.g. HealthKit on iOS. But for many apps, the web is good enough.

9 comments

Mourning the lost art of native app is HN's ritual routine. In the meanwhile VSCode has become the most used editor by developers and it's not even close.

I think a lot of hatred toward web apps actually comes from the hatred toward cloud-first design. Notion feels sluggish compared to Obsidian, but is it really due to electron? Or the fact that one is cloud-first while the other is local-first?

Edit: well I just looked it up and it seems that Obsidian is electron-based too.

Yeah. You cannot achieve native performance with web apps, but most tasks are simple enough that wasm is plenty fast. If you generate a frame in 7ms or 1ms, the user can't tell the difference.

I think cloud-first design is natural because webapps have nowhere good to store state. On Safari, which is the only browser that matters for many web developers, everything can be deleted at any time. So if you don't want to have a horrible user experience, you have to force your users to make an account and sync their stuff to the cloud. Then, the most natural thing to do is to just have the user's frontend update when the backend updates (think old-school fully-SSR'd apps). You can do much better than that with optimistic updates but it adds a lot of complexity. The gold standard is to go fully local-first, but to really do that right requires CRDTs in most cases, which are their own rabbit hole. (That's the approach I take in my apps because i'm a perfectionist, but I get why most people wouldn't think it's worth it)

With the files API, apps could actually replicate the microsoft word experience of drafting a file and saving it to your desktop and praying that your hard drive doesn't fail, but despite offering great benefits in terms of self-custody of data it was never a great user experience for most people.

> With the files API, apps could actually replicate the microsoft word experience of drafting a file and saving it to your desktop and praying that your hard drive doesn't fail,

Even withou the files API, with local storage, web apps can (and some—mostly extremely casual games that are free—do!) duplicate that experience with the extra risk of your data being lost because your disk became too full or some other event causing the local storage to be cleared.

I once ran out of disk space while Chrome was running and, despite me clearing the space again shortly after, the damage was already done and Chrome had already decided to wipe all my local storage and cookies. It didn't keep it in memory to save again once there was space, it just deleted it all permanently.
> If you generate a frame in 7ms or 1ms, the user can't tell the difference.

But muh 0.00001W of energy!

> In the meanwhile VSCode has become the most used editor by developers and it's not even close

Correct me if I’m wrong but isn’t VSCode an Electron app? ie a webapp shipped together with a stripped down browser

I know that GitHub Codespaces open as a full VSCode editor in my browser so I always assumed it was the same code.

I’ll never understand “stripped down browser” like it’s some curse. Any managed language brings its own runtime. C# brings CLR runtime, Java brings JVM, Go brings its own runtime.
I’m not saying it’s a curse, I’m saying it’s a webapp. Because the person I’m replying to used it as an example of something you can only build as a native app.
> Mourning the lost art of native app is HN's ritual routine. In the meanwhile VSCode has become the most used editor by developers and it's not even close.

McDonald's is probably most popular... "food serving place" in the world.

Both Notion and Obsidian are sluggish compared to Minimal.
I tried a web search for "Minimal text editor" and Minimal vs Obsidian" and couldn't find any results that seemed to be an obsidian or notion equivalent.
I’ve also never heard about minimal, while I’ve heard about Notion and Obsidian.
> No download and install process

Plenty of Electron apps expect you to do this anyway. "Apps using web tech" aren't all web sites.

> No "please wait while we update this"

Not everyone has a fast web connection.

On the flip side, plenty of programs have no reason to use a web connection at all once they're downloaded and installed.

> Users can link to individual pages within my app... Users can find text on any page in my app

How many apps out there really have "pages"?

> Users get autofill for forms and passwords and credit cards

Why does my program need this information?

> Users can block ads

Why would my program present ads?

> No "SmartScan couldn't verify if this app is safe" because it wasn't signed with a cert.

Is that supposed to be a plus? Consider the user's side, too. Also, consider that things like Google Safe Browsing exist.

> A knee-jerk answer is often "performance", but honestly, most web apps load faster than their native counterparts these days.

Care to give an example?

(It also generally comes across like you just take for granted that your users will be on mobile.)

I'm convinced that the real problem here is that people preferring websites only know how to make websites and won't learn anything new. The rest is just to frame it as a rational technical decision.
> How many apps out there really have "pages"?

A lot of them. Enough for me to wish I could have OS bookmarks for specific app screens.

> Why does my program need this information?

Because I as a user don’t want to copy paste sensitive information? Also, not sure what the OPs point is, you can have autofill on native apps too.

> Why would my program present ads?

Because you’re a penny counter at big tech who subsidizes their product by stealing user information?

> Is that supposed to be a plus? Consider the user's side, too. Also, consider that things like Google Safe Browsing exist.

Web has one of the most hardened sandboxes out there, just because it was an attack vector for decades. Yes, it’s a good thing - less friction.

> Care to give an example?

VSCode loads faster than Xcode. Google Sheets loads faster than Numbers. On Windows you can start VSCode and brew coffee until VS is ready to roll.

> Because I as a user don’t want to copy paste sensitive information?

When using my program, why would the user need to supply a password or a credit card number?

> why would the user need to supply a password

Because they’re logging in to your application and then buying a thing with a credit card?

Why would I write a program for this, when we were doing it decades ago with web pages that honestly didn't even require JavaScript to function?
Because your product is a program and some of the features are paid. So you have a screen for the user to start/manage/cancel their subscription? It doesn't have to be some JS heavy thing, just that it will be a page in your app and you get autofill for free from the browser.
Can't agree more. The web has won, and for the vast majority of apps, it's not even close.

I wish I figured this out years ago. I spent significant time learning and building with Flutter, iOS native — chasing that "native feel" — only to realize that for most of what I was building, a well-crafted web app would have been not just good enough, but actually better.

I also find building apps for the web is much easier than any of the native frameworks. You can start by writing plain text in a file and then progressively add HTML, CSS, and JS. The app described in the article is trivial to implement in the web.

A lot of that comes down to the huge community and the shear amount of documentation that exists. OTOH, nowadays you will quickly be distracted by frameworks and build systems.

IMHO the biggest hurdle is hosting, but github pages makes even that somewhat easy.

> A knee-jerk answer is often "performance", but honestly, most web apps load faster than their native counterparts these days.

This is so off-the-mark I am skeptical of the rest of the claims in this list.

The MS Word webpage absolutely loads faster than MS word. Same with Outlook. Microsoft is even about to cheat https://www.theregister.com/2025/05/01/microsoft_will_preloa... and preload their apps to fake faster load times.
> and why so many of native toolkits feel uninspired and lacking any real innovation.

You ever thought that it’s the reverse? That native toolkits were left to rot, because it’s always the cost center (looking at you Android team, you’re a fucking disappointment), while web continued to evolve?

> - Users can block ads

Google fuckers are desperately trying to fix the “feature”.

Native apps are where power users and other non-developers can do programming. The type of things that an engineer who lives in the terminal might make a CLI or TUI for, an accountant or project manager might want to do with a GUI. This is where VB6 and VBA lived, probably also HyperCard. Web tech has too much complexity for that.
> Web tech has too much complexity for that.

Too much complexity like checks notes Google Sheets, VS Code, Notion.

None of which were made by accountants. They were instead made by engineers who have experience and training in dealing with complex software systems.
This hit a nerve as I am in the middle of developing a webapp for myself using NiceGUI. I find CSS, especially its layout framework, pretty confusing and sometimes downright intimidating to work with. `inline`, `block`, `flex`, `grid` seem reasonable when you read about them. But when using it, especially within frameworks when flexboxes are nested within grids which are nested within flexboxes and so on, it becomes hard to reason about. And then you throw in media-queries in the mix and it becomes even more dense.
> most web apps load faster than their native counterparts these days

maybe i'm doing something wrong, but from what i've noticed, the browser is usually what takes up most of my computer's resources.

also, i assumed the reasoning for using a native app was for offline use, honestly.

No you're not. They just made it up :)