François Nonnenmacher (EN) | FR

Previously on: The trouble with dynamic publishing.
Upcoming next: Let's dream!

Reinventing the wheel

Those same developers who dismissed static publishing as out, were starting to feel le vent du boulet. More and more people were coming to bother them about pesky cache and performance issues. They suddenly re-discovered the benefits of serving static files.

Very quickly, the traditional “Hello World!” first exercice when playing with a new language turned into writing your own static site generator, crunching Markdown files because HTML is still out for some reason (after all, we are talking about people who never use a rich text editor, live in a code editor and see no problem generating HTML and CSS with JavaScript, there is some logic here).

But they stopped at “here are some markdown files with fancy front matter, mix that with a few templates accompagnied with a toml/yaml soup and voilà, problem solved!”

This is why we now have a gazillion Static Site Generators made by developers, for their own benefit (et encore), as an exercize to learn new languages.

Markdown-eating Static Site Generators are a niche inside a niche.
They are not about managing content. They are about turning files in a directory tree of files into the a similar hierarchy of files ready to serve, with very little possibilities of developping a more complex one besides iterating along taxonomies.
This is the familiar setting for a developper. Not so much for everyone else. This is also why the SSG-powered sites lying around are mostly software or API documentations made by developers for other developers.

And then comes another layer above that.

Because SSGs are, to make an understatement, not made for content editors, here comes a flurry of web frontends that try to hide Markdown (if you're lucky to have a WYSIWYG preview), show the metadata in a decent way into form fields (with the extra benefit of some validation which you don't have if you edit the source directly), and isolate the rest of us of the jargon and complexity of git (no normal person would naturally understand “commit, MR, merge” as “save, ask for review, publish”, nor should they have to).

And that market is in a sorry state. Just look at the Front ends to Hugo. All are abandonned, not supported, or too complex to integrate for too few advantages to bother. And the commercial alternatives have pretty much all opted for the Very Bad Idea™ of forcing one to put themselves and their content into the hands of an external company somewhere in this fuzzy cloud.

I'll let you read this and picture yourself learning one day that you cannot edit your own web site anymore.

A Very Bad Idea™, indeed.

The best tool I have found so far is a plugin for VS Code. There is no escaping the Mordor furnaces SSGs were born into. I could swear it is a conspiracy to turn everybody into a git-loving developer (this one will cost me some karma points :-)

Some light at the end of the tunnel?

I see some recent progress with people who understand that content management is for content editors who need a content management system that allows them to do way more than organizing text files and a few images in folders, and that publishing content on the web is something different, that can be separated from the CMS (or at least intelligently articulated together). For example, a CMS might benefit from using a database, while the published site has no need for it.

And these content editors want to be able to manage their taxonomies, media, menus, styles, specialized blocks, semantic content, accessibility, forms, URLs, SEO, publishing process, moderation etc. as well as search and manipulate them in a web browser, anywhere, anytime. Some even want a Rich Text editor experience (how dare they?). And all this without having to pay for a specialized developer constantly on call anytime they add a new content type. For the most part of the life of their sites, they might sometimes need to work with web designers on styles and layout, again without having to add a developer in the loop at each time.

As I mentionned in the first part, Movable Type has been doing this since 2000, and even offers the ability to publish both static and dynamic pages on the same site. Unplug the database and MT, the site works just fine with a simple web server.

Enough for the snarky rant. Let's dream a little!

(To be continued…)

Previously on: The trouble with dynamic publishing.
Upcoming next: Lets dream!