Principles

Here are some of the principles that guided the design and development of Saltcorn:

Open and Extensible

we embrace open source and free software as a development and a community model. Every other principle and design decision are subordinate to the principle of growing Saltcorn as an open and free community. We put no barriers to how people and companies can use the Saltcorn code base and software and facilitate self-hosting and alternative commercial hosting options by releasing the multi-tenancy hosting capacity. Likewise,

One full-stack process

A single program handles the front end data display for end users, the admin interface for building sites, back-end data management, and server for pages and files.. The actual data is stored in a relational database such as PostgreSQL. In this respect Saltcorn follows the model of WordPress and other classical CMS systems. In fact, we often think of Saltcorn as a CMS for structured data.

Defer fine-grained layout to a theme

Most of the layout decisions in Saltcorn are made by a theme which can be installed as a plug-in. That way, Saltcorn applications can achieve a diverse range of look and feel, and one layout can be swapped for another without extensive work from the application builder.

Embrace the relational data model

The relational data model is well understood, well tested and capable of formalising many different application data models in a clean and simple structure. Relational databases are extremely robust and scalable, and their use is well documented.

Move as much functionality to plug-ins as possible

If a facility is moved from the core Saltcorn process to a plug-in, that means that it can be unfermented differently in a different plug-in if necessary, leading to a more flexible overall solution space.

Code

Implemented in JavaScript, the language everyone knows

if you are doing web development you will sooner or later have to learn JavaScript anyways. By writing Saltcorn in JavaScript we have a large base of potential contributors. The JavaScript language has really cleaned up, and with async/await is a feasible choice for large code bases on the backend.

Clean data over clean code

In general, in software engineering we favour producing value for the user over maintaining a clean code base. If a bit of messiness creeps into the code base, it is not the end of the world as you can always clean it up later if you have provided value to the end user. (If you don’t provide value to users, it doesn’t matter if the code base is clean or messy.) If on the other hand your primary data store becomes messy, that can be a devastating situation that it can be difficult to recover from. We always maintain a clean data model. A database for a Saltcorn application should look as if it has been designed by a competent data modeller. This makes it possible to transition from Saltcorn to a code application.

Simple object oriented functional programming

We use the good, simple parts of object-oriented and functional programming. This means no inheritance or only one inheritance layer but do use objects for mutable state as necessary. Write concrete rather than abstract code. Use anonymous functions and higher order functions generously, avoid more advanced patterns as they quickly lead to unreadable code.

Design by contract

Use design by contract to provide test-time type checks and checks for properties that are more difficult to predicate in type systems. We wrote our own design by contract library for Saltcorn. Contract checks are enabled in production and will crash the application on a contract violation. Let it crash, loudly, so you know what to fix.