What's Snap! Websites?

Snap! Websites run your CMS using binary code written in C and C++. (We use some libraries that are written in C, all of our server code is written in C++.)

The basic concept is taken from a large set of Drupal 6.x modules from Drupal Core and necessary 3rd party modules (we've been using over 220 modules on top of the Core modules.) The result is quite extensible as it offers a plug-in mechanism that everyone is welcome to use to create their own extensions.

The Implementation book lists all the features we're considering implementing in our C++ Snap! Websites.

Why not use the Drupal CMS then?

The main idea of having this written in C++ is for speed of execution. PHP is an interpreted language and although it is fast to develop, it remains slow to execute1.

The other big change from Drupal is the backend. We want to use a data manager, not a full blown SQL database. This introduces a problem: we cannot as easily gather data. However, quite often, this data gathering in Drupal can be quite slow2. Not only that, it is difficult to maintain, difficult to backup for easy restore, difficult to move from one system to another. With a data manager that does all of that work automatically, the small draw back of some extra work for data gathering looks quite acceptable.

Another huge problem with Drupal: it is impossible to have a truly international website. I tried a couple of times, and it just is a nightmare to manage. You get different pages for different languages so each menu to that "one" page are different for each language. Imagine you have a documentation of 100 pages written in three languages, that's 300 links to manage MANUALLY! (if you want the site to work as expected, at least)

C++ Snap! Websites Status

Update Jan 12, 2014

We created a full Ubuntu installation which compiles and runs on 16.04. If you are using Ubuntu, installation of Snap! C++ will be pretty easy (there are still quite a few steps to follow to complete the task, but still, just administrative tasks. So even if you are not a programmer, it will be easy to install and use Snap! C++)

Snap! Websites are composed of many Projects. We have the Snap CGI, Snap Server, and Snap Backend in place, along the Snap Manager to manage a complete installation. This is pretty much complete to run Snap! Only Snap! is composed of plugins to implement different features and those are not yet complete, the development status page shows you the current status.

The server is already capable of:

• managing plugins
• display pages with their layout or extended editor layout
• handle locale (language/country), branches, and revisions
• links between pages to change permissions, page type, parent/children relationships, etc.
• accepting user registrations (registration, email verification, login, forgotten passwords)
• send emails including lists support and user choices
• verify user permissions
• build an XML sitemap (using the backend process)
• handle the robots.txt file
• create widget based XML forms
• save standard forms or inline editor forms to the database (fully data driven!)
• generate sorted list of items (i.e. everything is a pages in Snap!)
• Started on automated menu support for the administration menu
• replace tokens found in your pages with content, and highlighting in the inline editor
• add images and attachments to pages (UI not fully available)
• display a message box (programmers can send messages to the client)
• handle any type of object

As I write this I'm finishing up the Snap! Editor which allows users to edit their page. The editor is very small and very fast, it works inline, and allows for saving your changes using AJAX.

• 1. Note that PHP is already quite fast. However, to create a large CMS system, we can quickly notice that it reaches its limits. We make use of about 100 modules on our main site, and it always responds in a little over 1 second which is not good enough.
• 2. We had several bad experiences with Drupal. Running many views on a single page will slow down your system very much unless you cache them and most often you don't want to use the cache since your data changes all the time. The list of items read from RSS feeds is very slow too. The permission system is neat, but has many limitations, plus when used extensively, it hits the database quite hard... All sorts of tables that the system generates make use of quite complicated SQL orders. Although faster than the views because specialized, they all are slow. Using a data manager such as Cassandra will reduce this problem dramatically.