The "Why?" Behind SonicJs CMS

Why Did I Start SonicJs?

Over the years, I've looked high and low and haven't been able to find another CMS written in any tech stack, let alone Node.js that came close enough to accommodating the full list of principals that I was looking for.

I’ve been in the software development industry since the mid 90’s. In that time, I’ve always had an affinity towards content management systems and enterprise application frameworks. I’m a big proponent on avoiding reinventing the wheel. I’ve used dozens of content management systems over the years, both open source and commercial. Each and every one of them have had one or more major drawbacks.

I’ve implemented custom websites, web/mobile app solutions built on CMS platforms like DotNetNuke, Wordpress, Umbraco, Drupal, Orchard, Sharepoint and many others for Companies like MARS, Nestle, Black & Decker, Mattel, Motorola, Panasonic and many startups. My last full time position before becoming an independent consultant was Web Application Architect for Panasonic North America.

I've continually found myself thinking "there must be a better and faster way". As web developers, we often repeat the same types of tasks over and over. SonicJs is an attempt to categorize, analyze and platformize these common tasks.

Please see the SonicJs principals for a full explanation. 

So is SonicJs just a Node.js based clone of Drupal?

There are hundreds of CMS, and dozens (if not hundreds) created every year. Most of them just don't compare to what I would consider the gold standard CMS: Drupal. 

So is SonicJs just a Node.js based clone of Drupal? Nope, although we share many of the high level principals, SonicJs aims to go even beyond what Drupal has been able to pull off.  See below for a more info...


All open source projects have a set of principals that they adhere to, whether written or not. The guiding principles of SonicJs are very near and dear to me. In fact, they are the core reason that I decided to embark on this long journey. Below are the list of principals that I have maintained while working on SonicJs. 

Free Forever

There are many companies building open source solutions with plans to switch to a mixed or full commercial license once they have become established. While I understand this tactic, it’s never felt right to me. Over my 20+ years in the software industry, I’ve seen this happen over and over again. In some cases it’s had a very negative impact on me because it’s forced me to abandon solutions built on these platforms. It just feels like bait and switch.

I realize both individuals and companies need to bring in revenue for their efforts. SonicJs is no different, but there are ways to do this thru offering services (professional support, custom development, referrals, hosting, etc) and custom licensing without screwing over your most loyal and devoted fans. I am committed to SonicJs being free forever. 

One Module per Feature

There will be one blog module, one gallery module, one page builder module, etc. One of the worst things about Wordpress and other CMS is that there are numerous, sometimes dozens of modules built for the same requirement. With SonicJs there will be one. If the existing module doesn’t do what you need it to, you’ll have to collaborate with the current maintainer and add it to the existing module.

This approach has numerous benefits. For one, it helps foster collaboration. It also makes it dramatically easier for other SonicJs users to add modules to their solutions without having to wade thru multiple options. Drupal does a phenomenal job at this and I think we’d be wise to adopt the same model. 

UI/UX Continuity

I can’t think of a single community driven CMS that does this well. Wordpress, Drupal, Joomla, Dotnetnuke, Orchard, Umbraco and many, many more all have different authors building different admin screens. The user experience should be consistent throughout the entire application, regardless of who built it.

This is a tall order, not easy to execute but we have a great feature built into the core of SonicJs that will greatly help achieve this goal: the form builder.  All UI forms are built using the forms builder, not by hand.  This means that all forms will have the same controls styles. Standard approaches can be taken for various user interface challenges. For the end user, the UI/UX should look and feel as if it was all built be the same design team.


Hooks/ the Event Emitter Pattern

SonicJs uses the event emitter design pattern religiously.  This allows us to implement complex business logic while keeping a very clean separation of business logic between various modules. It gives us a solid mechanism in which to run non related functions async. It also serves as a foundation for the next 2 principals... 

Light Weight Core

The event emitter pattern allows SonicJs the have a very light weight core by delegating the heavy lifting of complex operations to modules.  There are numerous benefits gained by this approach. There won’t be a need to constantly update the core which can be a pain and present risk to your production website or app. You can instead just update your modules on an as needed basis. 


Most open source CMS’ market themselves as being “extensible”. Drupal is the one and only CMS I’ve ever used that I would consider truly extensible. To be truly and completely extensible, modules need to have the power to modify and extend 2 component of the system:

  1. The Core - modules must have the ability to extend nearly everything in the core. Imagine that SonicJs’ authentication system doesn’t meet your needs. You should be able to write a module that overrides and extends just the part that you want to alter. You should be able to accomplish this without having to completely rewrite the way authentication works.
  2. Other Modules - If you've used any other CMS (besides Drupal) this is likely a foreign concept at first glance. It's hard to build a module that is "everything to everybody". However it's quite possible to build a strong "base" module, then build subsequent "child" modules that can be turned on/off depending on your needs. The child modules can both tweak and extend existing functionality to meet specific business requirements without having to completely replace the module.

Convention over Configuration

It’s nice when things just automagically work because you added a file with the right name to the right directory. Many frameworks take this approach and I think it provides a lot of value overall. 

Minimal Learning Curve

SonicJs is a complex system and will certainly require reading thru docs, watching videos, etc. However, when you first install SonicJs, it will be setup in a basic configuration with many modules turned off so that you can quickly get used to the basic features before attempting more advanced scenarios.

Developing your own custom modules should be easy to get started as well and I'm committed to giving documentation the attention it deserves.


It can be tempting for us developers to sometimes "over-architect" solutions. This is sometimes necessary but it often adds unnecessary complexity and increases the learning curve for developers new to the project. It important to keep things simple when at all possible.

Do it Right the First Time

It's ok to implement features knowing there is room for future improvement and optimizations. The MVP approach comes to mind and is fine. However, taking shortcuts that will knowingly cause future issues or cause issues for other developers with a slightly different use case should be avoided if at all possible. Sometime we need to slow down and take our time in order to speed up our overall velocity. Bugs are very time consuming to address.

100% GraphQL Based

Mobile/IoT projects are growing at an accelerated pace. In order for SonicJs to be useful to these solutions as a Headless CMS, 100% of the site content and media must be available via the API.

No "Fighting"

You shouldn't have to "fight" with the CMS to get it to do what you want. It shouldn't take 5x longer to do something in a CMS versus a custom project. This is a big problem I've encountered with nearly all of the before mentioned CMS that I've used. I'm highly committed to making development with SonicJs a productive and enjoyable experience.

Development Should be Fun

Maybe it sounds lame, but it should be fun to develop on a CMS. It should allow you to leverage the framework for the boring stuff like user management, logging, page management, etc and allow you to focus on the fun stuff like building really cool UX, implementing that awesome UI that your company paid 6 figures to an agency to design, programming advanced business logic, etc.

Building your project in the right CMS should make you look good as well. You should be able to deliver a vastly superior product in materially less time compared to building from scratch.

You Actually Read All This?

Really, and you haven't even starred the project on GitHub yet, have you?

Anyway, I'd love to get any feedback you may have. Please feel free to reach out using the contact form.

Thanks for your interest in SonicJs!