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 acceptable.

C++ Snap! Websites Status

We are still in the early stages of development, although we're just starting to get things to connect. We've got the basic features covered as found in our Projects section. We also already have the Snap CGI and Snap Server in place. Now we need the server plug-ins to work out the content of a website. That's the part we're working on right now. Creating a few tables and writing the code that generates the pages (we already have a robots.txt and a default page too, all working. Hang in there, we'll soon have something you can try.)

• 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 limitation, 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.