Hello, I am Jeremy Shaw, the creator and lead architect of clckwrks. I'd like to share with you my inspirations for creating clckwrks, why I think it is important, and where I think it is headed.
clckwrks was created to address the needs of three groups of people I interact with on a regular basis:
The Haskell web developers I talk to are trying to build sites to solve specific problems. But, they can easily get bogged down in all the support infrastructure that is required to make that happen. For example, many websites need user accounts, admin consoles, content management, etc. But even just creating a solid user authentication system alone is a significant amount of work, and filled with tricky details.
The core clckwrks package aims to provide these essential services so that developers can get started right away focusing on what makes their web application unique, not trying to figure out which random number generator library is cryptographically sound.
Beyond the core, there is still a lot of common functionality that can be found in different web sites. For example, most photography sites need a media gallery, many project sites need a bug tracker, etc. The clckwrks plugin architecture allows developers and non-developers to quickly assemble sites by combining existing plugins.
Most CMSes have support for plugins, but, unfortunately, they are often very fragile. Dynamically typed languages like PHP and Python do not make it easy to mechanically check that the plugins and core library agree on the API they are supposedly sharing. As a result, upgrading your CMS can result in broken plugins and other ugly surprises. Haskell, on the other hand provides power tools that allows us to mechanically check the compatibility of plugins.
In order to ensure the quality of plugins we will be able to offer 4 levels of certification. The first two levels are entirely automated, so we can provide them even if we have thousands of plugins. The latter 2 levels deal with the human part of the equation.
level 1 - we can automatically test that a plugin compiles against different versions of clckwrks. A successful compilation does not guarantee that the code still works -- but it is certainly a positive sign. Failure to compile is a definite sign that an upgrade will not work. We will automatically notify plugin maintainers if their plugins fail to build against upcoming releases of clckwrks so that they can resolve the problem before it affects end users.
level 2 - developers can also provide a test suite which we can run automatically. Using the Haskell Program Coverage (HPC) tool we can check that these tests have 100% code coverage. If the test suite succeeds and has 100% coverage, then it can be level 2 certified. This is an entirely automated process.
level 3 - this level means that clckwrks has a relationship with the vendor, and that we feel reasonably confident about the quality of their code and their commitment to on-going support for the plugin. They must also pass level 1 & 2.
level 4 - plugins at this level are supported directly by the clckwrks project. They must also meet all the requirements for levels 1-3.
Another issue that comes up a lot is themes. Designing a good looking website is difficult and can be very time consuming. There is a good reason that web design is its own specialized field. Like plugins, themes for PHP and Python based solutions are often broken and buggy due to the lack of static type checking. Fortunately, the same tools, techniques, and automated checks we use for plugins can also be used for themes.
For Haskell developers, the big win here is being able to develop web applications in Haskell, but still be able to leverage the work of graphic designers.
The challenge here will be getting enough critical mass to make clckwrks attractive to theme designers.
One of my friends is a writer who runs a subscription based website. She pays monthly fees to various vendors to provide subscription management, mailing lists, etc. Unfortunately, she leaves money on the table every month, because these services are not integrated. When a subscriber's credit card is declined, there is no way to automatically add them to a former subscriber list and ask if they want to come back.
As we develop more plugins, an important aspect will be creating plugin bundles that target the needs of specific industries. The key to a good bundle is that it needs to act as a well integrated collection, not just a bunch of independent plugins.
My friends often ask me how to create a website. Usually I wince and then tell them to use Wordpress. Wordpress has tons of themes, loads of plugins, and there are a ton of people that know how to use it, so they will be able to get help if they need it.
But, I wince because I also know what types of problems they are going to encounter. Most of these people are not going to update their sites very often -- and are going to be running old, insecure versions that will be attacked by bots. And, when things don't "just work" they aren't really going to have any clue.
My writer friend has to pay hundreds of dollars per month to a Joomla developer just to keep her site functioning. Stuff that should work, suddenly doesn't. Instead of investing in improvements in the site, she is just paying to keep it functioning.
For my own personal websites I use Wordpress -- and it makes me nervous. I worry that I am going to get hacked, that the next upgrade is going to break my site, etc. And, I feel completely uninspired to add features to the site that require any sort of PHP coding.
In clckwrks, we start off right by using Haskell, which gives us the tools to enforce safety at compile time. If we have to rely entirely on developers 'being constantly vigilant', then we will be in deep trouble. Instead, we strive to move as much as the vigilance into automated processes and good tools as possible. For example, the HTML and Javascript templating libraries we use automatically escape strings ensuring that users can't insert malicious code. The database library we use uses pre-compiled queries instead of interpreting strings at runtime. As a result it is impervious to SQL-injection style attacks.
So, what I want is a CMS that:
I hope that you will join me in making clckwrks great. Listening to people talk about the problems they are currently suffering from has been a big source of inspiration. And continuing to address the complaints of users is what will make clckwrks great.
clckwrks is still pretty rough around the edges (and the insides too), and does not yet live up to the standard we want to set. But, that means that there are still lots of easy and fun ways for you to contribute as we get things in shape for clckwrks 1.0.
Thanks, and hope to see you around!
Jeremy Shaw