Myself and my colleagues have spent the last two months working on TinaCMS, and have learned a lot along the way. We believe Tina is a novel solution for managing website content.
For one thing, as the title of this post mentions, "Tina is not a CMS". Our team also works on the Forestry.io CMS, so we know how to build one of those. As we embarked on the Tina project, we felt that another one-size-fits-all CMS wasn't the solution we wanted. This is why we architected Tina as a suite of libraries to enable frontend devs to quickly compose a more form-fitting content management strategy for their clients.
Another interesting innovation that we discovered along the way was that, by having the CMS live on your website instead of in a traditional CMS dashboard, the correlation between source content and rendered website becomes much more intuitive to those who were not involved in developing the website to begin with. With a traditional CMS, users must have some mental model of how their site is composed. They can ultimately figure out that, for example, they can change the homepage title by clicking on Settings > Homepage > Title or something like that, but requires some trial and error and a lot of implicit rules to remember. With Tina, the editor will edit the Homepage title while viewing the homepage; the information will tend to be where they're expecting it. And by having a short-feedback, on-page experience, even more esoteric rules will reveal themselves more intuitively.
We have been thrilled so far with the response to the public release of this project. We hope to continue to improve and extend the capabilities of TinaCMS, and I'd like to thank everyone who has expressed their enthusiasm and support!
I agree with the author that SSGs are tools written by developers for their own use. But what's great about the file-based, command-line-driven interface is that it's possible to hook the input side up to some more machinery if you want a GUI CMS.
I work for Forestry.io, and our product is a CMS that aims to ease the pain of non-developers managing content for static sites. We are committed to bridging the gap between copywriters and developers. I am a big believer in the potential for static sites to transform the web, but I realize there is a lot of ground left to cover.
Forestry.io is a CMS for static sites that includes a media management interface you might like[0].
We also support uploading images to Cloudinary instead of committing them to your git repo to prevent repo bloat.
Depending on what you're trying to do, a non-CMS option that will remove some of the tedium of inserting all these images is to take advantage of Hugo's Page Bundles feature[1]. With this you could just group a bunch of images in a folder and iterate over them in your templates.
I definitely think static sites are a great alternative to WP, and I love Markdown. But you're right: trying to get non-developer users to write markdown was a struggle, they thought it was some new special language we were forcing down their throat.
I work for https://forestry.io/ and we created a CMS for static sites that lets users write markdown with a WYSIWYG editor, and allows devs to build an interface for editing front matter.
I definitely agree. The point I wanted to make here is that setting up replication for a static site is trivial due to their static/stateless nature (you can just use a CDN.) These same qualities make distributing a static site over IPFS easy to do too.
We've gotten several comments about that "beginner-friendly" quip! Installing Hugo is indeed much easier than Jekyll, but I personally find Jekyll's barrier to entry a bit lower. This owes mostly to the built-in Sass processing, the Liquid templating language, and the absence of a required file structure (this last point can be a detriment at times, but the parity between source files and rendered files is more intuitive.)
This is clearly a matter of opinion; personally, I find Go's templating syntax to be a bit more esoteric at first. This will likely depend on prior experience, as it does in your case. I have grown to love Go templates, and Hugo is my go-to for new projects.
Thanks for reading and for your feedback! I will amend the supported markup languages list.
For one thing, as the title of this post mentions, "Tina is not a CMS". Our team also works on the Forestry.io CMS, so we know how to build one of those. As we embarked on the Tina project, we felt that another one-size-fits-all CMS wasn't the solution we wanted. This is why we architected Tina as a suite of libraries to enable frontend devs to quickly compose a more form-fitting content management strategy for their clients.
Another interesting innovation that we discovered along the way was that, by having the CMS live on your website instead of in a traditional CMS dashboard, the correlation between source content and rendered website becomes much more intuitive to those who were not involved in developing the website to begin with. With a traditional CMS, users must have some mental model of how their site is composed. They can ultimately figure out that, for example, they can change the homepage title by clicking on Settings > Homepage > Title or something like that, but requires some trial and error and a lot of implicit rules to remember. With Tina, the editor will edit the Homepage title while viewing the homepage; the information will tend to be where they're expecting it. And by having a short-feedback, on-page experience, even more esoteric rules will reveal themselves more intuitively.
We have been thrilled so far with the response to the public release of this project. We hope to continue to improve and extend the capabilities of TinaCMS, and I'd like to thank everyone who has expressed their enthusiasm and support!