I have encountered a big deal of discussions abut eZP vs. Drupal, all of them stating different facts and opinions. So I hope this will shed some light on the topic...
Note that this are my own opinions and do not necessarily reflect the opinions of the eZ crew of eZ Community.
While planning a news portal project I had a discussion with two web developers about eZ Publish vs. Drupal. The goal of discussion was to determine which CMS to use as a platform for web development, not only for this portal, but also for future projects (big, small and medium). Besides as a CMS, the chosen platform would have been used also as a web application framework for developing custom web solutions and modules when needed. To sum it up, this decision was to determine our future cooperation and team development.
The two developers were cheering for Drupal and their main argument (which later came out to be the only one) was this article:
I was of course cheering for eZP, but I decided to enter this matter open minded (as much as I can), so I got myself a Drupal installation and started investigating.
I didn't look for "shiny" pieces and "wow it's got this gadget" stuff but I rather dived deep into the concept and structure of Drupal and compared it with eZP.
The conclusion was a big mail to the two developers so I'm rewriting it here completely as it was written.
***************************************************************************
The result of my two day Drupal vs. EZP analysis is the following...
1) Code quality
Drupal:
Awful! Code junk. OK, it has some good parts, but altogether non systematic and without any clear rules and order. It reminds a lot of Cowboy coding (here is a better definition than one on wikipedia: http://c2.com/cgi/wiki?CowboyCoding). For example, I took a look at the forum module code and there are absolutely no DB safe transactions, commits, ecc.
It doesn't have any abstraction layer. And don't you even dare to mention me this http://api.drupal.org/api/group/database/7 as an abstraction layer. By the way, look also at the example in the “Template system” chapter of this mail.
It's not object oriented! OK, the Drupal crew has a super nice explanation why this is good. Great! And all this modern web frameworks are of course wrong...
Furthermore, I personally believe (and also most of code developers I know) that the discussion object oriented vs. procedural in the context of web applications has no sense. Most of the web applications come down to manipulating resources through 4 HTTP verbs (GET, POST, PUT, DELETE). Resources naturally map to objects. Everything in web applications, except maybe helper functions for generating HTML and JS, naturally maps to objects. It seems to me that most intelligent procedural implementations will actually end up on objects. If you have a bunch of procedure calls which receive some “structs” or similar data structures and pass them around, effectively this is object oriented programming.
eZ:
Hi-class object programming model with great concepts and code. It has several abstraction layers and every single one of them can be used. I could talk and talk about it, but instead take a look for yourself:
Besides being object oriented it has a tendency to the HMVC pattern, the same tendency that most of the today known web application frameworks show.
2) Template system
EDIT: Later on I found out some more fresh info so before reading this chapter see this comment:
http://share.ez.no/forums/discussions/ezpublish-vs.-drupal/comment66630
Drupal has a regular PHP templating system, which can sound good, but my opinion is that this produces more chaos and damage than gains. We could enter a discussion about this topic, but instead I'll give an example...
In Drupal, to fetch 10 nodes you have to write this:
<?php
$result = db_query_range('SELECT n.nid, n.title, n.created FROM {node}',array(), 0, 10);
?>
and in eZ this:
{def $nodes=fetch(content, tree, hash(parent_node, 2, limit, 10) )}
But, bear in mind that this Drupal call only gets you the id, title and creation date, and for getting the actual content you have to do joins or make several query calls. In eZP all of this is contained within this same line of code.
The criticism that a CMS's own template language degrades performance doesn't stand, because eZP has a template compilation system which compiles all the templates into PHP files and executes this files. The refreshing of this PHP compiled files does not represent a problem.
Furthermore, Drupal seems more like oriented to theming existing modules, and eZP more to custom templates. It's enough to say that Drupal in it's core installation has a folder called “themes”.
3) Database structure
Drupal:
It doesn't have one. OK, it has one but what is it? It comes down to basic tables for node storage and core features. Almost every module I have looked at, creates some new tables in the database. Besides of getting a vast database, who can guarantee the quality of this tables and what about database integrity? And what about sharing data between modules?
Furthermore, this concept of DB scheme produces questions like this:
OK, the guy that asked that is pretty much an amateur that doesn't know what he's dealing with, but the fact that such questions even exist means that for adding any custom solution you have to think about creating new SQL tables and planning their structure.
In eZP you don't have such worries. Most of custom needs can be done through existing DB schema or some abstraction layer. If it's necessary, in eZP you can easily create and modify DB schema from XML definitions. OK, Drupal also has something like this, but is it powerful as this:
eZ:
With the concept of nodes, objects and ready made attributes, the need for creating new SQL tables for new functionality is eliminated.
And another interesting detail, on www.whitehouse.gov, the whitehouse web development team made a module that simulates eZP node tree structure. It means that there was a natural need for such a thing.
4) Framework/library
Drupal doesn't have it. Period.
eZP has eZComponents. Period.
5) Performance
We exchanged a lot of opinions about this one, and we all know what is the biggest worry (the article about the Swiss newspaper), but I'm still convinced that eZP can be setup and configured to work as efficiently as Drupal. I already did it on two big projects.
6) General impression
I cannot get rid of the impression that the whole Drupal system resembles very much to Joomla!
Besides that, the overall eZP development and ideology look far more serious and professional.
Of course, this is my opinions and I cannot say nothing more than expressing my personal feeling.
7) Comparison conclusion
It looks to me like we are comparing DOS with Windows.
Not to be misunderstood, in my lifetime I have done the following things in DOS:
- used LAN and sent messages through Windows Messenger
- played 3D games
- connected with FTP and SSH to remote machines (and used this actively)
- coded in PHP
- surfed the web with full HTML browser
- made a realtme version of the Scorch game
- used point&click GUI (not only Windows 3.11, but also others)
- used multitasking
- watched pictures and video (real video not the Aalib stuff)
- used instant messaging
- read and sent mails
- created programs for computations in mathematics and physics
- worked with databases
- listened to and programmed music
So, DOS can do everything what Windows can, and it can do it faster!
P.S. If someone is interested in how all this things can be accomplished in DOS, feel free to contact me. There are some things I still remember...
***************************************************************************
NOTES:
1) The result of sending this mail was...
The two developers never responded with counterarguments and they didn't become a part of the team for the project. I have chosen eZ Publish and started a fresh team of new young eZP developers.
2) Everything in this text is completely my own personal opinion, based on my experience as a web developer and “intuitive feeling”. If anyone disagrees with me or is offended by something I wrote, feel free to react.