zlacker

To be fair, browser apps do have their advantages:

- text is selectable

- content is zoomable

- you can have an ad/nuisance blocker

- page source is open

While native apps have their own advantages:

- much smoother experience esp. navigation, scrolling, animations, etc.

- better overall performance (JavaScript will always lose to the native binary)

- access to hardware opens new possibilities; audio, video accelerators etc.; there's a ton of things you can't do in the browser with audio for example

- widgets, some of them are nice and useful too

- for publishers: an app icon on the home screen is a reminder, a "hook" of sorts; this is the main reason they push apps over web versions

>>mojuba+(OP)
All the features you mentioned can also be achieved by a well developed PWA. Of course, minus the widgets or some deeper system integration (like controlling phone calls etc.)

>>blackl+B5
Try to build a more or less serious music synth in the browser that won’t kill your battery.

>>mojuba+qi
Heh, I was actually building one. Haven't considered the battery... Are the web audio APIs bad, or are you forced to use the CPU? I guess with webgpu it may be easier?

>>firtoz+Ti
I think on iOS you need access on the CoreAudio level if you want to be efficient, ie fill audio buffers on a high priority thread with some lower level static language.

>>mojuba+(OP)
> browser apps do have their advantages:

These are more like byproduct of the fact that web apps are built on the stack not suited for modern UI apps. It's literally a text typesetting engine pretending to be a rendering engine for high-performance UI.

So, it can also be framed as:

- everything is selectable, even what shouldn't be - buttons, drawers, video players, etc - content is zoomable, which most of the time just breaks UX in hilariuous ways. Developers have to do extra-work to either disable zoom or make hacks/workarounds.

"Everything is selectable" and "everything is zoomable" makes total sense if it's a blog post. If it's a UI for the modern app, it does not.

>>divan+Bs
Disabling zoom is so hostile, why not disable screen readers and put bollards on handicapped ramps while you are at it. It’s literally a middle finger to older people and people with vision issues. If you disable zoom I will not be using your website.

>>divan+Bs
> It's literally a text typesetting engine pretending to be a rendering engine for high-performance UI

This is an outdated view of the web. Catch up or be left behind.

>>mvdtnz+201
This is factual view. No matter how many layers of abstraction you put on top, the foundation is always there. Luckily we have better and better support for wasm in browsers, so it's a matter of time when this outdated stack will be replaced with solutions designed from the ground up for the task.

>>rblatz+CS
Luckly most popular operating systems have concept of global text size that can be adjusted, and non-web UI frameworks respect that.

>>mojuba+(OP)
+ working notifications - adblocker is more of a minus for publishers though

But mainly don't expect any good web app integration on mobile, because it would hit the store 30% tax.

>>divan+Bs
Web just have defaults that are not suitable for apps. Disable text select is one line of css, not that hard.

>>mojuba+qi
Of course, I'm not saying that one size fits all.

There are cases like media apps, camera apps, videogames, terminal emulators, clipboard managers etc. that won't become Web apps any time soon.

Either because they need to operate closer to the OS, or for performance expectation reasons.

But I've just had a quick scroll through the apps on my phone, and I can confidently say that 90% of them are basically HTTP clients that interact with an HTTP server.

And even those that do more could probably be wrapped into a WebAssembly artifact with comparable performance in a near future.

The reason why they are not PWAs, and why engineers are often expected to do triple work (iOS, Android, Web), and why there aren't more products released as PWAs, keeps eluding me.

Sure, you have to tell folks how the "Install/Add to home screen" process works from a mobile browser, but is it that really that much more friction compared to an App Store paradigm to justify the abuse of native apps that either reinvent the wheel multiple times, or are just unglorified Web browsers running an Electron app just to show you the discounts at the supermarket near your house?