Joomla! versus Drupal

In the development community, there are many discussions and debates over the best platform to use for a web application build. The discussions usually come down to three platforms: Drupal, Joomla!, and WordPress. Businesses all over the planet need websites, so a large number of non-developers make their living building sites, and when their livelihoods depend on these platforms, they can become territorial when a discussion arises about different architectures outside of their comfort zone. I think that's silly. The main premise I want to emphasize to the reader is I am not suggesting one is better than the other. To me, it is like arguing about who is the best player in football. Is it fair to compare an offensive lineman against a defensive player? The evolution of that discussion recognizes the positions of the players, and a better debate is framed when the discussion becomes who are the best offensive players, and the best defensive players. The best application framework is in the eye of the site builder. When I compare architectures, it's like comparing a hammer to a screw driver; they're just tools, and I'm a developer first and foremost. If there's money on the table, a site is getting built. With that said, if the builder is not a developer and is tasked to build a site through the admin UI, then this isn't even a discussion, as Joomla! makes the most sense.

There are indeed tools that would be crazy to use for certain jobs. In my Unix systems programming days, I wrote in C, as our software did a lot of low-level stuff with devices and the operating system. For Windows applications, I used C++ so I could use the MFC library in Visual C++. I used PERL on our Unix servers to handle and manipulate customer data. At that time, PERL was the best choice for me to write web applications. PERL is interpreted and not typed, so I was able to assemble scripts pretty quick and build dynamic CGI sites. I could have written web applications in C, but that would have been insane. I used PERL because I knew PERL and could code quickly and make changes rapidly.

The analogy I give when describing how I approach a new application, architecture, or whatever, is it's like being an experienced airline and Air Force pilot for over 20 years, and one day learning how to fly a small single engine Cessna. The learning curve for the experienced pilot will be different when learning to fly the small plane, versus a new student pilot with no flight time experience. The experienced pilot already “gets it”, and probably enjoys not having to go through the lengthy pre-flight check list and the stress of carrying lives. He just taxis out and takes off care free. The new pilot, however, will be learning with no previous experience.

WordPress

I take WordPress out of the discussion. It is a very powerful blogging system, and has the majority of the CMS market share by far because it is easy for a non-developer to launch a WordPress site, appealing to a larger market. WordPress has stability and name recognition, and is a great product, but it isn't built for development. The context of my comparison is what architecture is the best for a custom business site. When WordPress bound businesses look to grow or add complexity to their site, they start looking elsewhere.

Determining Factors

These two open source architectures are written in PHP and both give me, the developer, a nice API set to build and extend whatever I want. In the end, there is nothing that Drupal can build that Joomla! can't, and vice versa. Therefore, when deciding what platform to use, my personal preferences, skill sets, and development philosophies paved my decision path. If requirements change in the project, or a customer wants to add more features, I want to be able to say "Yes" as much as possible, while keeping the development pain little as possible. The system needed to be flexible. I wanted a system where I could do a lot with less code. The system needed to have an active and passionate community, where core commits are flying by and the community is always looking to consolidate direction. Performance is always a factor, and both systems seemed to be pretty scalable. I wanted the presentation layer to be separate (as much as possible) from the model. The system would need to play nice with JavaScript and any flavors of frameworks or libraries. Seamless user management and access control were very important, as that can get messy. Creating custom content pieces should be pretty easy, as well as joining different content pieces together seamlessly. I didn't want to pay for modules, and as popular trends pop up, the modules should as well.

The Communities

