As soon as the programmer opens up the guts of the Drupal source code they are faced with a nightmare. Customizing Drupal is not easy, as it is based on a poorly-designed, procedural framework, whereas Joomla is based on a well-designed, Object-Oriented, MVC framework. It also implements a number of design patterns such as listener, etc.
Even if you hire highly-skilled, (very expensive) Drupal programmers, there is a high possibility that your code will still resemble spaghetti, which will cause many problems in the future if you want to make further changes.
- In Drupal, views are stored in the database by default. This means you can’t have version control (such as SVN or GIT) and developers can’t collaborate on developing views. Drupal Core provides the ability to override default views in code, but this process involves extra development steps.
- Every new content type in Drupal corresponds to a couple of database tables. This means the database structure changes over time as the webmaster creates and changes content types. This is a nightmare for developers who like to create Entity Relationship Diagrams (ERD) when building web applications. You can never rely on your ERD because the next time you look at the database, the number of tables and the schema would be different.
- In Drupal, logs are stored in the database. All modern systems store logs in files. Storing logs in databases means they are very hard to access, analyse, and profile. A developer can’t use Linux tools (such as sed, etc.) to process and analyse logs. The process is slower and takes massive amount of disk space (lots of gigabytes) for database storage. It makes the system database grow unnecessarily and become inefficient. For a large high traffic site it is virtually impossible to query and analyse the logs. Additionally it cannot support log-rotation and archiving of old logs. Who in their right mind would store logs in the database? To address these issues, Drupal has introduced syslog, however it is not recommended for shared hosting environments and you have to go through many steps to disable dblog and set up syslog instead.
Firstly, Joomla is Object Oriented, but Drupal is based on old PHP 4 procedural programming (the dark days of php).
Drupal implements these design patterns which are old and known to be bad practice:
If you like to know more about programming bad practices, read my previous blog post: clean high quality code – a guide on how to become a better programmer.
However Joomla implements these design patterns which are modern, good practice, and used by the best frameworks such as symfony2, Zend, and enterprise programming languages such as java (including Struts and Spring):
- Object Oriented (including polymorphism, encapsulation, inheritance, etc.)
- MVC (Model View Control)
- Event Driven, Event Dispatcher, and Observer
Some of the Design patterns implemented on both Frameworks such as DBAL (Database Abstraction Layer) have been done better in Joomla. Joomla’s DBAL is almost as good as an ORM (Object-relational mapping). And if you really want to use a full-on ORM Joomla easily integrates with Doctrine.
Implementation of these modern practices is due to the continuous improvement that the Joomla framework and CMS have done over the years, while Drupal has stagnated. It is also representative of the active nature of the global Joomla community.
Joomla has a very clean core API but Drupal is written in ugly spaghetti code. An analogy would be to compare Joomla architecture to a Christmas tree and the Drupal architecture to a Buckyball.
branchesIn Joomla you have a tree hierarchy. The main trunk is the Joomla core. It has branches (the API) to which you can attach more branches (Components) or leaves (modules or widgets). So a component can be plugged in, thus integrating itself with Joomla’s security (Access Control Levels) and article management functions. Being a branch, it may have sub branches and it may even have a bridge to someone else’s branch. But to a large extent, there is minimum contact between various component branches.
structureIn Drupal, the shape is largely circular with numerous points across the surface called modules. When building an extension, you can hook into any or all of these modules. This tight integration means everything speaks to each other. This architecture is much less elegant and reduces the quality of the code of any custom features. On-going and long term maintenance becomes an issue with this kind of structure.
To implement this hooking architecture Drupal uses call_user_func() and other dynamic function invocation / reflection methods extensively. This means debugging Drupal is a nightmare using modern debugger tools. If you want to know more about debugger tools you can read: How to configure VIM and PhpStorm with xDebug to debug.
Furthermore this means you can’t use the click through feature of your modern IDE when you are coding. Also if you are using PHPStorm or other modern IDE’s the inspection and auto-complete features will not work as they wouldn’t know the return type of dynamically invoked functions.
PHP Specification Request (PSR) is a coding standard adopted by most modern enterprise frameworks such as Symfony2 to maintain PHP coding consistancy.
Joomla is PSR-1 compliant and provides a framework for PSR-0 custom development, however Joomla core is not PSR-0 just yet. A PSR-3 logging interface and a PSR-4 autoloader is also provided within the Joomla framework. Currently Drupal is not compliant to any PSR standard but will contain PSR-0 within version 8.
Performance and caching
Drupal on average makes 100 database queries per page load (for simple pages). Because of this and other performance issues relating to the hooking architecture, everything has to be abstracted and cached heavily which creates further complexity and resource (hardware) requirements. Joomla is a lot more lightweight and optimised. It has a much faster Core. Joomla’s recommended memory is 512MB while Drupal’s is 2GB.
Most benchmarks agree that, without caching, Joomla is faster and less resource intensive than Drupal. However some benchmarks consider Drupal faster when caching is turned on. But if Joomla caching is set up by experts and configured properly it can outperform Drupal even when caching is on. Also Joomla’s caching is a lot simpler and less resource intensive than Drupal which makes Joomla easier to use, update, and customise.
While you have Solr in Drupal to boost your performance for websites with large databases and a lot of users, you have Sphinx in Joomla which is written in native C++ code and is faster and easier than Solr. We simply do not need to install Sphinx on most of the websites because Joomla is fast and powerful enough out of the box to be able to handle very large databases under heavy traffic. However when needed Sphinx can provide a massive performance boost to Joomla making it many times faster than Drupal Solr bundle.
All of the above are strong indications that in contrary to common belief, Joomla is much better for developing larger more complicated websites than Drupal.