Weekly status of KL blog (1)

So I told you about the blog engine I wanted to write. I decided to go for an own-defined engine. There’s obviously no news – I was way too optimistic about the time available for my own work. But this will change, soon enough. And I’ll try to make some weekly status notes before I start opening up github repos.

So where am I with the implementation? I implemented a simple template engine, in which one can substitute easily things. Say you have a JSON configuration that describes the values, things like:

and a template file like:

you will have the proper replacements. This is schoolyard stuff. So basically, I have nothing, but nothing done in a very pretentious manner. I also started an execution context, in which you can have paths (author.name and author.email would happen as you would expect) and execution flows – for, if, all the good stuff. Again, schoolyard stuff, but fun to implement.

However, the technical problem I tackled, while satisfying in itself (it was fun creating my own JSON parser, for example, and it is fun to write your own interpreter for a language you define), does not get me any closer to what I really need. And what I need is a workflow. And while it’s easy to satisfy me (I could easily maintain a blog using just the tool I wrote for value parsing and value replacement, and a bit of HTML), I think the template tool is just that – a simple tool that should be used to satisfy a more complex workflow – one that makes it easy for a potential user, not just for me.

As a matter of fact, this is what I should’ve started with. And to make things right, I looked around to see what other static generators do. And from what I’ve seen they don’t have a very good workflow, the place where they all get stuck is „you edit a file and you must create it this way and that way, and it must be in this folder and you must X and you must Y”. Which is a fine workflow for someone who likes to edit HTML files, but that’s about it.

And one issue that’s not solved is content management. There is something for posts (text) but close to nothing about any other type of management. The solution for HTML text is not even original – most of them come with textile (which is HTML with less markup) or Markdown, which is a more natural format, easier to edit. Still, including content is a complicated thing. Embedding stuff is/can be hard, and while solutions exist, maintaining them is hard. Post management is passable, content management not really. I’m not sure if there is a good solution out there.

Most of the static site generators are basically clones of jekyll rewriting the same „Markdown to HTML” logic. Most if not all of them are dedicated to developers. They don’t want to work with the real users, they assume that there’s no market for static sites for normal users. And that’s fine, I guess, but I think this can be better.

Also most of these generators don’t come with a good backup workflow. „Use github” is not really a good backup solution, although I can see the charm in an hourly pull and regenerate site cycle. Still, it doesn’t feel like it’s enough.

Ok, so to sum up:

  • Text management is easy. Use Markdown or Textile, require some metadata to be filled by the user, everyone’s happy. I think this can be automated a bit more.
  • I haven’t seen a good solution for non-text content management. Not even WordPress does it right, and they work with a database and have any level of metadata they want, they still don’t know how to do it right.
  • Static sites are for developers and require you to know at least Markdown, HTML, JavaScript, rake/ruby/programming language of choice. And to be structured and rigurous in your approach.
  • Most static engines don’t take into account the possibility of having to search for stuff in 10 years of archives, and interaction with external content is limited (ie youtube embeds).

Eh, I think I can do better. But that was the whole point about starting this, right?

4 Replies to “Weekly status of KL blog (1)”

  1. Well, I must say you’ve properly identified the issue many users do face when trying to use static site generators or other templating engines: the “workflow”. I couldn’t really put my finger on it up until now, but I must agree this is what makes the end user feel somewhat inadequate when trying to learn & use one of the existing tools (I myself have been using Hugo for the last six months for a personal website – and yes, having to do with the software development world helped a lot!).

    This does sound really interesting. Make sure you post a Github link once you think the concept/idea can be shared with others.

    Cheers!

  2. @Dragos: there will be public github. There is a public repo (hint, a penguin and my own name is some simple way to identify me almost anywhere I have an account) with a few ideas I wrote down (but I have them spread in many places, the github doc only scratches the surface, and I’ll add to it slowly, as I make up my mind on „what’s definitive” and what isn’t. Anyway, with the 1st of May weekend I decided I need a break (I’ve been at full throttle for quite some time now), but afterwards I’ll have weekly updates.

Comentariul tău