Paul goes into detail describing how he built a progressive web app that’s actually progressive (in the sense of “enhancement”). Most of the stuff about sharing code between server and client goes over my head, but I understood enough to get these points:
Phil describes the process of implementing the holy grail of web architecture (which perhaps isn’t as difficult as everyone seems to think it is):
I have been experimenting with something that seemed obvious to me for a while. A web development model which gives a pre-rendered, ready-to-consume, straight-into-the-eyeballs web page at every URL of a site. One which, once loaded, then behaves like a client-side, single page app.
Now that’s resilient web design!
Remy wants to be able to apply progressive enhancement to React: server-side and client-side rendering, sharing the same codebase. He succeeded, but…
In my opinion, an individual or a team starting out, or without the will, aren’t going to use progressive enhancement in their approach to applying server side rendering to a React app. I don’t believe this is by choice, I think it’s simply because React lends itself so strongly to client-side, that I can see how it’s easy to oversee how you could start on the server and progressive enhance upwards to a rich client side experience.
I’m hopeful that future iterations of React will make this a smoother option.
I haven’t made a website with React, but if and when I do, this Node.js framework looks like it aligns nicely with my priorities. It’s all about the universal JavaScript (the artist formerly known as isomorphic JavaScript).
Here’s a fantastic and free little book by Adam Scott. It’s nice and short, covering progressive enhancement, universal JavaScript, accessibility, and inclusive forms.
Download it now and watch this space for more titles around building inclusive web apps, collaboration, and maintaining privacy and security.
Did I mention that it’s free?
I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:
- The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
- In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
- The next time a user clicks, rather than being sent to the server, the client-side app is in control.
- If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.
YES!!!
Y’know, 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. I think that points to a crucial mindset that’s reiterated here:
Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.
Many believe we should leave the term “progressive enhancement” behind and start anew, but why not educate developers, clients and stakeholders and change many of the misconceptions surrounding it? Changing the name won’t change anything unless we address the real fundamental problems we have when describing the underlying concepts.
I think we can all agree that “isomorphic JavaScript” is a terrible name for a good idea. I quite like calling it “portable JavaScript”, but here’s a good case for calling it “progressive JavaScript.”
(Right up until the end when the author says “But mainly, it’s pretty safe to assume JavaScript will just work. Everywhere.” …which is precisely the kind of unfounded assumption that leads to the very problems that isomorphic/portable/progressive JavaScript can help fix.)
I like the thinking behind this isomorphic JavaScript library: start with the (Node.js) server and then take over on the client side after the initial page load.
Progressive enhancement with isomorphic JavaScript, as practiced at Government Digital Services.
A nice tale of progressive enhancement from gov.uk, talking about how they made their analytics dashboards (which are public, by the way) using JavaScript on the server and on the client.
I believe this is what the kids are calling isomorphic JavaScript.