Joomla! is a more rigid architecture with a finished admin menu right out of the box that allows the admin to get right to work. Drupal comes with a generic admin user interface that UI dependent site builders do not like, and the common heavy duty modules in Drupal 7 must be downloaded and loaded up, which is inconvenient. Even the WYSIWYG editor must be installed. Most of my Drupal pain will be solved in another year or so when version 8 is released because these common modules will be included in core. Some Joomla! extensions seemed to have a price tags, and I couldn't quite get my arms around the overall development community, where I was able to grasp Drupal's a little better. I liked Drupal's centralized module repository, which I believe keeps module developers in collaboration and greatly reduces overlap and rework. I didn't have any problems finding modules for the popular stuff, like social media functionality. Every project in Drupal shows maintenance statistics on the module, with a count of downloads and open bugs and issues. I can quickly gauge the popularity of a module and how much TLC the maintainers are giving. If it has a lot of issues and not a lot of commits, I probably wouldn't use it. This all comes down to something breaking, and how much support for the module do I have. If a module developer is unresponsive, I'd have to troubleshoot and fix the problem myself, so the more I can reduce that support burden, the better. Ultimately, I'm a believer that a developer shouldn't install any open source code on a production site if they don't know how to fix and support the module themselves. If the author is good and can support it, then that's gravy, otherwise, the certainty of fixing a broken component relies on the hope of a developer dedicating time for the support and a quick fix.

The API and Architecture

As an experienced artistically challenged developer, I approach the platform from an under-the-hood and development perspective. The relevant content is selected from the database, structured in HTML, and sent to the requesting browser. This is where custom web development happens. Neither Joomla! or Drupal architectures are rocket science. Joomla! is an object oriented MVC architecture. Many developers think they know object oriented programming, but really don't. To customize in Joomla!, you really need to know object oriented programming in PHP. While that is no problem for experienced developers, my junior programmers may or may not have a learning curve, and I didn't want to spend time and money teaching. Junior programmers do a lot of the programming grunt work, and they come and go. Their job is to essentially write their code segments the best way they can, we do a code review, then I, or another experienced developer, tell them what to change. I want my junior programmers to master the basics of programming first, and web programming second. I think a dependency on object oriented programming adds a level of complexity in that regard. If web design was pretty strict and trends and technologies didn't change frequently, it would be less of an issue in this case. No, I'm not saying object oriented architectures aren't flexible or scale. I'm saying the architecture needs to be flexible. Drupal 8 is going to use the Symfony framework, so Drupal 8 is moving towards the object oriented MVC architecture as well. With that said, any projects we do in Joomla! will be done by a higher caliber programmer. Clients change their minds and want new functionality. When a client base adds up over time, there is more support to do, and more and more requests for new functionality. The last thing I wanted to do was worry about how the site was designed, as changes can call for a total refactoring if built in a rigid architecture. The Drupal architecture makes this very easy with its hook API. If we want to do something custom, we simply write a module, define hook functions for whatever event we're dealing with, and register it with Drupal core. When the event happens, Drupal invokes our function and passes pertinent data objects for the function to operate on. You can get as complex as you want, but that's the basic premise of the hook API.

User Management and Access Control

This is an area where Drupal had a very clear advantage when compared to Joomla!. Managing users, their roles, and permissions to access content is a critical part of designing an application, and Drupal handles this so fluidly out of the box. When I listen to customer requirements and we get to the users of the system, I just nod my head knowing we can do it whatever it is very easily.

Drupal Views

This was another deal maker for us to favor Drupal. The power of the Views module gives us an incredible tool to present content in infinite layouts and presentations. This module alone (which will ship with core in D8) doesn't even require the site builder to touch any code. The reality is with Views, the Drupal contextual system, taxonomy, content creation, and a few other modules, you can build very complex and highly functional sites without touching any code. There are similar extensions in Joomla!, but developers I talked with said Drupal's is light years beyond Joomla!.

Full Circle

Joomla! is powerful. Drupal is powerful. In the end, how I wanted to approach web projects was why we utilize Drupal more often. If a client throws a bunch of money at us and tells us to build in Joomla!, then no problem, and we have the team to do it better than anyone. So far, Drupal has been a great choice for supporting clients and delivering on projects. Does Drupal have issues? Good lord yes it does. No platform is perfect.