Oops! I did it again: introducing DecentCMS
There are a few things that nobody should ever do. One of these things is to write a new CMS. So about four months ago, I decided to write a new CMS using Node.js. It’s called DecentCMS, and I’ve had insane amounts of fun building it so far.
It doesn’t do much yet: it’s only a runtime, there is no dashboard at all, but most of the important architectural foundations are in place. It works well enough that I’m already hosting two sites (my business and the CMS’s new site) on a single multi-tenant DecentCMS instance running on Azure. I manage the contents using a text editor, and I deploy it through git.
DecentCMS builds on lots of ideas from Orchard, on what I know works, and it tries to find new ways of doing what I now know doesn’t work so well. For example, the idea of content types composed from content parts is still there, but I did away with fields, instead allowing parts to be named, thus removing a common source of confusion from new Orchard users.
Before I even started writing code, I worked on establishing a set of principles that are to guide the whole enterprise:
- Modular: the core provides very little, all features are provided by services within modules.
- Extensible: all services can be replaced and extended.
- Composition: All components have a single, limited responsibility, and are composed to build larger entities.
- Decoupled: services are loosely coupled, and hard dependencies are avoided.
- Familiar: when a component, API, or pattern already exists and has been successful, use it. Don't reinvent, don't be exotic in the core. Weird and experimental stuff belongs in optional modules.
- Simple: simple designs, with a focus on core features that are needed by all.
- Open: everything is open-source, but can be used in commercial applications. Open standards are preferred.
- Easy: different personas will get different and adapted entry points into the system. Developers get a clean, clear, and extensible API, designers get tools to determine what templates to write, webmasters get complete control over the structure of the site and its contents, content creators get an easy, task-based set of tools and wizards, and end-users get modern, responsive, and fast sites. The barrier to entry is kept low, and no concept is required knowledge until it’s needed. Friction is minimized.
- Ready: out of the box, the most common types of sites can be built: blog, commerce, community. You only have to build what's unusual about your site.
- Scalable: sites are fast no matter their scale, at boot and then on every request. Tooling exists to diagnose and fix performance issues.
- Proven: all features are tested, and I’ll eat my own dogfood.
- Documented: all features come with documentation, literally: documentation is actually packaged with the code and tests for each module. JsDoc comments are used on all public APIs.
In the next few posts, I’ll detail how I implemented each of these principles, and I’ll dig into specific features.
In the meantime, if you want to give it a try, or if you want to look at the code, please do so, and let me know of any feedback you may have. Discussions are more than welcome, and if you’d like to contribute in any way, I’d be delighted.