Static Pages in Dynamic Web Apps
A Step Towards Efficiently Rendering Web Views
Quite a while ago, I wrote about different ways to render web views, and the efficiency of each way. I concluded that the most efficient and generally useful (and strangely absent) framework would be one that serves static files, all the while allowing the files to change after deployment, enabling dynamic content in static files.
As a step in the right direction, I built a simple blogging site that follows this principle: static-page-blog.
A clear distinction is made between views that many users will access (reading blog posts) and views that only a few will ever see (editing a blog post).
Contributing users are generally more stable than consuming ones: writing a blog post will more often happen from a stable connection, whereas reading a blog post is very likely to happen on-the-go. Mobile data is much less stable that WiFi, and that’s even before considering underground travel (metros, etc).
At the beginning of this post, I called static-page-blog a step towards better web frameworks. This is for two reasons: this project has taken no steps towards generalizing the model, which would be required for a framework; and there are several possible improvements on the model I used in this project.
The first, most glaring issue with this approach is that it does not support both dynamically and statically rendered pages (as originally defined as a problem, when I wrote about Efficiently Rendering Web Views).
Rendering what is needed (and nothing more) when it is needed (and not too early) is the central problem here. Some pages change more often than they are seen. Re-rendering on every change would be a waste.
The second issue is that modification requests will have long waits, as PHP does not allow for code-execution after a page has returned. There are two options for making all pages statically rendered, then: allow long requests and let the modifier wait, or run an often-running cron job that renders all modified pages.
The overhead of re-rendering only affects modifying users, in this case the author of the blog post, and was deemed acceptable for this project. It is not yet a solid, generally usable model, though.
- I also wrote briefly about the terminology of rendering web views.
- I also quickly learned that the name was misleading (it was confused with projects like Jekyll that do static file generation before deployment, but don’t allow for dynamically changing the content), but alas, I haven’t found a better name yet.