Hacker News Reader

Comment by em3rgent0rdr | Hacker News Reader

> "do something that can be done in a web app"

I'll bite. What important features can only be done in an "app" but not a web app nowadays?

NFC reading is one. That's why lots of Governments publish apps - it's a reliable way to check your passport if you need a visa etc.

It might be coming to the web - https://developer.mozilla.org/en-US/docs/Web/API/Web_NFC_API

Do they require it though? I've used a few, but it's always been a convenience thing to use the NFC-scanning app; the alternative is just typing in the details manually.

Yes. It offers cryptographic proof that you physically have the passport with you. It also gets a digital copy of the photo and other biometrics held on the NFC chip. From a user point of view it reduces the number of typos entered.

Kazakhstan has an app (QazETA) for its electronic travel authorization, which is required for many passport holders who want to enter under the visa-free regime. (Perhaps it is not strictly required as one could apply for a visa instead.)

Somewhat confusingly, the iOS App Store description [0] of the app says that it is not a government app, while the rest of the internet and Kazakh government sites say that it is the official government app for the purpose of applying for the ETA.

[0]: https://apps.apple.com/app/id6748705452

Realtime stuff. Audio, video etc, games. Apps with a large user library (like the Photos app) that should work offline.

Right. Of course there is some overhead for using WebGL vs native OpenGL calls, but I think that's only noticeable for AAA games. Web audio's extra latency does make it undesirable only for things that require quick response, like realtime synths and maybe DAWs.

Regarding libraries, I wonder if maybe there could be a cacheable package manager system for distributing wasm libraries to webapps.

A ton of features work only or better on app:

  - anything privacy sensitive
  - anything processing intense (using optimized binaries)
  - widgets
  - camera and audio based features *can* work, but are more finicky (or outright broken on ios)
  - local storage (exists in web app, short lifetimes on web site)
  - performance/latency sensitive work
  - (I'm less familiar, but probably local sensors, like gps and acceleration)

It's a shrinking area: You can get GPS, accelerometer, etc inputs from a web app nowadays. From my own experience the main areas that are tricky are related to automatically finding and connecting to devices: you can do bluetooth at least, but there's things an app can do with wifi and local connection protocols you can't easily do with a web app.

anything privacy sensitive

You've got that backwards. Web is more private than an app.

Every regulated healthcare company has a web site. None require an "app."

It depends. Truly working offline, which is as private as it gets in many scenarios, isn’t really feasible with web apps.

You could also work in a windowless steel box inside a cave at the top of a mountain, if you really want to move the goalposts.

Why is this moving the goalposts?

Native apps can work reasonably well offline and online. Web apps can’t, currently.

"Progressive web apps" can be installed to be used offline: https://en.wikipedia.org/wiki/Progressive_web_app

Nope... What you're talking about is not privacy sensitivity, but trust.

For you, you don't trust the provider of the software, so you mean being able to put a barrier around your life, and the delivered software... you think that by running in a browser, you're preventing that code from being connected to anything else... However, anything that happens in that code is directly connected to the provider, whom you don't trust.

I'm referring to the opposite... having something connected to your life, but having a barrier disconnecting it from the outside world... It involves trusting the provider of the software (maybe it's open source), but even if you don't, you can install an app, cut the network, use it locally, then delete it before restoring the network, and you have a guarantee that what you did with it was private... It's possible to build that into a web app, but most websites don't work offline, where most apps (though not all), do work offline... even if it requires an initial network session to establish authorization

I sign in to video calls using my browser every day. Saying video/audio requires an app beggars belief.

Privacy is the opposite of what you get with an app. Privacy? Really?

Local storage is available to browsers. Office 365 literally functions in a browser with full access to local storage.

Anything processor intensive can be compiled to WASM. This isn't 2005 anymore.

So... widgets?

I can see an argument for games, where you want to pre-install a large amount of resources, and maybe have a better i/o story. Even that is a function of convenience over necessity.

> anything privacy sensitive

I'd actually prefer that stuff stay in a browser and far away from my local storage on a device I take everywhere. Seems far riskier having it locally.

> anything processing intense

I can play Half-Life 2 in a browser window these days. I can do photo editing and CAD in the browser. I can have entire IDEs in the browser, compilers, non-linear video editors, and more. We're also kind of scoping this to phone apps, they're usually not very processing intense as you quickly hit heat and battery limits.

> camera and audio based features can work, but are more finicky (or outright broken on ios)

Sounds more like an overly restricted OS than anything else.

> local storage (exists in web app, short lifetimes on web site)

Once again, sounds like an overly restricted OS than a browser issue.

> (I'm less familiar, but probably local sensors, like gps and acceleration)

https://sensor-js.xyz/demo.html < works fine

https://openstreetmap.org < works fine

It’s also about friction.

No one wants to troubleshoot a card decline by logging into their mobile browser bank account in checkout at the grocery store.

You mean some kind of perceived personal convenience through the uneven-handed profit of others and at the expense of everyone else.

Trying to check why your card was declined at a checkout—while still standing at said checkout? Troubleshooting "PIN issues" (meaning your bad)? Is everyone still standing behind you at this point? LOL. Exactly.

> “Just log into your bank account on the mobile web browser” is a pretty clunky way to see why your card declined.

But that's because the user experience as designed is more hostile or not otherwise accounting for mobile use--right? Or are you saying there is a limit to the web platform's ability to reduce friction?

My credit card doesn't need me to lock/unlock it, doesn't require I have a phone with me, and certainly doesn't require an app. The last thing I ever would want is for the people in charge of "apps" to have access to my finances. All you are doing is creating another layer where something is allowed to tell you "No". Why would you choose this?

Right, and I can't remember the last time the battery in my credit card died or needed recharging. Phone has died plenty of times when I needed it

No one wants to troubleshoot a card decline by having to download and install a 700MB bank app in checkout at the grocery store either. Personally I'll take the browser login every time in that situation!

Reply on news.ycombinator.com