What apps do is add eas of install (app store), and usability (cache, use device sensors, do some offline tasks)

For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app, no address bar. Usability is tackled by modern browsers that allow webapps started like this to: - cache the entire webapp, and some/all data it requests. - run webworkers in background, (get push notifications, etc) - provide sensor access via APIs, (camera, etc) And to conclude, todays webapps respond FAST. They do everything the same way a native app does.

Ofcourse if your webapp does video transcoding or uses some specific OS feature it might profit from being native. But even then, its unbelievable easy to wrap your webapp in a shell that adds these functionality.

How do you think FB and other popular content consuming apps work nowadays? You are basically looking at webapps rendered in a shell that provides the few APIs a browser doesnt yet have, like share button and contact/calendar integration, to get/set data specific to/on your device.

Also literally NONE of the biggest most popular apps are HTML5/native. FB, Twitter, Uber, etc... are all native apps.

Which would mean any malicious site a user got tricked into visiting can access the native API. (Downloading an app is more deliberate than visiting a site and instinctively clicking to make the pop-up go away.)

All I'm saying is there are non-financial reasons why an OS designer might sandbox websites from the native API.

I like React Native and apps written in it are just fine by me but the browser and the web doesn't compare in L&F or responsiveness. Maybe someday down the line, but not now.

> For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app, no address bar.

