The Joys and Perils of Writing Plain Old Web Apps
<form> elements sending
POST requests, or adding search parameters to
GET requests. Servers respond with new documents and browsers display them.
Set-Cookie headers are used to let the client remember state, while a database can be used on the server side.
This is known as “Web 2.0”. It is a shockingly simple model that can still be used today, even without a framework. Really, all you need is to send some text to the browser.
While such apps might not quite rise the expectations of modern, mobile app-aware audiences, they trivially beat SPWAs in terms of memory consumption, energy efficiency, and reliability. The path to superior time to first byte, time to first paint, and time to interactive is also much clearer.
I’ve recently built just such an app, and I can say that I’m quite pleased with the result. Interestingly, I didn’t set out to write a Web 2.0 app, I’ve just wanted to quickly throw together a dashboard and things went from there. I expected this to be temporary; to be replaced by a full React app later on. Now I think I’m just going to keep the HTML version.
The Complexity of Single Page Web Apps
When combined with data fetching, modern SPWAs easily devolve into an exercise in ad-hoc distributed systems engineering. The need for ever more sophisticated “easy-to-use” libraries arises to help manage all this extra state and asynchronicity.
Writing Plain Old Web Sites can be an eye opener. You thought you needed all this complexity, but actually what you’re giving up is mostly cosmetic.
I’ve stated some benefits above, but there are more:
- Simplified data fetching — Pulling all the strings together in a central location before generating a single document is a simpler model than fetching from many sources at different times and updating the UI in patches
- No need for crazy build tool chains — The size of the Create React App tool chain is well known. Other frameworks take it a step further and introduce their own compiler, etc.
What You Lose
Obviously, most web apps cannot be built in this way. Anything with a high degree of interactivity, real-time, etc. is a very bad fit. As a rule of thumb, the closer an app resembles a series of documents, the better this model fits. This should not be surprise, given the origins of the web.
If there was a vibrant ecosystem of Web Components, some of the interactive capabilities could be added back, but this is purely hypothetical at this point. The available stock of Web Components is underwhelming, while all the best web components (lower case) are written in React.
Could There Be a Comeback of POWAs?
Probably not, but there are some trends that are helping:
Edge computing moves the server closer to the visitor, which reduces latency. I’ve used Cloudflare Workers for my dashboard, and response times can be crazy fast. More on that in an upcoming post.
There’s obviously precedent for “Everything Old is New Again” in user interface development, and React itself is an example of that. While a comeback for plain old web apps seems unlikely, crazier things have happened.
I’ve enjoyed writing a web app using pretend-1998 technology, and I’m looking forward to writing another one should a situation come up. At the same time, there’s still an obvious, battle-tested, and straight-forward choice for most web apps today, which is React.