Maybe Progressive Enhancement is the Wrong Term
Many of the responses to my last article, Progressive Enhancement: Zed’s Dead, Baby, were that I “didn’t get” progressive enhancement.
So, maybe it is time to choose a new term that doesn’t carry with it the baggage of the past.
While I think that for many apps, it is an acceptable tradeoff, it clearly isn’t for many others, like Twitter.
Unfortunately, telling people to “just render the initial HTML on the server” is a bit like saying “it’s easy to end world hunger; just give everyone some food.” You’ve described the solution while leaving out many of the important details in the middle. Doing this in a sane way that scales up to a large application requires architecting your app in such a way that you can separate out certain parts, like data fetching and HTML rendering, and do those just on the server.
Once you’ve done that, you need to somehow transfer the state that the server used to do its initial render over to the client, so it can pick up where the server left off.
You can do this by hand (see Airbnb’s Rendr) but it requires so much manual labor that any application of complexity would quickly fall apart.
I’ve got bad news: Progressive enhancement is dead, baby. It’s dead. At least for the majority of web developers.
Mozilla prides itself on being a champion of the open web, and largely it is. But one policy continues to increasingly grate: their badly-managed add-on review program.