Selecting a framework for implementing web applications
31.3.2010 —We have been lately working with several web applications and social media systems. Every system has a unique business model and value proposition to the customers and the visitors, and thus the functionality we have been implementing vary a lot between the applications. However, when digging one level deeper, similarities start to surface.
There are a lot of typical features in web applications, such as registration, signing in and out, viewing your details, and so on. On the admin side, one needs to be able to list, add, modify, and remove items — whatever they might be — and to manage users, see log files, etc. If we drill one more level down, there is a need for a common set of library functionalities, such as image manipulation, friend and group management, session handling, and protection against SQL injections and XSS / XSRF attacks.
If you are coding all components mentioned above, you are either in framework business or doing something wrong. There is no need to invent the wheel again. Instead, you should be focusing your energy on selecting the correct wheel for your needs.
There is a plethora of different web application frameworks in the market. Some of the publishing systems, such as Drupal or Joomla! provide their own application frameworks within the CMS. The selection is not easy, because approaches to the challenges of web application development are different, and sometimes even not directly comparable.
When we selected our core set of tools (Drupal, WordPress, eZ Publish, and CodeIgniter), we looked at the following items:
- Easy of extensibility. How easy it is to extend the system using the API provided? Or do you need to take shortcuts and fight against the system when there is a need to make anything fancier?
- Availability of third party components. Can you rely on third parties to solve your problems completely or partially? What is the quality of these components? This resonates directly with the needs listed above.
- Separation of content and presentation. Is there a proper template system with easy enough syntax? Does the system enforce good policies for separation, or do components produce HTML directly?
- Performance. How long is the route to your code through the system? Does the system provide mechanisms to cache data in various levels? Some of the systems are notoriously bad in this area, and constant attention needs to paid to the performance throughout the project — others are lightning fast.
- Documentation. How well the system is documented? This can be a real killer, as reading code is way slower than reading through good documentation.
- Fit for the purpose. What is the problem that the system tries to solve? Is this your problem, too? Developing applications against the system is a constant uphill battle and not worth the money and the effort spent.
None of our systems are perfect. WordPress has issues with separation of content and presentation, and the performance is not optimal. However, it is an excellent tool for small and medium scale web sites. CodeIgniter is fast, but you need to implement a lot of functionality around it. There is a good number of third party components, though, and active development going on. Within Drupal, there is typically at least one module that solves similar problems you are working on — sometimes the approach is not valid, or the module is half-baked.
After selection of the systems, we have been steadily gaining knowledge of good modules and extensions that can improve the projects at hand by cutting development time and thus prices. Further, we have been implementing a commonly used functionalities, as mentioned in the beginning, into libraries and components that can be used in any project requiring such functionality. We do not believe in coding for possible future needs, so the components grow based on the needs of the project — and the next projects get more features from the same components. One just needs to keep the solutions generic enough so that they can b reused.
We have been able to use the components so that some projects have been able to implement a large set of functionality, such as group management, with only a few hundred lines of own code.
I am amazed that at the same time you seem to know what you are talking about, but do not even mention Joomla CMS. As it is built using the best practises, it really is flexible to be the platform for any type of web-application. It can be criticized for it poor access control framework and some what old database api. But the first can be substituted and the other is something one can live with.
I would assume, that you really have not evaluated all the CMS’s ( as your post does not mention the biggest one ), but you just must use some of them for external reasons. And that is why you have only subset of CMS’s and frameworks mentioned.
How ever I totally agree the thing between the lines in the post: there is alwys freedom to architect extensions in such manner that they do not completely rely on the framework used, and there for are more portable.
Drupal: lacks modern object oriented concepts and is there for too old.EzPublish: no wide community support, has weird structure in its code base – not a very architectural framwork.CodeIgniter: does not even have built in master templating system, what’s that about!
Joomla, Elgg, some others, are just more modern and probably will be winners in CMS competition, if there is such competition going on.
Hannu, thanks for valuable comments. We have, in fact, done sites with Joomla! and some other CMS systems.
However, we consider Drupal to be a better fit for most of our customers — as we are doing complex sites that have a lot of user generated content or social media features. The ecosystem around Drupal is simply better for us and our clients in these scenarios.
Joomla! has its strengths over other systems, and thus we have adopted it for certain types of customers that are not served well by Drupal (expert admin UI) or eZ Publish (too much functionality).
Anyhow, we do not select the technology just by its own merits, but also through market adoption, customer awareness, and availability of developers in Finland. For those, WordPress, Drupal Joomla!, and eZ Publish (in this order) seem to offer the best toolset for us to be offered to our customers.
We have looked around quite much for good systems, and will take a second look to Elgg, but we need also to limit our platforms — otherwise we cannot master them deeply enough.
Speaking of CodeIgniter templates; the first thing we did with CI was to bolt Smarty template engine to replace CI’s own view system. That was almost three years ago and Smarty is showing some age, so any pointers to better ones (we’ve identified a couple) are welcome.
My perspective is more technical and all those business oriented view points are not in my scope. I usually don’t see as tight tie though between business requirements and frameworks. Usually frameworks are not in-depth understood and there for their capacity is not fully unleashed. The main business rule for picking one seems to be that customer(s) want to use specific CMS – and as you mention in other article in your page you are willing to go along with that single requirement:
“Olemme käytännöllisiä järjestelmän valinnassa; jos asiakkaamme haluaa tai heidän täytyy käyttää tiettyä järjestelmää, opettelemme sen erityispiirteet ja toteutamme palvelut sen päälle.”
I am sure that you have search for the template engines. Here is some list of those with few comments: http://www.webresourcesdepot.com/19-promising-php-template-engines/ I do agree with those that consider PHP5 as the best template engine. I do not always see the benefit of using some processing between data and templates in non-PHP5 way. There are pro’s and con’s using XSLT or other XML based templating. I wonder what the problem is that they try to resolve… Maybe converting XML to any of the popular Internet types like PDF, text versions of the page, etc. But how often that can be implemented inside XSLT based templating layer? I just would go with the PHP5 and build those few necessary classes required to do templating. But again, there might be other business requirement I am not aware of.
Hannu, thanks for the link. We’ll take a look at them — and some of them, like Smarty and Dwoo, are already familiar to us.
Template engines, in general, force clear separation of business logic and presentation, organise the project better, and allow people with no knowledge of PHP to work with HTML templates relatively easy.
Most of this can be also achieved when using PHP as a template language, but in our projects we tend to get easier / better view layers when using Smarty.