Why do I need a native binary, tens of thousands of lines of code, an app with a massive permissions access to my device...
To read a news article?
To book a flight?
To comment on an internet post?
Adding a few more "app features" to light web pages sounds a whole lot more attractive than banishing all useful functionality into the den of apps, where only larger teams and more experienced developers can roll out even basic functionality.
Apple is ensuring that most of its ecosystem is fast and pleasant.
You don't – but why do you need loading screens, push notifications, or any of that other stuff either?
The web is great in concept for document-oriented information and some application uses. Mobile applications are greater for richer user interfaces and more device integration. They both have their strengths, and I think it's okay to accept that.
I booked the holiday I'm currently on to China almost entirely on an iPad, I could easily have done all of it that way, with none of these features.
The author got it right:
> Apple treats web apps like second class citizens because they don’t generate money like native apps in the app store.
There won't be good support for web apps unless they find a way to make money out of them. If the day comes that native apps don't make money anymore, maybe because everybody gives them for free as front end to services paid outside the Apple Store (think Slack), then Apple could improve Safari and live only with revenues from the hardware.
It's going to be a hard fight because the goals of Apple and the goals of developers (and maybe also the goal of their customers) are not aligned and they own the platform.
> To read a news article?
I refuse to use a native app for this (e.g., Apple News, Flipboard). I love reading my news on the web. In a browser. Where the page is the content and the browser is the convenience. Even better is having Safari's "Reader Mode" enabled constantly so every article is consistently and nicely formatted and I get just the text and links.
> To book a flight?
Same thing for booking a flight, last time I did that was on a web site. With some forms and a few "Next" links to go to the next page until I was done.
It was nice to get the boarding pass in Apple Wallet though and then use that to board.
> To comment on an internet post?
I'm commenting on this post right here in Safari. I wouldn't ever want to use an app for it.
I don't need more "app features" on light web pages. Especially not the ones mentioned in the article.
You seem to be laser-focused on this one tiny part of PWAs. There's way more too it than that, like offline support, background sync, etc. Imagine if you could press a button on the page to save that article you're reading for later, and have it available offline next time you need it.
Or what if you could write a comment while offline, and have it be automatically posted next time you have a connection. (Or optionally, have a notification pop-up next time you're online asking if you still want to post it.)
PWAs are just flat out _better_ than existing web apps. It's remarkable to me that so many people seem to be against these incredibly useful features just because the app they're using is web-based rather than native.
> Why do I need a web app, tens of millions of lines of code, a website with massive permissions to my browser.
> To read a news article?
> ...
On booking a flight: I'm not sure how doing this offline helps? Last time I did it, I did have to wait for pages to load after clicking links but it was on the order of seconds or less. And not anything frustrating.
On commenting on an Internet post: Doing it offline is not really interesting to me, and I'm not sure how that would work (which is why I'm happy to do it in a browser). Hacker News is more than fast enough. It's really minimal.
Well, actually they can, as Twitter has shown. It looks like Apple is trying to pull an Internet Explorer on us though.
Sure, but PWAs allow for so much more than that. For example, you could not only read the article offline, but also _comment_ on it offline and have your comment automatically posted next time you have a connection. Or you could click a button to have all future articles from a particular news site automatically synced in the background while you're on WiFi so they're available for reading next time you're out; no manual downloading of each individual article required.
> On booking a flight: I'm not sure how doing this offline helps? Last time I did it, I did have to wait for pages to load after clicking links but it was on the order of seconds or less.
A PWA would allow much faster interaction than that. Seconds or less? That's terrible compared to the performance you _could_ be getting out of a PWA (i.e. near instant, like what you'd expect from a native app).
> Doing it offline is not really interesting to me, and I'm not sure how that would work (which is why I'm happy to do it in a browser). Hacker News is more than fast enough. It's really minimal.
Sounds to me like you're already content with the experience you're getting from the web. That's fine, but it's no reason to oppose features that would make the experience even better for those of us who do want them.
This is available on Safari, the same browser the author is bashing and comparing to IE.
And it's synced across macOS and iOS. It's called "reading list". It works with airplane mode and everything.
If only we had a standard way to do this...
Not to mention PWAs would allow for more complex offline features Safari doesn't support, like syncing the front page of a news site and all associated articles, or automatically downloading new articles as soon as they're posted.
You'd hit "Next", the screen would push over instantly. But there'd be a loading indicator right in the middle of it until the server returned the necessary data. Asynchronous apps or web sites or web apps will always need to load data from somewhere. PWA doesn't magically make loading go away.
I'm okay with adding offline support, faster loading, and all of that for web apps and sites I use in my browser. None of those features sound bad to me. In the browser.
I think that's where we'll have to disagree in some sense.
Adding features to the web platform will of course mean that web applications have access to more features. Some of those are great – I'm really glad we have geolocation, for example.
The trade-off is that every feature added to the platform incurs cost and complexity. Trading these off is important; what is the point in web apps that do everything native apps do, but in a somewhat less good way?
There are obviously pros and cons here, and I'm not convinced that the use cases for more complexity are beneficial enough to justify it.
Web applications are fine, and have their place. I'd argue that place is not as frequently-used, heavily interactive applications; native apps exist for that, and are better in most ways.
This is the thing – some publishers insist on using their stupid application when all I want to do is browse some content. Other publishers insist I use their shitty JS-HTML-Hybrid nonsense because they are too stingy to develop proper applications. I wish we could learn to more effective use technologies in the right places.
Well it seems like either each and every website could build offline support and background sync into their site, or you could use a browser that does it for you.
In the former case, if you rely on sites integrating it, you could be frustrated when some sites do not implement background sync and offline support (or do it badly).
Having the browser do it seems simpler. Especially given the real world use cases for this feature.
(I'm not against having these technologies on the web. Just seems more sensible for a browser to do your reading list — just like it manages your tabs.)
That was the case in the 90s, and hasn't been the case since. "Some times, that are so rare that people point to it and comment on it on forums", yes.
> This is the thing – some publishers insist on using their stupid application when all I want to do is browse some content.
That's exactly the problem PWAs solve. Those publishers want some features that on iOS are only available to native apps, and so have to make the experience suck for Apple users by using an installed native app instead of a web app. Both publishers and users have an aligned interest there for PWAs, which goes against Apple's own interest.
We're laser focused on the annoying parts that we know will be abused to death.
"Imagine if you could press a button on the page to save that article you're reading for later, and have it available offline next time you need it."
Most browsers already do this.
"PWAs are just flat out _better_ than existing web apps. It's remarkable to me that so many people seem to be against these incredibly useful features just because the app they're using is web-based rather than native."
Because we already have native apps to do these things. I don't want websites to do these things. I want a website to be a website.
If you're talking about fonts rendering differently, or some line being some pixels further to the right, same thing; incomparable.
If you're talking about corporate web apps written for IE, those aren't accessible from a phone anyway, so the distinction between native and web app is meaningless for them.
If, instead, you're talking of websites that really don't work on a modern browser, and you stumble on them day to day, you just have an experience that's different from most other people. The easiest way to tell that what I'm telling you isn't just my individual experience is to compare what you see and read today from what used to be the case in the days of IE domination.
Acting like a dick that thinks people that disagree with you are in a sorry little bubble of ignorance is just a character flaw; nothing to do with this.
It's not comparable to writing multiple native apps, but it's the exact same model as having to use cross-platform toolkits like QT. The web has just replaced OS with browser.
> taking about fonts rendering differently
This mimics what happens when using something like QT or Java since they at least try look kind of like the platform they're running on.
> talking about corporate web apps written for IE
IE & Chrome specific features are exactly kinds of things that make cross-browser development just like cross-platform development. Your site either has to use the lowest common denominator or be littered with platform ... err browser specific code -- exactly like native apps.