A lot of the talks at this year's Chrome Dev Summit were about progressive web apps. This makes me happy. But I think the focus is perhaps a bit too much on the "app" part on not enough on "progressive".
What I mean is that there's an inevitable tendency to focus on technologies—Service Workers, HTTPS, manifest files—and not so much on the approach. That's understandable. The technologies are concrete, demonstrable things, whereas approaches, mindsets, and processes are far more nebulous in comparison.
Still, I think that the most important facet of building a robust, resilient website is how you approach building it rather than what you build it with.
Many of the progressive app demos use server-side and client-side rendering, which is great ...but that aspect tends to get glossed over:
Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering, but this is only one of many options.
I think it's vital to not think in terms of older browsers "falling back" but to think in terms of newer browsers getting a turbo-boost. That may sound like a nit-picky semantic subtlety, but it's actually a radical difference in mindset.
Many of the arguments I've heard against progressive enhancement—like Tom's presentation at Responsive Field Day—talk about the burdensome overhead of having to bolt on functionality for older or less-capable browsers (even Jake has done this). But the whole point of progressive enhancement is that you start with the simplest possible functionality for the greatest number of users. If anything gets bolted on, it's the more advanced functionality for the newer or more capable browsers.
So if your conception of progressive enhancement is that it's an added extra, I think you really need to turn that thinking around. And that's hard. It's hard because you need to rewire some well-engrained pathways
There is some precedence for this though. It was really, really hard to convince people to stop using tables for layout and starting using CSS instead. That was a tall order—completely change the way you approach building on the web. But eventually we got there.
When Ethan came out with Responsive Web Design, it was an equally difficult pill to swallow, not because of the technologies involved—media queries, percentages, etc.—but because of the change in thinking that was required. But eventually we got there.
These kinds of fundamental changes are inevitably painful ...at first. After years of building websites using tables for layout, creating your first CSS-based layout was demoralisingly difficult. But the second time was a bit easier. And the third time, easier still. Until eventually it just became normal.
Likewise with responsive design. After years of building fixed-width websites, trying to build in a fluid, flexible way was frustratingly hard. But the second time wasn't quite as hard. And the third time ...well, eventually it just became normal.
So if you're used to thinking of the all-singing, all-dancing version of your site as the starting point, it's going to be really, really hard to instead start by building the most basic, accessible version first and then work up to the all-singing, all-dancing version ...at first. But eventually it will just become normal.
For now, though, it's going to take work.
The recent redesign of Google+ is true case study in building a performant, responsive, progressive site:
With server-side rendering we make sure that the user can begin reading as soon as the HTML is loaded, and no JavaScript needs to run in order to update the contents of the page. Once the page is loaded and the user clicks on a link, we do not want to perform a full round-trip to render everything again. This is where client-side rendering becomes important — we just need to fetch the data and the templates, and render the new page on the client. This involves lots of tradeoffs; so we used a framework that makes server-side and client-side rendering easy without the downside of having to implement everything twice — on the server and on the client.
This took work. Had they chosen to rely on client-side rendering alone, they could have built something quicker. But I think it was worth laying that solid foundation. And the next time they need to build something this way, it's going to be less work. Eventually it just becomes normal.
But it all starts with thinking of the server-side rendering as the default. Server-side rendering is not a fallback; client-side rendering is an enhancement.
That's exactly the kind of mindset that enables Jack Franklin to build robust, resilient websites:
Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.
I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. Server-side rendering was the default; client-side rendering was added later.
The key to building modern, resilient, progressive sites doesn't lie in browser technologies or frameworks; it lies in how we think about the task at hand; how we approach building from the ground up rather than the top down. Changing the way we fundamentally think about building for the web is inevitably going to be challenging ...at first. But it will also be immensely rewarding.
This was originally posted on my own site.