Deploying and maintaining websites used to be quite the ordeal, especially if you had content intensive requirements or clients who wanted to be able to update key design features such as navigation on a regular basis. While approaches for how to manage that process improved from the early 90’s through to early 2000’s there was still a great deal of manual coordination and update required. Changes in scripts deployed inline needed to be adjusted in every page deployed. Also, sometimes the pages design rendering was inconsistent from one section of a site to another - this too required polishing to get just right. The addition of CSS (cascading style sheets) and external scripts helped but pre-CMS website development was still a significant challenge – and this was for sites with relatively simple expectations for application or database support.
In the late 1990s and early 2000’s, SharePoint and a whole slew of commercial portal products hit the market, targeted primarily at enterprise users. These types of products offered the chance to build sites without quite so much manual design, but the products soon became fairly specialized in their support for integration with larger back-end systems. That specialization and the cost involved with this class of system made them unappealing or unrealistic for the majority of website developers. At the same time all of this was occurring, the web development community had amassed an ever greater array of applications that could be plugged into site development. Many of these apps at first were built using CGI and later PHP became the standard (although many languages have been used including .net). By 2005, there were several groups that had effectively combined a number of these apps into coherent platforms – those platforms shared the same core characteristics:
For our purposes though, Web Publishing within the WCMS involves very comprehensive features (some might say almost limitless) for design control and application extension. So, for all intents and purposes, the platforms have become ubiquitous for web development – supporting just about any Use Case that you can think of – everything from a simple site, to a community forum, to a magazine or an online store. You can do all that and more, and in a fraction of the time it previously required.
Value Proposition of the WCMS
Why is all of that important? Well, adoption of a WCMS translates into the following value proposition for most web developers:
WordPress – This WCMS began life as blog platform in 2003. The first CMS features were deployed across two releases in 2005 and by 2008 WordPress had shifted from being primarily blog focused to be a full-featured CMS. One of the key differences between WordPress and Joomla historically had been that many of the WordPress blogs / sites began life within WordPress's hosting environment (what we’d now call the Cloud). WordPress is used in 60 million websites (although a good percentage of those are purely blogs with little functionality used – more or less equivalent to blogger.com).
Joomla – Joomla began life as a commercial product called Mambo in 2000. Shortly, thereafter an open source version of Mambo was released and eventually the Mambo project forked into other projects including Joomla which launched in 2005. Mambo / Joomla was built to be a CMS from day 1. There have been approximately 30 million downloads of Joomla since 2005.
Both platforms support very large feature sets, although evaluation just on the competing lists doesn't tell the whole story – in other words, they both look equally impressive on paper. Before we can rate them however we’ll need to add our remaining criteria; those are:
So, given that popularity is already factored out, we could assign a 20% weight to each of the criteria listed above and we might rate each area from 1 to 5 (1 lowest, 5 highest). Here’s our score card:
There are those who might say ratings are determined in part by which tool you used first. In our case this doesn't apply, as over the past 15 years we've worked with more than a dozen different CMS and portal products and hundreds of similar scripts that were eventually pulled together to build these types of WCMS platforms. For us, the true measurement is how long does it take to build using one platform versus another and then how much of that is due to the platform itself (as opposed to unique requirements). For those of us in who work in IT and have had to evaluate dozens or even hundreds of different tools over our careers; we’re able to develop a certain level of objectivity when contrasting technology.
So what do these ratings really mean; here are some associated observations:
Bottom line – in the WordPress v. Joomla battle, Joomla wins in most categories (in situations where an organization hasn't already invested a lot of time in one or the other). How long this will remain the case is hard to tell, but based on our review it would probably require several major architectural changes in the core WordPress platform to complete the shift in its evolution from blog platform to WCMS.
Copyright 2013, Stephen Lahanas
 |
| Old Timey Web development has a strange connection to Married with Children - there may be a similar link between Mobile development and Modern Family... |
In the late 1990s and early 2000’s, SharePoint and a whole slew of commercial portal products hit the market, targeted primarily at enterprise users. These types of products offered the chance to build sites without quite so much manual design, but the products soon became fairly specialized in their support for integration with larger back-end systems. That specialization and the cost involved with this class of system made them unappealing or unrealistic for the majority of website developers. At the same time all of this was occurring, the web development community had amassed an ever greater array of applications that could be plugged into site development. Many of these apps at first were built using CGI and later PHP became the standard (although many languages have been used including .net). By 2005, there were several groups that had effectively combined a number of these apps into coherent platforms – those platforms shared the same core characteristics:
- Holistic control panel interfaces (not unlike those used by web hosting providers).
- Content management features – this was focused around page publication and abstraction of content development from page deployment.
- Style blocks – the ability to segment off panels or blocks to position specific content or application features.
- Application support – development of core code and APIs for interaction.
- Shared data structure – single instance DB to support platform and all applications.
- First, it made these platforms universally available to all and any web developers for any purpose they could imagine.
- It ensured a growing set of application plugins designed to run on that platform would be available. For anyone who had worked with the more expensive portal software or even SharePoint, this difference is striking. The lack of a community to tends to translate into limited capability and an overall high cost of ownership as most added features end up being custom coded.
For our purposes though, Web Publishing within the WCMS involves very comprehensive features (some might say almost limitless) for design control and application extension. So, for all intents and purposes, the platforms have become ubiquitous for web development – supporting just about any Use Case that you can think of – everything from a simple site, to a community forum, to a magazine or an online store. You can do all that and more, and in a fraction of the time it previously required.
Value Proposition of the WCMS
Why is all of that important? Well, adoption of a WCMS translates into the following value proposition for most web developers:
- These platforms support rapid prototyping – getting the site up and running actually becomes easier than the style-sheet work – although with the superstructure up – it becomes feasible to highlight many more design options simultaneously.
- Using these platforms allows smaller shops or teams to handle more simultaneous work (in most cases).
- Using a WCMS allows for plug and play application features (and potentially this could extend to all application features of a site). Custom configuration may still be required but the level of effort is an order of magnitude smaller.
- Setting up training and maintenance processes for any sites developed using these platforms can be consolidated to one effort (e.g. the first manual and training class you prepare becomes the template for all others with relatively little rework required).
- The mobile strategy and main site can be planned and rolled out in tandem.
- WordPress (most popular)
- Joomla (second most popular)
- Drupal (probably third)
- DotNetNuke (in the running).
- It implies a more dynamic community which means the software will keep getting better and more comprehensive.
- It also implies that we will have an ever growing pool of new (plugins or extension) apps to choose from.
WordPress – This WCMS began life as blog platform in 2003. The first CMS features were deployed across two releases in 2005 and by 2008 WordPress had shifted from being primarily blog focused to be a full-featured CMS. One of the key differences between WordPress and Joomla historically had been that many of the WordPress blogs / sites began life within WordPress's hosting environment (what we’d now call the Cloud). WordPress is used in 60 million websites (although a good percentage of those are purely blogs with little functionality used – more or less equivalent to blogger.com).
 |
| An example of a Joomla-based solution (circa 2011) |
Both platforms support very large feature sets, although evaluation just on the competing lists doesn't tell the whole story – in other words, they both look equally impressive on paper. Before we can rate them however we’ll need to add our remaining criteria; those are:
- Ease of Administration – this is generally typified by the admin console but can extend to other features or considerations.
- Design Flexibility – This relates more to what is possible from a design perspective.
- Design Ease of Use – This relates more to how hard is it to conduct those designs.
- Content Management – Each CMS has its own idiosyncrasies.
- Application Functionality (extensibility) and integration of that within the platform – Sometimes the same apps developed for WordPress and Joomla behave differently in either platform. Also, there are some apps you can find for one but not on the other.
So, given that popularity is already factored out, we could assign a 20% weight to each of the criteria listed above and we might rate each area from 1 to 5 (1 lowest, 5 highest). Here’s our score card:
|
Category
|
Joomla
|
WordPress
|
|
Ease of
Administration
|
5
|
3
|
|
Design
Flexibility
|
4
|
4
|
|
Design
Ease of Use
|
5
|
3
|
|
Content
Management
|
4
|
2
|
|
Application
Functionality
|
4
|
3
|
|
Totals
|
22 (of 25) 88%
|
15 (of 25) 60%
|
There are those who might say ratings are determined in part by which tool you used first. In our case this doesn't apply, as over the past 15 years we've worked with more than a dozen different CMS and portal products and hundreds of similar scripts that were eventually pulled together to build these types of WCMS platforms. For us, the true measurement is how long does it take to build using one platform versus another and then how much of that is due to the platform itself (as opposed to unique requirements). For those of us in who work in IT and have had to evaluate dozens or even hundreds of different tools over our careers; we’re able to develop a certain level of objectivity when contrasting technology.
So what do these ratings really mean; here are some associated observations:
- In the most important metric, time to develop / complete / deploy a site on Joomla on average took 25% or less time than WordPress.
- The WordPress multiple blog (Network feature) is still not quite ready for prime time.
- WordPress was built first for blogs and it shows, the design metaphor is little clunky and the widget (design blocks) can take on a life of their own – making design much more time consuming than it should be.
- You’re more likely to run into application / widget compatibility issues on WordPress.
- WordPress does though seem to be getting some apps that aren't being made available on Joomla, some of these are more focused towards the enterprise which is a serious long-term issue for Joomla (if it is to remain competitive).
- In Joomla, management of page (CMS) taxonomy is definitely more complicated than WordPress, however this is a relatively small part of the overall web development effort and isn't too hard to get used to.
- Both WCMSs have suffered major security flaws in the past, this will likely continue to be the case (but isn't nearly as complex as dealing with the Microsoft stack and SharePoint).
- One of the biggest issues we ran into with WordPress was the embedded editing capability (and errors associated with it). The editors (which can be added as extensions to the administration consoles) seem to perform better on Joomla – this is a big deal from a content management standpoint.
- Overall, we found it harder to achieve some of the core design functionality in WordPress than in Joomla (everything from placement of blocks to the ability to run content sliders etc.)
- The application update notifications in WordPress are nifty, but don’t completely make up for other failings (in getting them to work properly for example).
- The WordPress blog moderation console is pretty cool and shows where WordPress really excels. However, for many web Use Cases, this is unnecessary.
Bottom line – in the WordPress v. Joomla battle, Joomla wins in most categories (in situations where an organization hasn't already invested a lot of time in one or the other). How long this will remain the case is hard to tell, but based on our review it would probably require several major architectural changes in the core WordPress platform to complete the shift in its evolution from blog platform to WCMS.
Copyright 2013, Stephen Lahanas