Only as long as you have an open Internet connection. Maybe a properly made web app will cache itself somehow, but that process is relatively obscure and (from the user's POV) pretty unreliable. Whereas a native app is an executable on the phone, it will run whether or not you're on a network.

> They do everything the same way a native app does.

Only slower and worse. Between basic UI functions being (poorly) reimplemented one abstraction layer and extra VM level higher, and random 404 screens because oops, you briefly lost connectivity, it takes lots of extra work to get a web app to native level of quality - at which point one might want to consider why they didn't write it native in the first place?

> How do you think FB and other popular content consuming apps work nowadays? You are basically looking at webapps rendered in a shell that provides the few APIs a browser doesnt yet have, like share button and contact/calendar integration, to get/set data specific to/on your device.

Yes, I can tell, by the frequency with which it breaks in unexpected ways, and shows its internals - by e.g. giving you a web error page instead of the app-specific one, or just giving you a blank screen.

Webapps are just "worse is better" in action. Gross.

As far as I know, the web alternatives are miles behind the convenience of ”click the side button twice to confirm this payment” that an app provides.

Majority of the content on these apps is native and not html/js. They have a small amount of content on the settings screens in html/js but all of the main view code is native. For an app with complex layouts and content like facebook, html/js scroll performance would be far too slow. You can easily verify this by running the application with UIAutomator turned on which will show you the widgets being used on screen.

Native is faster because it's not layout and control agnostic. So you get controls like recyclerview which recycle view elements while scrolling large lists to keep animations smoooth. Sure, you can implement that in javascript too, but the javascript can't beat a native c++ implementation which is also GPU accelerated. This is also the reason why frameworks like React Native and Flutter were born. They use javascript/dart but render all UI content natively which allows them to maintain smooth 60fps animations.

To be honest, I wouldn't like mobile going the html/js way at all. Html/js has moved to desktop with electron and the results aren't that great. They take up huge amounts of memory ( gmail web on chrome takes up 500mb of ram on my machine, also slack is a noteworthy mention). Native desktop apps take up a fraction of that memory. For the sake of accessibility we have significantly sacrificed performance. I can't wait for webassembly to be widely adopted so that the browser can move away from html/js. Google has a nifty tool called ArcWelder which allows android apps to run in chrome. Apple has already announced support for running iOS apps on Mac. Would people really want to use html/js apps if they have native and more performant apps available on their platform?

Does this finally work? I remember first reading about this many years ago. I tried to make a simplest-possible webpage that I could "add to homescreen" and have it work like a native app. Unfortunately, there were too many critical features that were missing, broken, or unreliable.

Every couple years I've tried again, and every time I've failed. Does it finally work? Is there any example of a webpage which can successfully pretend it's a phone app?

No, it doesn't, I'm sorry. It's often a far cry from how a native app would be behave, both in terms of usability and performance.

Yeah, I'll download an app for Uber or Southwest airlines or Airbnb because their two-way information requirements work better as apps. But I won't clutter up my phone with things that work just fine in a browser, which is most of what I need. I don't play games, so maybe I'm not most people.

Here it's true if you talk about official app, which you seem to be doing, but there's a couple of other options - apps made by community, which can be way better than official anything. I guess that Reddit doesn't want to fall behind and that's it.

That's the window for apps to compete. If "just fine" works for you, cool, but it's possible for apps to make the experience better in meaningful ways. A web page can't notify of you a new message, but an app can, for example. Look at all the Twitter apps that came up, and they've had to start to systematically kill over time because the experiences are _so much_ better than Twitter in the app. "Just fine" doesn't push us forward.

Now if we could just get app designers to realize that!

IME, apps are usually just poor front-ends for the website, where companies think it's OK to shove stupid things like unblockable ads, notifications, data-harvesting, etc.

Oh, reddit on mobile without an app is a displeasing experience. The official app though, isn't much better.

I do have apps for all the shoppibg platforms I use, even though the performance isn't substantially better

Like you said, it's slow, drains battery and add a barrier to customer conversion.

But also:

Web apps don't have a direct access to the file system. Forget about filming or recording voice and saving that for anything serious.

They can't respond to intents, making them completly isolated from the rest of the OS.

They can't use the share function so your data is hard to extract, move around or ... well, share.

They don't have access to the cryptographic facilities, or the authentification ones (e.g: no finger print unlock). They can't be directly filled in by other apps like lastpass. You can't even chose between security and convenience.

The amount of data they can store is very limited, hard to manipulate, and the API changes from one browser to the other. Unless you have a bit of texte, though luck.

Basically, anything that is not a simple CRUD service is useless offline, and slower online than the app version.

Plus, how many people know that they can "add this app" to the home menu ?

Not to say you should not offer a web version of your app. But it's an ersatz.

> The data I have seen from the old company was this: people who installed our news reader app were 4-8 times more engaged than the people who used our uber mobile friendly and fast news site. Apps can be faster, handle offline/near offline far better.

I think you're mixing up causalities here. Those users that are already more engaged are the ones that can even be bothered to install your news reader app. How many users is that though? Do they make up for the ones that don't install the app? You're probably going to need both anyway, you're paying for both, you better make sure the native app is worth it. For a lot of business, it isn't worth it.

The core issue is that people aren't willing to install any more apps. Case in point, the very article wants me to install the "Medium" app. I'm not going to do that, because it's pointless. Medium works just fine as a website and that's true for most other apps you use merely on occasion. Could it be more responsive, use less battery, if it was native? Of course. I don't care.

Is there any source for this? Are app installations declining?

This isn't 2010 where everyone wants the top 25 apps, and could actually install them since they weren't hitting 100mb each. Inflation of app sizes and continued premiums on useful storage amounts from Apple has been forcing people to cut the fat and keep only the most essential apps installed. Even if you had a large iCloud account for your photos or texts to reside off your device, you still need local storage for apps.

Of course strictly speaking I will install more apps in the future, but the chance that it's going to be the kind of App that I could just use as a website is practically zero.

This was the case a decade ago, but not anymore. I have been writing medium complex web apps using Angular/React, Web-workers and RxJS which runs on mobile (Android 4.4+ and iOS 9+) from last 4 years with no extra battery draining side effects and native (like) look and feel. You just need to choose write framework and responsive design UI guidelines. Today most frameworks provides it out of the box. JS, DOM and CSS engines in mainstream browsers are getting more and more performant.

Moore's law is getting us out of a hole. The processing power, and performance per watt on mobile has increase exponentially. Those people who who are stuck on three year contracts feel the pain of this idea. Yes, JS engines are getting faster, but they are being asked to do more and more stuff.

React native is a marvel of engineering, where the bridge intercepts UI calls and diverts them to native. But thats not a webapp, that re-invented version of QT, Wx, tk or whatever java uses.

My point is this: a native app on a underclocked pi zero, can animate UI items at 60FPS. Via a browser, no where near. HTML is many things, but efficient is not one of them. HTML/CSS/JS is a marvel of engineering to get it anwhere near as fast as it is, but its comes from a very slow base.

It’s an ecological concern as well: how many gigawatts of electricity a day is spent fetching react.js?

I've been asking questions like this for years now, mostly as rhetorical devices, but I swear one day I'll try to get data and compose a chart of "how much your bloated product is contributing to climate change".

And it seems that server usage consumes around 1% of the USA energy budget. Heating, industry and transportation are most of that list. Not sure apps are going to show up.

I don't expect the answer to come out very high, relative to other things. But it would be good to see an absolute value, if only to drive home the point that everything your software externalizes to your users has costs multiplied by the number of those users.

How much electricity is spent by developers using Electron based apps like VS Code and Slack and npm packages during their work hours? We should all develop in terminals, with no GUIs and no GPU usage. Only in non-bloated languages like C and ASM. Anything else is crime against the climate.

All sites should also be text only (like the motherfucking website), no images, especially hero ones.

Of course they were more engaged, they're the tiny minority that cared enough to find and download your app.

You have't adressed the most important point in the article - people simply don't want hundreds of apps on their phone.

But how many people installed your reader? I think it's easy to explain why they engage more with your site in your app: they have nowhere else to go, and the website icon is there, on the screen. This doesnt scale

Its important to say that it was a choice, there was no full page banner or bouncer that forced people to install the webapp, it was entirely optional.

If, however you are saying that people only click on it because there is an icon on their phone, then you are making possibly the biggest argument for keeping apps (although its perfectly possible to have webapps on the homescreen with icons)

It seems to me the category of people who have gone to the length to install an app is perhaps going to spend more time with the content compared to the full set of people interacting with the content.

Engagement is measured across the entire subscriber cohort. consumer "councils" are made up of a selection of subscribers, so we can adequately get data from all sections.

We had a webapp, the users were very engaged. We replaced the webapp with a native app, we got way more people who very engaged, we also got loads more people who were mildly engaged. The overall effect was more engagement from a wider base of subscribers.

Lowering the bar to entry, proper offline caching of content, faster loading, just a better more seamless experience.

I mean, I agree with you that simple web pages are best for simple news and articles. But I don’t think you can immediately generalize that to “apps don’t scale”.

Most mobile developers have no idea how web-centric non-mobile devs are. I've recently started working in a web-centric company, and am the only mobile dev. It's mind boggling, freaking unbelievable how less open minded web developers really are. I had no idea.

I don't know what is the cause of this, but this article is pretty common to the crowd who were trying to convince everyone that Phonegap was a viable solution 5 years ago. All I know is that the web community need to get this kind of hyperbole under control because they're losing credibility.

I've almost reached the point where I don't take anything they say seriously anymore, especially when it comes to platforms that they've never spent a single project developing on.

o can I find what I want o can I find it easily o can I find it fast o can I view what I've found properly o nothing gets in the way of getting what they want.

slow load time, dodgy networking, waiting for app to load from notification, losing your place, inconsistent or foreign UI, all make the user scream in annoyance.

"TRY OUR APP" fits stops you from viewing what you want.

Linked in on mobile is shite, you have to use the app. The emails don't redirect to the app, which is fucking stupid

Twitter's desktop site is rubbish, the mobile version is slighty less annoying, you have to use the app.

Facebook's webapp is really slow.

agree. right or wrong, as an android user, i feel less vulnerable, less bloated, less violated, using a web app than i do installing a native app.

For whom is it better? Me, the customer, or you, the vendor? I buy furniture from Wayfair's website, and browse on the site quite often. On the mobile site, I'm able to view products, add/remove them from a wishlist, and make a purchase. All from a browser with ad and tracking blockers enabled.

Wayfair still puts a "Download the app!" popup on the site, even though it can see from my repeated visits and purchases that I primarily use the mobile site. I imagine it's because on an app, notifications are opt-out and tracking is continuous.

As for your imagination about tracking, it’s both false and paranoid. Mobile notifications are opt-in, and tracking is limited to behavior within the app, unlike the web where you are tracked across sites wherever you go.

I agree it’s still suboptimal for now, incremental improvements are making it less so year over year. More parts of native apps are also getting written with web technologies. Eventually, maybe, most of the app icons in our phones might just be a shortcut to some website

If you continue the current trends, this process could involve making WebAssembly more powerful, making CSS and Web Components into an actual widget framework and adding more capabilities to service workers to enable OS hooks, background activities and offline use.

However, all of those changes will push web apps into the direction of becoming more "app-like", not more "web-like".

So after the improvements are done, I think we might end up with just another framework for building apps, not having moved away from apps. (With the one downside that HTML will still have to drag around reams of cruft to maintain backwards compatibility which other app framework could easily do away with)

I’d add that that’s the good scenario. The bad scenario is that everything goes the way of desktop apps, where everything just becomes a lowest-common-denominator web page with crappy UI design that doesn’t really use the platform effectively, just because it’s cheaper that way and cheap always wins.

For the longest time it was. Because $newsCompany was subscription it had to leave the apple store, or give apple ~25% cut. To get round this we had a fully offline HTML5 webapp.

it was very good, but despite mega optimisations, it was slower than native, and had limited storage.

Users were constantly asking for a native app, In every customer council/survey. Bear in mind that these people were not techhead, they were babyboomers who struggled with tech, they knew enough however, to know that native apps were faster. (for example the times, grauniad and telegraph. )

That's maybe because people that are engaged with something could be more willing to install the app. Also once the app is installed there is an icon on your phone constantly reminding you to use it.

you are correct, not all apps need multi-threading, but it sure is useful. Especially if you don't like callbacks. Blocking the UI to do a HTTP call with no network isn't not a good move.

> GUI is most easy part for web app to mock.

Yes, but thats not my original point. Mocking a UI in a webapp easy to do, but very hard to do fast, smooth, offline capable, with all the features you want, and cross platform.

Most comparisons I've seen talked about here on HN, seem to think these two are equivalent. They're not.