But, no demo anywhere?
A thing that most other developers miss is that non-technical people, like (and especially) content creators, shy away from a terminal as if it were such a plague.
Some of them don't even have the mind concept of a directory tree, from a root drive to nested ones.
Therefore, if you have to `cd` to a directory and then `npm run build` it, yeah: the CMS is developer-oriented no matter what you claim. Once your Windows customer tries to run that command (assuming they know what `cmd.exe` is) they'll run into `'npm' is not recognized as an internal or external command, operable program or batch file.`. If it's a Linux person, they may find `node` and `npm` installed, but then it's closer to a developer than the pure content creator this is trying to target.
These products seriously need to compete with the 5-minute WordPress installation. I'm no WP fan, I really don't, but I give credit to its low-friction onboarding.
> Aether stores everything as Markdown files with YAML frontmatter.
Yeah, just like GravCMS[0]. Full disclosure: I'm a Grav user.
Except that Grav has a web admin interface: now, that is more approachable to a non-technical content creator than typing commands in a terminal.
I really don't want to make my comment feel like a rant, but it's very hard to ignore that some devs entirely miss the target public they intend to approach.
--
[0]: https://getgrav.org/
The static site is optional, you can send to use the web interface if inclined.
But my point still stands, I checked the repo and this is too advanced[0] for anyone not a developer.
--
[0]: https://github.com/LebCit/aether-cms?tab=readme-ov-file#-dep...
(And the dirty secret is that, for a great many npm-based tools at least, nodejs/npm isn't actually required, and programmers could be writing and distributing them as a simple browser-based app.html (or whatever) instead, by targeting standardized, widely supported APIs that have been around since the days of HTML5—instead of The NPM Way of targeting NodeJS's proprietary stuff that changes/breaks all the time—but they choose not to. <https://news.ycombinator.com/item?id=41481714>)
In fact, YAML is pretty hard to use to be advertised as user-friendly[0] front matter that can be edited by hand.
--
I would even say vanilla Wordpress without plugins isn’t a CMS, even though it does come close. It’s more like a blog management system with some extra bells and whistles.
Wordpress is really more of a blog management system with page editing features. It doesn’t work well with different types of content, it’s geared for articles and ”pages”. How would you use it to build a site where a lot of content comes from some other background system, say NewsML feeds for example? It is possible, but you can only import the content as posts, and you only have one schema for what a post contains.
And I'm afraid your definition of a CMS is your own, and not the consensus. A CMS doesn't need to consume external sources, it can be self contained content.
A Markdown editor in an admin UI does not promote the system to a CMS, although I could be skewed towards enterprise systems here…
More super powers for me then!
Next, optimising themes and hardening security add another layer of complexity, let alone learning Full-site editing.
There are many questions posted daily on r/Wordpress ("p" in lower case because they can't fix it on Reddit) — some users are able to fix the issues themselves, while others seek help. So WordPress has never been easier than using a modern static site generator (SSG).
The terminal isn't that hard — what's harder is that there’s more than one way to run it.
The "sweet spot" really depends on the use case. If you're wanting to give content control to folks that couldn't write HTML, or to folks that want to quickly update what content flows into pre-built structure, almost any headless CMS will do. In my case, I need a CMS that can do this:
* Schedule content release * Preview content in the actual pages * Store drafts
I hate to say it but, Drupal can do all of that. I hate Drupal. I've considered writing my own but got no further than a save/read set of endpoints. (https://github.com/nobleach/cobaltcms) Who has time to write yet another headless CMS??
Clearly, a CMS is something more, geared for arbitrary ”content management” instead of being a ”UI for a database” or an ”editor for web pages”.
radical 20+ years ago, maybe
I basically just want a simple Web UI I can give my marketing team to let them create content that will be rendered using the main hugo templates.
To summarize my reservations, this lacks custom post types, meta fields or modules, and a full deployment story.
Although I can picture it, I think the author would get a lot more traction if they demonstrated how users might serve the generated content. It also feels odd to have to do so manually. Realistically this requires some kind of CI script, or, if attempting to expose to content editors, a dual reverse-proxy configuration.
I'm also not thrilled with the handlebars-esque DSL. Any templating solution without a general programming escape hatch is problematic in my eyes these days.
Users & Developers alike want a content management dashboard that bends to their sense of organization and needs. Many modern websites have more than one menu, for example. Custom post types are necessary for ease of use and quick content discovery. Modules exist to empower editors to insert beautiful, pre-designed content of their own making. Meta fields exist to signal to editors what kind of content is necessary to make a page viable (required fields). These types of features are becoming table stakes for modern content management systems, and they're very difficult to pull off in a meta-programming sense without the dynamism of a database.
All of that being said, I hope the author really does continue working on this. It's really great and exciting work!
cies•8mo ago
But replacing PHP with server-side JS is not the kind of progress that I'm into.
Anyway: congrats on the release!
exodust•8mo ago
PHP is still great and could benefit this CMS, which reminds me a lot of Kirby CMS. Kirby has the same ambition "get our of your way" and everything is static files, no database if you don't want one. Except Kirby has the added benefit of PHP and optional databases, and easier setup for people who aren't fans of the letters "npm".