Now that I’ve spent a good deal of time learning about what’s hot in the front-end area, I can go back to my initial goal: renew this Website.. or maybe I can fool around some more? :) In this post, I’ll describe the idea that I’ve got in mind.
One thing that’s been bothering me for a while is the dependency that I currently have on WordPress, PHP and a MySQL database. Of course there are pros and cons to consider, but currently I’m inclined to ditch WordPress, PHP and MySQL in favor of a static site.
Static site generators like Hugo (one of the most popular options at the moment) let you edit your content using flat files (e.g., using Markdown) with a specific folder structure. Once your content is ready for publication, you have to use a CLI/build tool that takes your content (e.g., posts, pages, …) and mixes it with a template.
Once the build is completed, you can upload the output on your Web host; no need for a database, no need for a server-side language, no need for anything more than a good old Apache Web server (or any Web server flavor you like). Neat!
Now what I’m wondering is: can we go further? What if we could create doubly static static sites? :)
Here’s the gist of my idea:
First, we can edit/maintain the content in the same way as with Hugo: through a specific folder structure with flat files. Of course we can add any feature we’d like around that: front matter, variables & interpolation, content editor, … For all that a build/CLI should be useful.. more on that later.
Note that the content could be hosted on GitHub or a similar platform to make the editing/publishing workflow simpler/nicer.
So, we’ve got static content, cool. What else? Well now what if we added a modern client-side Web application able to directly load those flat files and render them nicely?
If we have that then we could upload the static content to any Web host and have that modern Web app load the content directly from the client’s Web browser. The flow would thus be:
- go to https://www.dsebastien.net
- receive the modern Web app files (HTML, CSS, JS)
- the modern Web app initializes in my Web browser
- the modern Web app fetches the static content (pages, posts, …)
- the modern Web app renders the content
Ok, not bad but performance could be an issue! (let’s ignore security for a moment ok? :p).
To work around that, we could imagine loading multiple posts at once and caching them.
If we have a build/CLI could also pack everything together so that the Web app only needs to load a single file (let’s ignore the HTTP 1.1 vs HTTP 2.0 debate for now).
In addition, we could also apply the ‘offline-first’ idea: put pages/posts in local storage on first load; the benefit would be that the application could continue to serve the content offline (we could combine this with service workers).
The ideas above partially mitigate the performance issue, but first render would still take long and SEO would remain a major problem since search engines are not necessarily great with modern client-side Web apps (are they now?). To fix that, we could add server-side rendering (e.g., using Angular Universal).
Server-side rendering is indeed nice, but it requires a specific back-end (let’s assume node). Personally I consider this to be a step back from the initial vision above (i.e., need for a server-side language), but the user experience is more important. Note that since dedicated servers are still so pricey with OVH, it would be a good excuse to go for DigitalOcean.. :)
Another important issue to think about is that without a database, we don’t have any way to make queries for content (e.g., search a keyword in all posts, find the last n posts, …). Again, if we have a build/CLI, then it could help work around the issue; it could generate an index of the static content you throw at it.
The index could contain results for important queries, post order, … By loading/caching that index file, the client-side Web app could act more intelligently and provide advanced features such as those provided by WordPress and WordPress widgets (e.g., full text search, top n posts, last n posts, tag cloud, …).
Note that for search though, one alternative might be Google Search (or Duck Duck Go, whatever), depending on how well it can handle client-side Web apps :)
In addition, the build/CLI could also generate content hashes. Content hashes could be used to quickly detect which bits of the content are out of date or new and need to be synchronized locally.
There you have it, the gist of my next OSS project :)
I’ll stop this post here as it describes the high level idea and I’ll publish some additional posts to go more in depth over some of the concepts presented above.