bjornerik

The article in the top of this thread is interesting. I can just add that in Hugo we have tried to make it simple for the simple stuff, but also make the "harder stuff" possible. We have naming conventions for layout files to keep it DRY (to avoid having to set "layout: blog" or something in every content file (you can)) and we have some special meaning behind "index.md" and "_index.md" -- which among other things allows for a navigable and not so rigid content tree. We even have plans to, in near future, to extend that tree into the content files themselves (ToC, paragraphs, sections). We may have different trade-offs than the article writer: With many sections and thousands of files in a deeply nested content tree, Hugo's layout system its speed may make more sense. Or not. So we do try, but it is hard to make everyone happy. I'm bep on GitHub.

Agree.

bep (Hugo maintainer)

I am bep, the lead maintainer of Hugo. A plugin system will happen in Hugo, and I don't think it will take too long to get there -- we have been thinking about it for some time, and it feels natural to have that before we call it 1.0. CMS like editing is something that could live well outside of Hugo, me thinks.

One could also argue that developers also has some impact on speed in an app like Hugo. The measured speed increase from Hugo 0.16 was 40/60 Go vs Developer.

Steve Francia has written a nice blog article about the recent Hugo 0.17 release: http://spf13.com/post/hugo-goes-global/