Spina CMS is "just Rails". That means you can build anything with Spina. It doesn't mean you should. Over the years we've developed strong opinions about what makes a good CMS. We've applied those lessons to Spina CMS, resulting in the following list of design principles.
Keep it simple
This one should be obvious, but it's worth repeating. Keep in mind who the end user is and build accordingly. Cut away the cruft. Not everything has to be editable.
Dare to be different
Web design is often criticized for being too boring and similar. Traditional CMSs make it difficult to create complex editable layouts, discouraging exciting design. Spina provides flexible content fields for everything you need – nothing more – and then goes out of your way.
No HTML
HTML belongs in source code, not in a CMS. The end user shouldn't need to know what HTML is to edit their website.
No WYSIWYG
What you see is what you get is a promise that fails to deliver. Instead, Spina includes easy to use page editing forms with clear labeling. It uses Trix for rich text fields. Page forms in Spina have zero optional fields so users don't have to guess.
Configuration happens in code
Everything a developer has to configure should be done in Ruby, not in Spina. Configuration rarely changes, storing it in version control is better than storing it in a database.
Be fast, without caching
Slow websites kill the user experience. Spina uses Postgres' JSONB-type to store all content as JSON. This makes pages screaming fast without having to worry about cache expiration. It's better to embed content directly on a page than to reference a different table.
Fewer dependencies is better
More dependencies equals harder maintenance. Spina tries to stick with the vanilla Rails stack as much as possible. That way there's little risk of getting trapped in dependency hell when upgrading down the line.
These design principles are what guide us when developing Spina, but are not set in stone. Feel free to adapt Spina to your needs!
