So if AMP is useful it’s because it raises the stakes. If we (news developers) don’t figure out faster ways to load our pages for readers, then we’re going to lose a lot of magic.
A number of developers answered questions on the potential effects of Google’s AMP project. This answer resonates a lot with my own feelings:
AMP is basically web performance best practices dressed up as a file format. That’s a very clever solution to what is, at heart, a cultural problem: when management (in one form or another) comes to the CMS team at a news organization and asks to add more junk to the site, saying “we can’t do that because AMP” is a much more powerful argument than trying to explain why a pop-over “Like us on Facebook!” modal is driving our readers to drink.
But the danger is that AMP turns into a long-term “solution” instead of a stop-gap:
So in a sense, the best possible outcome is that AMP is disruptive enough to shake the boardroom into understanding the importance of performance in platform decisions (and making the hard business decisions this demands), but that developers are allowed to implement those decisions in standard HTML instead of adding yet another delivery format to their export pipeline.
Paul takes a look at the year ahead on the web and likes what he sees. There’s plenty of new browser features and APIs of course, but more interesting:
The web reaching more people as they come online with Mobile. There is still a huge amount of potential and growth in India, Indonesia, China, Thailand, Vietnam, all of Africa. You name it, mobile is growing massively still and the web is accessible on all of these devices.
A run-down of all the functionality that you get in browsers these days. One small quibble with the title: most of the features and APIs described here aren’t limited to mobile browsers. Still, this is a great reminder that you probably don’t need to create a native app to get the most out of a mobile device.
There’s a whole category of native apps that could just as easily be described as “artisanal web browsers” (and if someone wants to write a browser extension that replaces every mention of “native app” with “artisanal web browser” that would be just peachy).
Here’s some more thoughts along the same lines:
We’re spending increasing amounts of time inside messaging apps and social networks, themselves wrappers for the mobile web. They’re actually browsers.
There’s an important take-away to this:
The web is and will always be the most popular mobile operating system in the world – not iOS or Android. It’s important that the next generation of software companies don’t focus exclusively on building native iOS or Android versions of existing web apps.
Just make sure those web apps render and work well in the new wave of mobile browsers – messengers. Don’t build for iOS or Android just for an imaginary distribution opportunity. Distribution exists where people spend most of their time today – social and messaging apps, the new mobile browser for a bot-enabled world.
Henrik points to some crucial information that slipped under the radar at the Chrome Dev Summit—the Android OS is going to treat progressive web apps much more like regular native apps. This is kind of a big deal.
It’s a good time to go all in on the web. I can’t wait to see what the next few years bring. Personally, I feel like the web is well poised to replace the majority of apps we now get from app stores.
Every front-end developer at Clearleft went to FFConf last Friday: me, Mark, Graham, Charlotte, and Danielle. We weren’t about to pass up the opportunity to attend a world-class dev conference right here in our home base of Brighton.
Normally FFConf would be a good opportunity to catch up with some Pauls from the Google devrel team, but because of an unfortunate scheduling clash this year, all the Pauls were at Chrome Dev Summit 2016 on the other side of the Atlantic.
I’ve been catching up on the videos from the event. There’s plenty of tech-related stuff: dev tools, web components, and plenty of talk about progressive web apps. But there was also a very, very heavy focus on performance. I don’t just mean performance at the shallow scale of file size and optimisation, but a genuine questioning of the impact of our developer workflows and tools.
He makes the point that if you really want fast rendering, nothing on the client side quite beats a server render.
Unfortunately, all too often, I hear people say that a progressive web app must be a single page app. And I am not so sure. You might not need a single page app. A single page app can end up being a lot of work and slower. There’s a lot of cargo-culting around single page apps.
As Benedict Evans has noted, the next billion people who are poised to come online will be using the internet almost exclusively through smartphones. And if Google’s plans with Android One are any indication, then we have a fairly good idea of what kind of devices the “next billion” will be using:
They’ll mostly be running Android.
They’ll have decent specs (1GB RAM, quad-core processors).
They’ll have an evergreen browser and WebView (Android 5+).
What they won’t have, however, is a reliable internet connection.
Assumptions are the problem. Whether it’s assumptions about screen size, assumptions about being able-bodied, assumptions about network connectivity, or assumptions about browser capabilities, I don’t think any assumptions are a safe bet. Now you might quite reasonably say that we have to make some assumptions when we’re building on the web, and you’d be right. But I think we should still aim to keep them to a minimum.
It’s not necessarily true that all those new web users will be running WebView browser like Chrome—there are millions of Opera Mini users, and I would expect that number to rise, given all the speed and cost benefits that proxy browsing brings.
I also don’t think that just because a device is a smartphone it necessarily means that it’s a pocket supercomputer. It might seem like a reasonable assumption to make, given the specs of even a low-end smartphone, but the specs don’t tell the whole story.
It’s not enough to talk about the “next billion” in abstract, like an opportunity to reach teeming masses of people ripe for monetization. We need to understand their lives and their priorities with the sort of detail that can build empathy for other people living under vastly different circumstances.
Finally! Apple are being sued for refusing to allow any non-Webkit browsers to be installed on iOS.
I’m not usually in favour of legal action but in this case, there doesn’t seem to be any other recourse.
We would be delighted at Nexedi to create a Web browser for iOS with better HTML5 support based on a recent version of Blink library for example. But as soon as we would publish it, it would be banned from Apple’s AppStore. Many developers have experienced this situation already. Many companies are being hurt by this situation. Some companies have already begged Apple to improve HTML5 support in iOS with little significant results.
AMP loads super, super quickly and is simply a better experience right now. So can we add enough design to make an AMP page feel like The Verge?
What a depressing conclusion! But I guess it’s easier than, y’know, actually fixing the bloated Verge website, packed with megabytes and megabytes of invasive trackers. It’s no wonder people prefer the AMP experience. Yet the idea of improving the website isn’t even raised in this whole article.
This is what tells all our browsers on all our devices to set the viewport to be the same width of the current device, and to also set the initial scale to 1 (not scaled at all). This essentially allows us to have responsive design consistently.
The viewport value for the meta element was invented by Apple when the iPhone was released. Back then, it was a safe bet that most websites were wider than the iPhone’s 320 pixel wide display—most of them were 960 pixels wide …because reasons. So mobile Safari would automatically shrink those sites down to fit within the display. If you wanted to over-ride that behaviour, you had to use the meta viewport gubbins that they made up.
That was nine years ago. These days, if you’re building a responsive website, you still need to include that meta element.
That seems like a shame to me. I’m not suggesting that the default behaviour should switch to assuming a fluid layout, but maybe the browser could just figure it out. After all, the CSS will already be parsed by the time the HTML is rendering. Perhaps a quick test for the presence of a crawlbar could be used to trigger the shrinking behaviour. No crawlbar, no shrinking.
Maybe someday the assumption behind the current behaviour could be flipped—assume a website is responsive unless the author explicitly requests the shrinking behaviour. I’d like to think that could happen soon, but I suspect that a depressingly large number of sites are still fixed-width (I don’t even want to know—don’t tell me).
There are other browser default behaviours that might someday change. Right now, if I type example.com into a browser, it will first attempt to contact http://example.com rather than https://example.com. That means the example.com server has to do a redirect, costing the user valuable time.
You can mitigate this by putting your site on the HSTS preload list but wouldn’t it be nice if browsers first checked for HTTPS instead of HTTP? I don’t think that will happen anytime soon, but someday …someday.
Progressive Web Apps versus native is the wrong question because every step on the path to a Progressive Web App makes sense on its own, irrespective of what a company does with their native apps.
Not all of your customers are going to have your app installed. For those who visit via the web, providing them with a better experience will make them happier and generate more revenue for your business.
It’s always, um …”interesting” when a mainstream publication covers a topic from the web’s bikeshed. In this case, it’s progressive web apps, and—apart from the sensationalist headline—it’s actually not that bad at all.
Start by forgetting everything you know about conventional web design, and instead imagine you’re actually designing a native app.
This makes me squirm. I mean, I’m all for borrowing good ideas from other media—native apps, TV, print—but I don’t think that inspiration should mean imitation. For me, that always results in an interface that sits in a kind of uncanny valley of being almost—but not quite—like the thing it’s imitating.
With that out of the way, most of the recommendations in Owen’s article are sensible ideas about animation, input, and feedback. But then there’s recommendation number eight: Provide an easy way to share content:
PWAs are often shown in a context where the current URL isn’t easily accessible, so it is important to ensure the user can easily share what they’re currently looking at. Implement a share button that allows users to copy the URL to the clipboard, or share it with popular social networks.
Anyway, I think my squeamishness about all the advice to imitate native apps is because it feels like a cargo cult. There seems to be an inherent assumption that native is intrinsically “better” than the web, and that the only way that the web can “win” is to match native apps note for note. But that misses out on all the things that only the web can do—instant distribution, low-friction sharing, and the ability to link to any other resource on the web (and be linked to in turn). Turning our beautifully-networked nodes into standalone silos just because that’s the way that native apps have to work feels like the cure that kills the patient.
If anything, my advice for building a progressive web app would be the exact opposite of Owen’s: don’t forget everything you’ve learned about web design. In my opinion, the term “progressive web app” can be read in order of priority:
Progressive—build in a layered way so that anyone can access your content, regardless of what device or browser they’re using, rewarding the more capable browsers with more features.
Web—you’re building for the web. Don’t lose sight of that. URLs matter. Accessibility matters. Performance matters.
App—sure, borrow what works from native apps if it makes sense for your situation.
Will people expect an experience that maps to native conventions? Or will they be more accepting of deviation because they came to the app via the web and have already seen it before installing it?
These are good questions and I share Jason’s hunch:
My gut says that we can build great experiences without having to make it feel exactly like an iOS or Android app because people will have already experienced the Progressive Web App multiple times in the browser before they are asked to install it.
In all the messaging from Google about progressive web apps, there’s a real feeling that the ability to install to—and launch from—the home screen is a real game changer. I’m not so sure that we should be betting the farm on that feature (the offline possibilities opened up by service workers feel like more of a game-changer to me).
People have been gleefully passing around the statistic that the average number of native apps installed per month is zero. So how exactly will we measure the success of progressive web apps against native apps …when the average number of progressive web apps installed per month is zero?
I like Android’s add-to-home-screen algorithm (although it needs tweaking). It’s a really nice carrot to reward the best websites with. But let’s not carried away. I think that most people are not going to click that “add to home screen” prompt. Let’s face it, we’ve trained people to ignore prompts like that. When someone is trying to find some information or complete a task, a prompt that pops up saying “sign up to our newsletter” or “download our native app” or “add to home screen” is a distraction to be dismissed. The fact that only the third example is initiated by the operating system, rather than the website, is irrelevant to the person using the website.
My hunch is that the majority of people will still interact with your progressive web app via a regular web browser view. If, then, only a minority of people are going to experience your site launched from the home screen in a native-like way, I don’t think it makes sense to prioritise that use case.
The great thing about progressive web apps is that they are first and foremost websites. Literally everyone who interacts with your progressive web app is first going to do so the old-fashioned way, by following a link or typing in a URL. They may later add it to their home screen, but that’s just a bonus. I think it’s important to build progressive web apps accordingly—don’t pretend that it’s just like building a native app just because some people will be visiting via the home screen.
I’m worried that developers are going to think that progressive web apps are something that need to built from scratch; that you have to start with a blank slate and build something new in a completely new way. Now, there are some good examples of these kind of one-off progressive web apps—The Guardian’s RioRun is nicely done. But I don’t think that the majority of progressive web apps should fall into that category. There’s nothing to stop you taking an existing website and transforming it step-by-step into a progressive web app:
Switch over to HTTPS if you aren’t already.
Use a service worker, even if it’s just to provide a custom offline page and cache some static assets.
Make a manifest file to point to an icon and specify some colours.
See? Not exactly a paradigm shift in how you approach building for the web …but those deceptively straightforward steps will really turbo-boost your site.
I’m really excited about progressive web apps …but mostly for the “progressive” and “web” parts. Maybe I’ll start calling them progressive web sites. Or progressive web thangs.