I've recently researched open source CMS's, primarily Drupal vs Joomla. Consensus (as you probably know) is Drupal is more powerful, flexible, yet more complicated, with steeper learning curve.
Something I'm having trouble understanding:
Drupal 5.1 has 277 files in 53 folders, weighing in at 2.2 MB (2.9 MB on disk).
By contrast, Joomla 1.5 beta-2 (released this week) has 3,332 files, in 633 folders, weighing in at 11 MB (20 MB on disk).
3,332 vs 277 files
11 vs 2.2 MB
How can a program so much smaller be considered more powerful?
In the automotive industry, there's a saying: "There's no substitute for displacement."
Documented some of my research findings here:
http://blogs.radified.com/2007/04/joomla_vs_drupal_content_cms.html#more
Comments
extensibility vs. built-in
One way in which Drupal is considered more powerful is in its extensibility. The core install may not do everything that the core install of Joomla does, but it's there are tons of modules to add on to it, and it's easy to write your own.
Also, the number of files may reflect differences in the templating systems for the output. from what I understand, Drupal 6.x will have more files because there is a push to separate out the templates for the output.
---
Work: BioRAFT
thanks
hi. thanks.
that makes sense.
how many modules are there, and where might i find them?
i believe joomla has something like 1600 extensions available (too).
1600... and so?
Size has never mattered. How many of those extensions will cost you money? How many duplicate functionality or conflict with others. A better question for you... Are there contributed modules that when combined with Drupal core modules help you build the site you want?. Module count doesn't matter a bit.
With CCK elements in core and the addition of CCK contrib modules we are finding that many contrib modules are becoming obsolete. Of course, as the community is growing in this new method of doing things the possibilities are opening up for even more things.
To find modules, click the download tab on top, then click modules. Filter by version number.
As to which you should use? You should use the one that will help you accomplish your goals and grow with them.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Software
I suppose that applies to the American automotive industry :)
After all F1 cars have 2.4L engines, and have had much smaller engines than that in the past.
But if we're just talking about folklore, with software bigger is regarded as being bloatier and slower.
Speaking in general - ie not about Joomla vs Drupal here (I don't know enough about Joomla to comment):
Comparing the size of the codebase is pretty meaningless without compaing the underlying design. It all comes from the design - if you start with a small well architected flexible design with lots of code reuse and aren't afraid to continually refine it at the expense of backward compatibility you can keep things smaller. If you just layer new stuff on top of old stuff and reinvent wheels you can easily end up with way more code. More code for the same features usually means a "throw in the kitchen sink" approach, or a slavish effort to prolong backwards compatibility (Windows is a good example of this) or just bad/lazy coding with little code reuse.
Plain ol programming is pretty easy, but good design/architecture/engineering needs a lot more experience and talent.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
answers bring more questions
i'm beginning to see the light on drupal' design architecture, which i've read about ("drupal has better architecture" http://cmsreport.com/node/543 ), but never really understood.
i actually like the notion of a small, lightweight core, designed to accommodate a variety of "modules"
found your modules, btw:
http://drupal.org/project/Modules
regarding this statement: "and aren't afraid to continually refine it at the expense of backward compatibility"
i like the idea of continually refining the code, even at expense of backward compatibility, BUT
are you saying drupal typically does not have BC? .. or *never* has BC?
i've read that modules designed for v4.7 are NOT compatible in/with v5.x
what do you do then when drupal 6 is released?
i'm guessing you install a fresh/clean new copy of drupal and migrate ccontent for old to new. yes?
surely you don't start over from scratch every time there's a major upgrade.
i am not familiar with term "CCK elements"
more answers
are you saying drupal typically does not have BC? .. or *never* has BC?
i've read that modules designed for v4.7 are NOT compatible in/with v5.x
what do you do then when drupal 6 is released?
i'm guessing you install a fresh/clean new copy of drupal and migrate ccontent for old to new. yes?
surely you don't start over from scratch every time there's a major upgrade.
No, you don't start from scratch. Drupal gracefully updates your database along with all its modules when I place the 5.0 files over top of my old 4.7 files and I had virtually nothing to worry about in the process. Many of my modules weren't yet up to date at first but within weeks all my important modules became upgraded and supported.
i am not familiar with term "CCK elements"
CCK allows you to create new content types with intricately designed custom fields and Views lets you look at and manipulate them every which way. CCK elements like field types and widgets (multiple methods of editing the data in a particular field type) allow CCK to take on any project for which elements can be designed to support it. This used to require custom modules and now it's just a matter of using CCK.
Case in point.
I showed Project module to my coworkers and we liked it but we wanted to change a few things. I rebuilt a new version that did what Project does using CCK the way we wanted it in a single day.
backward compatibility
so when the foresaking of backward compatibility is mentioned, you're primarily referring to plug-in modules?
thanks for the case in point.
is CCK an acronym for something? custom content k....?
CCK = Content Construction Kit
http://drupal.org/project/cck
Backward compatibility refers to the core API. So, that's way a module written for 4.7.x is not likely to run under 5.x without some amount of modification. This modification may be trivial in many cases (see: http://drupal.org/node/64279 for example, if you used the function module_exist() which was renamed to module_exists(); or if you use user_mail() which was renamed to drupal_mail() and needs slightly different parameters)- for some of my modules, the update took less than an hour.
---
Work: BioRAFT
Backward compatibility
Drupals API isn't fixed from release to release. Only a fraction of it usually changes, but it is generally enough that it is rare for modules or themes written for the previous release to work unchanged on the new release (some simple ones do though). There are well written upgrade guides for module and theme developers to follow though, and it usually isn't much work.
The upside of these changes are that Drupal rapidly improves from version to version - there are no qualms about replacing crufty or clunky code. Each new version of the API gives developers more scope to easily change the way Drupal behaves.
Your data is forward compatible though even if your custom code base isn't, Drupal will upgrade your data in a new release.
CCK - Content Creation Kit. In 4.7 it was a module that allowed non developers to create their own custom node types from a collection of extensible field types. In 5, part of CCK moved into core and allowed you to make new basic node types. The CCK add on module is still needed for adding custom fields to node types. There is a large eco system of modules building up around extending CCK - it is a powerful solution.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal