Reply to comment
A Comparitave Analysis of Web Application Frameworks.
Submitted by bingomanatee on 5 February, 2009 - 03:30There are many codebases designed to assist you in the construction of web application development. Some require little or no code expertise, others demand it. The quality of code varies widely as does the amount of prefabricated solutions available. I have even tossed in SugarCRM which is not an intentional player in the CRM/Framework marketplace only because its open-ended configuration driven system makes it a powerful web application toolkit for a broad range of tasks.
Before I get into the details, a caveat: the strength of a codebase is relative to the strengths and tendencies of the team that maintains it. Though there is no doubt in my mind that there is a framework out there that nearly any team can benefit from using, choosing a framework without input from the team that is to use it is ill advised. The exception being, if they reject all frameworks and insist on writing all the code from scratch, they are probably too inexperienced to be responsible for such a monumental decision.
CMS vs. MVC
Cake, Zend and Symfony are frameworks for the do it yourself crowd. Drupal, XOOPS, Mambo, Joomla and SugarCRM are pre-fab, modular solutions; while coding can bring out their best, they are designed for people who are content to assemble, configure and "tweak" systems that other people have made.
Comparing these two wholly different systems is unfair; its like comparing a hacksaw to an assembly line robot. However, they do have comparable goals -- to enable their users to assemble websites. So even though their approach and target userbase is vastly different, comparing them side by side should help self-educate their prospective clients. And where the robot shines in its specialty, the hacksaw's general utility put it ahead in other arenas.
Similarly, CMS's go farther down the design road in specifying an approach for a host of components -- at the very least user profiles, view rendering and generally speaking, some assumption about content organization schemes. Inside every CMS is a depenant, custom(by practice) framework that manages the lower level data abstraction, rendering and routing tasks that independant frameworks will provide, but the reverse is not true.
The Contenders
I am listing the systems in order of their introduction. They all have the following shared characteristics:
- They are LAMP based. For good or ill, its the turf I roll in, so its what I'm qualified to examine.
- They are open source. They can all be modified at every level.
- They all have a substantial user base and development community. Help can be found in forums, books and websites.
- Most of them have a full fledged company behind them. Specifically, Zend, Mambo, and SugarCRM have true corporte backing. My apologies to the other if they also have corporte backing I'm not aware of, but to the best of my knowledge, Cake, Symfony and XOOPS are still "pure" community supported endeavors. I'm not trying to establish either model as superior but it is interesting to note that many of these frameworks despite lacking a consumer orientation have been successful enough to merit inorporation.
- I have used and read the codebase of all of these systems with at least one real world client.
Mambo / Joomla
Mambo is an open source project that evolved into a secondary but essentially identical product called Joomla. It is a CMS, designed to be assembled by a lightly skilled developer content with patching together pre-fab solutions and templates. It has supported years of development and has a galaxy of plugins. I have only personally used Mambo. Ideal Adapter: A blogger on the move. Someone for whom spitting out content at lightspeed is more important than investing in web expertise. Rigged to Blow: Anyone who plans to work with the system at a code level.
Drupal
Drupal is like Mambo; its code is better organized, but what makes it different is not so much the code but the way its data is organized and standardized. Its nodes work like legos -- you can nest and assemble them into whatever arrangement you like and they are designed very well to "plug into" each other. Internally, Drupal is one of the great non-OOP holdouts, being strictly function-driven. However its node system emulates objects and does a great job of semantic mapping. Of special note is its unique Content Constuctuion Kit which enables a nearly endless variety of informational constructs, and the view system which allows those (and other) nodes in blocks and pages, both of which are usable without any PHP background whatsoever. Wonderland Labs is a Drupal stack. Ideal Adapter: a non-coder who wants custom results in their blog without a lot of effort. Rigged to blow: anyone who os strict about OOP. (See Drupal's OOP Apologia.)
SugarCRM
SugarCRM is an immensely configurable CRM -- customer relationship management tool; that is, a system for storing conctact information and potentially a wealth of related data-- product catalogs, etc. Despite being a finished application, it is extremely modular and adaptable to a wide variety of data and backend needs. You can create whole systems by tweaking its configuration files, a feature unique in this lineup. It is the consummate intranet tool. Fair warning: even using it at a superficial level is an investment of significant time. If you are really looking for a deadon simple data wearhouse for small business, consider Claris Filemaker Pro. Ideal Adapter Someone with a big client management task, and/or a huge and detailed product catalog. Want to be the next eBay? here's your wonder tool. P.S.: Buy a support package! Rigged to blow: Someone expecting an outward-facing solution. Someone in a real hurry.
CakePHP
Cake is a Ruby clone for PHP. It is the best tool for small-scale custom application development. While it doesn't have the same type of plugins as XOOPS, Mambo or Joomla, it does have a healthy array of Web 2.0 - oriented solutions at its Bakery, and a powerful Scaffolding. It is by far the best tool for the smallest scale projects. Ideal Adapter: An Agile zealot who doesn't want to lose the gains made in the PHP community by switching to Ruby. Someone with a small project that they want to toss out with plans to continue gradual development. Rigged to Blow: a noncoder, anyone expecting a CMS; anyone with powerhouse Enterprise expectations.
Symfony
Symfony is very comparable to CakePHP; its also the project that I have had the least exposure to but I was very impressed by the ease with which it integrates an existing databases and builds out from scripts. Its set of features make it ideal for intranet projects. Its strong AJAX integration is outstanding. Ideal Adapter: Someone who needs to control an already dauntingly interrelated database; an intranet developer. Rigged To Blow: a noncoder, anyone expecting a CMS; anyone hoping to gradually convert an existing site to a different framework.
Zend Framework
My current favorite framework, Zend is the most modular MVC available, and has many modules which can be adapted to existing codebase. Of all these systems, it is the one most easily insinuated into an existing codebase. The modules are noted for being assembled from a wide array of compact classes. It is also well documented and effortless to pick up and run with for the knowledgable coder. However, it is not by any stretch a CMS: there is no catalog of templates, fully finished plugins or even an admin layer to speak of, and you're on your own when it comes to Ajax -- though it does have a smattering of JSON aware systems. As one would expect from a system designed by the owners of the PHP language, its got a clean, nimble codebase. Ideal Adapter: an owner of an already impressive website who wants to establish more systemic control of their processes. An enterprise developer with a strong OOP/Agile bent. Rigged to Blow: a noncoder, anyone expecting a CMS; anyone who hates/fears OOP; anyone in a hurry.
| Measure | Drupal | Zend Framework | Symfony | CakePHP | SugarCRM | Joomla/Mambo | Comments | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Ease of Assembly | 1 | Perfect: The standard by which others are measured. | 6 | Impossible: Zend is for coders. | 5 | Hard: Symfony is also for coders but it has better scaffolding and site initiation scripts. It will create a stub site for you, but you really aren't going to like the results. | Difficult: CakePHP is also a coders tool; its scaffolding and scripts are as good as Symfony but its self-generating structure ("Baking") is not as thorough. | 1 | Powerful: SugarCRM have invested huage energy ito making their product easy to configure; whole modules can be instantiated from config file tweaks. | 2 | Strong: Joomla and Mambo are a dream to plug sites together like a lego house. | 3 | Only the last two frameworks are intended for "plug and play" use -- this quality strongly differentiates them from the first three. |
| How easy is it to use without getting deeply into the source. This is the "Scaffolding factor" -- how much self-generating code is in the system | |||||||||||||
| Ease of Learning | 1 | Solid: A solid community and long legacy of contrubitors, and a good forum and site to boot. | 2 | Poor to Moderate: strong documentation and a very easily understood development pattern, but a very large mass of modules to comprehend. Unlike, say, Cake, there us a substantial "critical mass" of code that must be read and understanad to be at all effective. | 3 | Easy: Good documentation; wins over Zend because its toolset is much more task focused than Zends, so you aren't as likely to have to sift through modules that don't relate to getting a site up. | Easy: Cake's self-teaching code, simple and effective scaffolding, clear documentation and very approachable ORM makes it the fastest system to learn and apply I've ever seen. | 1 | Basic, You can do more configuration based development in SugarCRM than you can in any other framework. it is the only completely finished application in this series which gives it an unfair advantage in this area. | 2 | Simple: Although it is the easiest system to plug stuff together with, it is the hardest system to customize. So it is very easy, if you are willing to accept module and templte designers conceits wholesale. | 3 | The approachability of the codebase is one of the areas that these systems vary in more than any other measure. |
| How easy is it to learn to code in, write modules for, etc., especially for novice codeers. | |||||||||||||
| ORM | 3 | good: Drupal doesn't have an OOP ORM like most frameworks; it uses straight SQL in many cases. However the node paradigm combined with CCK means it is quite possible to establish structures through a web interface which is an ORM of sorts. | 2 | Very Strong: The table component is quite flexible -- it has some great SQL abstration like unto Doctrine but is very approachable, flexible and intelligent. It is also worth noting that Zend is not bound to its own ORM at all, unlike the other systems | 2 | Strong: it uses Propel by default, which has great features like automatic YAML to database or database to YAML translation. The ability to echo your DB in class structure automtically with a single click can't be beat. | Strong: A very close third, it is not as good with multi-database environments, but is still extremely simple to pick up and use. | 1 | Excellent: one could consier SugarCRM itself to be basically one big database manager. | 5 | Weak: While not too bad, it doesn't really compare to the other contenders; kind of antique. | 4 | There is a wide variety of utility in the ORMs -- that being said, its quite common for developers to eschew ORMs as a whole and stick with custom or core PHP sql access systems such as PDO, to take more direct control of caching and table spanning. |
| The overall usefulness of the ORM | |||||||||||||
| Enterprise Readiness | 3 | Arguable: Drupal does not use OOP and for that reason, it does not look like the packages that generally fly in Enterprise contexts. Enterprises in general don't gravitate towards CMS's. However, in an intranet capacity, it is very ideal for companies looking to establish internal sites Drupal would be fantastic. And the non OOP tack is actually a performance gain in many contexts. So there is probably going to be a perception vs. reality gap here. Also you are going to have issues extneding it over an existing codebase. | 1 | Perfect: The gold standard in distributed systems, designed based on a lot of real world feedback from scaling startups. It is easily the best system to gradually introduce into a working environment. | 2 | Good: Altough more of an interdependant system, its realm seperation and translation modules make it a strong contender for scalable use. It loses out in that is not quite as easy to transition into use as Zend. | Fair: Although it is a very rapid development environment, its modules are much more tightly bound and some people have complained that like Ruby, while basic systems can be quickly assembled, long term scaling and adjustment are more problematic. | 2 | Strong: While SugarCRM is designed for enterprises, it often displays performance issues. That being said, its customizability and out of the box utility is superlative, and its support system is stellar. | NA | Do not use Joomla or Mambo in enterprise systems, period. They are maintenance nightmares and in rapidly evolving systems you will be destroyed. It is in fact the least MVC framework in common use. | 4 | There is a vast gulf in the ability of these systems to scale to the needs of a major institution. While anything can be done, and the definition of "Enterprise" is arguable, this is the measure by which these systems define their niche. |
| How applicable is the system to large scale projects | |||||||||||||
| Small Scale Applications | 1 | Perfect: This is the arena Drupal owns. | 6 | Poor: No pre-built tempates, components, database integration scripts or admin center. Zend is not a CMS. | 5 | Mediorcre: Better than Zend due to its scaffolding and ORM scripts; however there is still a healthy self-eduction barrier. | Great: What it lacks in pre-buit solutions it makes up for in metasystems, a simpler view and DB layer, and scaffolding. the Bakery is also a useful resource for quickly punching out sites, one that the other frameworks really don't have. | 2 | Good: SugarCRM is a finished application, giving it a remarkable edge. That being said, the task to which it is suited and the array of options is daunting to a truly small context. | 1 | Strong: Mambo/Joomla is the best system for throwing togheter pre-built elements and templates into a working system -- it owns this niche. This core feature is the reason for its success. That being said, its almost impossible to use Mambo without running into its impenetrabe codebase even on small projects. | 3 | Comparing general frameworks to CMS might seem unfair but considering the CMS' shorcomings in so many other categories, its only fair to present the one category in which their strengths are unmatched. |
| How suitable is the system for simple projects. This is heavily influenced by the self-sufficient modules built for these systems. | |||||||||||||
| RAD Friendliness | 2 | Excellent: Drupal is designed to be easy to develop in and has a pretty clear if quirky architecture. It is the undisputed kin | 3 | Poor: ZF is designed by and for class A programmers; any user friendliness has to be built BY users, as it has not been created by Zend FOR its target audience. | 4 | Fair: Also object oriented; as agile as Zend, it is more rapid and easier to "self-spawn" a site. It also features built in AJAX support which Zend does not. Like Zend it best serves a user base of trained engineers. But it does have fair scaffolding. | Strong: While the lack of a record or recordset object level in the ORM makes testing coverage less complete, it is bar none the fastest way to whip up a system, especially one with a smaller scope, than the other frameworks. It is an unapologetic RAILS clone. | 1 | Great: Its tough to beat a finished application for speed of development, especially one whose modules can be spawned wholesale from configuration. | 6 | Lousy: Its codebase is aged and very inflexible, and in most cases not object oriented as well. | 5 | You can't fault the older codebases for not being as agile as the modern frameworks -- but you really can't praise them for it. If your definition of Agile is Rails, than Cake is a major candidate. |
| How suitable is the framework for rapid application development and unit testing | |||||||||||||
| Intelligent Codebase | 2 | Weak: Drupal lives in its own world, and that world is hackish and quirky. That being said its amazing community and module repository means the strength of the codebase is not a primary choice point for Drupal. | 1 | Perfect: State of the art codebase, unmatched modularity, strong docs, and consistent patterns; thorough MVC, OOP and very economic use of code. Configuration and properties very readable. It is as close as one can come to a textbook in good code practices | 2 | Strong: While I have to confess I've not read nearly as much Symfony code as I have the other systems, from what I can see, its pretty solid. | Very good: The best strength of the Cake codebase is that it accomplishes a lot without a huge amount of code. | 4 | Good: SugarCRM was designed from day one to be extensible. It's easy to work with having some of the strengths of both Zend and Drupal. | 6 | Awful: Even in its day, Joomla's codebase was crap. | 5 | Its predictable that the more recent frameworks are also better coded, but understanding historical precedent beind lousy code doesn't make it any easier to work with. |
| How well written and easy to work with is the code | |||||||||||||
| Strengths Summary | Lightning fast to work in. Plenty of pre-built solutions that can easily be extended to meet specific needs. Can be adapted to many contexts with zero coding. | Superlative codebase. Easiest tool to gradually introducte into a working system. Individual modules (such as ACL, Caching, DB, Mail, Web Services bridge) easily used without adopting the MVC -- this is the only system that can be used piecemeal. | Has the best scripts for building out a system based on a database. Has Scaffolding that Zend does not, making it a very strong contender for intranet development. | Cake builds on the simplest codebase -- and simple in many cases is best. For smaller, cleaner projects Cakeis really out standing, and it has a strong batch of tools and a great developer community. | It has a strong company driving development unprecedented in open source; it is a completely finished tool and has a unique config-driven module system. | It has the largest collection of prebuilt solutions and templates, and the best looking admin area of all these systems. For smaller projects that fit well in the CMS pattern, its tops, especially if your maintainers are not really strong coders. | |||||||
| There is no "Microsoft Word" of web frameworks; they each have their own strengths area, and web production is to diverse for one solution to dominate, despite my clear preference for Zend and Drupal. Each of these systems do have very distinct strengths and weaknesses. | |||||||||||||
| Shortcomings Summary | Its quirky codebase. Its lack of ORM or OOP functionality of any kind mean making complex business logic daunting to integrate. | No pre-built modules. Also no built in admin layer or templtes -- do it yourself. Takes best practice/OOP to a seriously deep extreme. | Very tightly bound into one solution -- could be problematic to introduce gradually. No templates or pre-built modules. No pre-built Admin layer. | Some rumors of scalability issues; no templates; some pre-built modules but not comparable to those of fully formed CMSs. No real Admin tools. | Its not meant for an outward facing website; some performance issues with truly ginormous datasets. Also its default interface is an aircraft carrier of blocks and features. | Very difficult to customize; poor code. Not enterprise ready. Not really MVC or OOP in the accepted sense. | |||||||
The Case Against Frameworks
In plugging Zend at work I ran into a very counter-framework philosophy. For the benefit of those wanting to put forth frameworks, here are the arguments against framework, and their rebutta. (Incidentally these are for the most part, verbatim from the people at StumbleUpon.)
- A framework requires too many file includes which puts a load on the file system.
- The company ends up maintaining the framework code.
- The framework code is a lot of code to be adding to the codebase at once.
- You waste a lot of time having to learn the codebase before it becomes useful
- Using the framework concentrates a lot of the code in a single set of libraries; once this concentration exists, optimizing the libraries for one context threatens the integrity and functionality of the other depedant codebases.
In short, adopting a framework adopts a large codebase into your site with a single decision. The integrated nature of a framework means that adoption is bound to drive you into a performance bottleneck that will cause you to reject and rewrite whole chunks of the framework when you get into wide usage.
The rebuttal
Framework code is maintained by a far larger group of programmers than most companies have available to them, and is tested on a very broad range of applications. Framework code in my experience is better and cleaner than any application code is or ever will be.
It is possible that a company may end up participating in framework development; however it is far more likely that the company benefits from the rising tide of other developers' efforts, than the other way around. If you choose a good framework (and almost all the choices above are good ones) you will begin far further ahead of anyone who likes "working from scratch".
Adding frameworks to a site does add a learning curve to the developers -- but ask yourself this -- how many people are writing books about your home-brew source? Framework documentation and commentary is generally pretty top notch. This means that while there is an adoption period, it is also true that at least part of your codebase will be well documented and even better, part of the common education; it is quite possible that you can find a developer already prepared to understand a huge hunk of your codebase if you start with a popular framework, creating a time benefit. Better yet, working with frameworks encourages you to adopt the habits of its authors, adding a level of clarity to the code and again, increasing its readability.
The concentration factor is a real concern; however, there are two paths towards safe modification of the codebase without sabotoging other dependancies. You can write inherited classes that modify and optimize certain functions of the framework, or you can simply stop using the parts of the framework you need to optimize, and use custom code where there was once framework code. What, then, do you gain by using the framework in the first place? Time. You can develop your app, educating yourself in the business demands of the application and writing the code that will likely stand the test of time, instead of writing boring SQL strings and request routing code.
A classic example of an area where you will need to diverge from frameworks is cross-row joins. Most frameworks simply are not optimized to handle cross-table joins. A row object, after all, handles a single table row. If you want to consider a clump of joined rows as a single object, you will have to break away somewhat from the ActiveRecord pattern and write a domain object that subsumes your business pattern, most likely with core SQL calls to your connection.
But again: while you may be doing this level of optimization once your data gets to a certain critical mass, you will find that the ActiveRecord pattern is quite useful in getting you to that level, across several refactors, and allowing you to spend your time where you need to to build your business to that critical mass.
My Reccommendations
There are four standouts in my mind when it comes to frameworks. Note that I don't present Ruby because I honestly haven't taken the time to investigate it so its really fair to say that it may or may not be as suited for any given task as those I've ued and reviewed here.
- CMS: Drupal. If you have chosen another CMS over Drupal I honestly believe you have made a serious error. Its Admin area is a barrier but trust me: suck it up and push through the one obvious and superficial flaw that Drupal presents and you will be glad you did.
- Framework: Zend. Symfony is a very close second but Zend has the best written codebase and ORM I have ever seen and your code will be better for following it as an example.
- CRM: Sugar. If you are working on a back end heavily sales oriented app, Sugar will be a valuable asset. It may have some performance issues and is a bit heavy as an initial install, but it has a huge backing and adaptation; find out why.
- Minimal Framework: Cake. If you are working with a project that is made to scale small yet you plan on doing a smaller scale project and want the framework to be instanty recognizable Cake is a winner. It is extremely pared down yet sophisticated. Its not well suited towards pre-existing site makeovers but it has a devoted following and is as close to Ruby as exists in the PHP world.
