The Joys and Perils of Writing Plain Old Web Apps
In the age of “cybernetically enhanced” JavaScript frameworks, it’s easy to forget that you can still write web sites like it’s 1998.
In the age of “cybernetically enhanced”1 JavaScript frameworks, it’s easy to forget that you can still write web sites like it’s 1998. They consist of HTML and CSS and interactivity comes from <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.
“JavaScript fatigue” is wearing out developers and they might be inclined to look back to a simpler time. They will find it in POWAs, but not without losing many capabilities (see above)
The ad industry. The use of ad blockers is already prevalent. What if web users took it a step further and started disabling JavaScript altogether? Many websites no longer work without JavaScript, but those that do usually have their usability improved. For some publications, disabling JavaScript effectively circumvents the pay wall.
Apple. It would be a very Apple thing to do to give user an easy option to disable JavaScript. It would be called “Enhanced Privacy Mode” or “Request permission to execute untrusted code”. If you think that would never happen, remember the history of Adobe Flash.
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.
