I love this thread. It’s great to see the passion that everyone has for this project.
I think about 1.0 a bit differently. For me 1.0 is the milestone when we have a stable foundation. This means that we are happy with our data model and interface. I think far too often people release 1.0 long before things are stable. It took us thousands of users to recognize that our node implementation isn’t as flexible as we need it to be.
In my eyes, as soon as we have this stable foundation we can release 1.0 and then a lot of awesome things can be layered on top of it with point releases.
As I’m thinking about it today there are four things that we need to improve to get to a stable foundation.
1. Nodes.
Initially as I designed Hugo I thought that a lot of the way other CMS / SSGs designed their content data model was backwards or broken. Wordpress has everything as a post… then non post things are oddly hacked in. Jekyll is similar but has posts and then dedicated static pages. These make sense given their blog specific roots, but are not a solid foundation for a full content CMS. Drupal has dynamic (almost object oriented) approach to their content model where the base is a Node and Pages and other content extend the base. I took inspiration from this approach and used similar terminology. In Hugo content would be created by the author and nodes would be created by Hugo. I also made the decision that content should live where it wants to live… meaning /content/post/foo.md becomes /post/foo.html. This proved to be a very friendly and intuitive interface for creating content. It was the right interface because it catered to the creator of the content, not the generator.
Now we have learned that this foundation has a few holes in it. People want to be able to have some content on their site that’s hidden from lists. People want to be able to not only define the layout of their taxonomy and other node pages, but provide content for them as well. In essence a lot of the functionality that was in the content layer needs to move down into the node layer. The technical challenges aren’t too hard, but the interface design is tougher. I’m still not sure how to make it so that a given file translates into a node and not content. I’ve thought of a few things here and would love to brainstorm with others on it so we come up with the right solution.
2. Localized content & assets
If I was going to design Hugo today I would do it a bit differently. I would have a post be represented by a directory and a set of files in that directory. Front matter is a novel idea, but it really stems from the concept that a single file represents the entirety of content. In practice a post is often made up of metadata, content (which sometimes spans multiple pages), and media. While the current approach of separating /static and /content makes a lot of sense in a general way… for things like sitewide assets like CSS & JS, it becomes a bit laborous to manage post assets independently of the content.
It would be really nice to be able to have something like
/content/post/foo/
-> content.md
-> metadata.yml
-> headerimage.png
-> picture.png
This is a very flexible approach that opens a lot of possibilities (multiple pages of content, multiple languages, etc).
The challenge is how do we unify this approach with the current approach of a file representing the entirety of the post.
3. Better asset handling
I’m not sure what this looks like. Fundamentally it’s a framework which allows for things like image processing, css preprocessing, etc.
I don’t want to rebuild gulp or similar systems, but I’d like to be able to allow for these kind of operations to happen within the context of Hugo.
4. Partial building.
This has been a long asked for feature. It’s hard to do and to date we’ve focused on making Hugo fast enough that it’s often not an issue. It becomes more of an issue when Hugo starts leaning on 3rd party applications to do things more as these tend to be significantly slower than Hugo itself.
I’ve given this a lot of thought and I believe I have a good model for how this can work and in a pretty simple and straightforward way. I believe that the approach that others have taken of trying to discover what needs to be rendered by examining a rendered site is fundamentally broken and at our current speed would actually be slower than Hugo is today. I think by leveraging the watch system we can implement a partial render in a very efficient way by tracking each file that changes and marking all associated content as dirty. Then in the render stage we can limit the processing to only dirty content.
For strictly static content this complexity isn’t needed and there’s already a very straightforward PR on improving the static file copy to only examine the changed file when watching. https://github.com/spf13/hugo/pull/1671
I believe this is it from me.
Reply to other suggestions
To respond to other suggestions in this thread.
native i18n and l10n support is very important. I don’t understand it well enough to suggest I can really qualify what needs to happen here. Luckily Hugo has a lot of bi-lingual developers who this affects significantly. I believe that my #2 point could be a part of this.
Could happen before or after 1.0:
- easier deployment
- related posts
- easier migration
- write JSON
- Go implementation of AsciiDoc, ReST, etc
- template functions
- revamped docs / website
I hope they all happen ASAP, but we are a community of volunteers each having their own motivation and focus so they will happen when someone feels motivated to do it. I don’t see any of these being predicated on 1.0 or blocking the 1.0 release as none would have breaking changes to the interface or foundation.