Optimizing PWAs For Different Display Modes — Smashing Magazine
There’s really good browser support for display-mode
media queries and this article does a really good job of running through some of the use cases for your progressive web app.
There’s really good browser support for display-mode
media queries and this article does a really good job of running through some of the use cases for your progressive web app.
SPAs were a clever solution to a temporary limitation. But that limitation no longer exists.
Use modern server rendering. Use actual pages. Animate with CSS. Preload with intent. Ship less JavaScript.
An excellent appraisal of the importance of the rule of least power.
Why single-page apps are just not worth it:
Here’s the problem: your team almost certainly doesn’t have what it takes to out-engineer the browser. The browser will continuously improve the experience of plain HTML, at no cost to you, using a rendering engine that is orders of magnitude more efficient than JavaScript.
Meanwhile, the browser marches on, improving the UX of every website that uses basic HTML semantics. For instance: browsers often don’t repaint full pages anymore.
Rich suggests another reason why the UX of websites on mobile is so shit these days:
The path to installing a native app is well trodden. We search the App Store (or ironically follow a link from a website), hit ‘Get’ and the app is downloaded to our phone’s home screen, ready to use any time with a simple tap.
A PWA can also live on your home screen, nicely indistinguishable from a native app. But the journey to getting a PWA – or indeed any web app – onto your home screen remains convoluted to say the least. This is the lack of equivalence I’m driving at. I wonder if the mobile web experience would suck as badly if web apps could be installed just as easily as native apps?
Many interactions are not possible without JavaScript, but that doesn’t mean we should look to write more than we have to. The server doing something useful is a requirement for building an interesting business. The client doing something is often a nice-to-have.
There’s also this:
It’s really fast
One of the arguments for a SPA is that it provides a more reactive customer experience. I think that’s mostly debunked at this point, due to the performance creep and complexity that comes in with a more complicated client-server relationship.
Remember when every company rushed to make an app? Airlines, restaurants, even your local coffee shop. Back then, it made some sense. Browsers weren’t as powerful, and apps had unique features like notifications and offline access. But fast-forward to today, and browsers can do all that. Yet businesses still push native apps as if it’s 2010, and we’re left downloading apps for things that should just work on the web.
This is all factually correct, but alas as Cory Doctorow points out, you can’t install an ad-blocker in a native app. To you and me, that’s a bug. To short-sighted businesses, it’s a feature.
(When I say “ad-blocker”, I mean “tracking-blocker”.)
“And so what we did is we started looking at, internally, all of the places where we’re using web technology — so all of our internal web UIs — and realized that they were just really unacceptably slow.”
Why were they slow? The answer: React.
“We realized that our performance, especially on low-end machines, was really terrible — and that was because we had adopted this React framework, and we had used React in probably one of the worst ways possible.”
This proposal is exactly what I was asking for!
C’mon browsers, let’s make this happen!
It’s a shame that the newest Safari release is overshadowed by Apple’s shenanigans and subsequent U-turn because there’s some great stuff in there.
I really like what they’re doing with web apps added to the dock:
Safari adds support for the
shortcuts
manifest member on macOS Sonoma. This gives you a mechanism in the manifest file for defining custom menu commands that will appear in the File menu and the Dock context menu.
Hallelujah! Apple have backed down on their petulant plan to sabatoge homescreen apps.
I’m very grateful to the Open Web Advocacy group for standing up to this bullying.
This is exactly what it looks like: a single-fingered salute to the web and web developers.
Read Alex’s thorough explanation of the current situation and then sign this open letter.
Cupertino’s not just trying to vandalise PWAs and critical re-engagement features for Safari; it’s working to prevent any browser from ever offering them on iOS. If Apple succeeds in the next two weeks, it will cement a future in which the mobile web will never be permitted to grow beyond marketing pages for native apps.
Also, remember this and don’t fall for it:
Apple apparently hopes it can convince users to blame regulators for its own choices.
When it benefits Apple, they take the DMA requirements much further than intended. When it doesn’t benefit them, they lean back on the “integrity” of iOS and barely comply at all.
I don’t like to assume the worst and assign vindictitive motives to people, but what Apple is doing here is hard to read as anything other than petulant and nasty …and really, really bad for users.
If you’ve ever made a progressive web app, please fill in this survey.
In the same vein as that last link, Chris says what we’re all thinking:
Most of what we build is links from one page to another, and
form
submissions that send data from the browser to the server.
Web Push on iOS is nearing its one year anniversary. It’s still mostly useless.
Sad, but true. And here’s why:
On iOS, for a website to be able to ask the user to grant the push notification permission, it needs to be installed to the home screen.
No other browser on any of the other platforms requires you to install a website for it to be able to send push notifications.
Apple is within their rights to withhold Web Push to installed apps. One could argue it’s not even an unreasonable policy - if Apple made installing a web app at least moderately straightforward. As it is, they have buried it and hidden important functionality behind it.
I really, really hope that the Safari team are reading this.
Why the heck is everyone reaching for React as soon as something on the screen needs to update? And why do we insist on squishing our frontend concerns together with our backend concerns?
I’m glad I’m not the only one constantly asking myself those questions.
Look: is the idea of physically separating “code that runs business logic and builds markup” from “code that handles realtime interactions” really that awful? You can write both in JS if you like, I promise I won’t judge, but we can’t keep pretending that they’re basically the same.
If there’s one takeaway from all this, it’s that the web is a flexible medium where any number of technologies can be combined in all sorts of interesting ways.
Lots of new features landing in Safari, and it’s worth paying attention to the new icon requirements now that websites can be added to the dock:
To provide the best user experience on macOS, supply at least one opaque, full-bleed
maskable
square icon in the web app manifest, either as SVG (any size) or high resolution bitmap (1024×1024).
Following on from my post about websites in the dock, Trys upgraded to Sonoma and added a handy copy’n’paste resource to his dock. It works a treat.
Sit with that for a second, you can write a desktop application with no tooling, launch it from your phone to the internet for free, and seconds later install it on any computer. I didn’t have to ask permission, or jump through any App Store hoops. I wrote a thing, pushed it to the internet, and then I could use the thing. Even better, I could send the link to Chris and he could use the thing. That’s the power of the internet.