Zena starts to work and we ask ourselves questions about optimization (especially in memory usage). Then we think “if we started this all over, what framework (if any) would we use ?” given that we want speed, small memory footprint, unknown link, unknown link, ‘live edit’ and modal templates.

Haskell (haskell.org)

Haskell is not a web development framework but we are currently fascinated by this language. It’s really fast and we like the functional programming paradigm, but it’s syntax seems too far from something we could work with. There are some haskell frameworks for the web (HAppS), but it looks like it would take us weeks to understand even the ‘hello world’ web application. We put Haskell in this list because we do not understand anything about haskell.

Django (djangoproject.com)

Django sure looks great. The fact that most ‘administration’ tasks are made for you could be a nice thing that rails lacks, but we want to handle this part ourselves, reducing the gap between reader/writer/publisher as much as possible. We decided to start working on Zena because we were fed up with complicated admin pages like the ones found in spip. These pages might be very well thought, with nice graphics and pretty CSS. But they are too different from what the reader was used to before he/she suddenly became a contributor. The less admin pages, the better. Django does not play with Ajax as well as Rails does… And we really dislike these ideas on forcing coders to write like this and not like that (python philosophy). It’s funny that it’s called the “zen of python”. We understand zen as “creativity through clarity of thought” not as “uniformity through obedience to the master”. Anyway, as a python framework it looks much nicer then Zope and so close to rails. If we loved python, we would have chosen Django.

Ruby on rails (rubyonrails.org)

Some of the tricks you can see on screencasts (scaffolding, macro defined relations) were not really useful for our project. We had to redefine our own relation management (called Linkable) and we could use very few of the rails built in has_many and friends because our security model is too complex to allow simple scoping in these macro definitions. Moreover, the Model-view-controller paradigm is very strong in rails and we felt it was annoying. Maybe the best paradigm for web applications is not MVC but might be “Model-Template-Domain”, something without a controller but with a stronger model capable of receiving user interaction directly and a very thin domain for the data. That said there are some things we really like with rails:

• AJAX integration is really good, especially through RJS
• Testing is very easy for models and controllers. It is much harder to test views (helpers).
• Model callbacks (validations, after_save, before_create, etc) are very intuitive.
• and of course, made with Ruby !

Symphony (symphony21.com)

Symphony seems very interesting. They use XLST to render html pages from xml (you do not write the xml, it’s pulled out of a database). Some years ago, we became fed up with MS Word and decided to write our letters in XML, using XSLT to create XSL:FO and then PDF files. We really liked working with XSLT. The way it expresses the relation between data and views was very convincing. The problem with an xlst stylesheet is that your designer will hate it. When we designed unknown link, we took all we could from the way xslt expresses data to view relations but tried to make it in such a way that designers will enjoy working with our templating language. Symphony templates don’t seem that fun to write…

We feel that the framework is geared toward developers (“made for developers” as it says on their first page) but we think that web applications are about “users” and “readers”. The fact that you can do a lot of work on you web site in a nice admin section means that you tend to forget all this is going to be read.

conclusion

From our perspective (create a Content Management System with our own templating language and as less admin pages as possible), the fact that a frameworks offers a great templating language (symphony) or clever admin pages (django) is irrelevant.

Speed is an issue in all these frameworks, so none really wins our heart for resource management. A lot can be done to improve speed for any of these frameworks but whatever we do, they will not scale down well (easy to host for a few dollars, so fast that cache becomes a silly idea).

The language: XSLT+PHP vs Python vs Ruby. We choose ruby because we are fond of ruby (less messy then perl but more then python).

The framework: we believe all these frameworks are really good at what they are aimed at. From our very limited knowledge of Django and Symphony it seems that these frameworks let the developer work on a higher level then Rails which is more like a library. When designing a content management system, we need a ‘library’ to help us, not a full web application. We are happy with Rails because it doesn’t do too much.

If we had to restart from scratch, we would take the same route: Ruby on Rails.

webography:

• rails vs django development speed (google docs). It seems strange how everyone seems to benefit from scaffolding and the like. During the development of Zena, this was of no use to us because these solutions are too general to create a cms with a complex security layer.
• rails vs django vs symphony performance test (this test got flames, but we found no other).
• ruby vs haskell vs python speed for a simple mandelbrot print.