The Framework is dead. Long live the CMS.

I think a strong framework is still a good basis and a CMS/other product can be built on top of it. My major gripe with Drupal is it is too CMS-ey. If you want to do some things that don't need CMS functionality or how Drupal's main modules/core -tries- to do it, you wind up working harder to extend it to basically make it more structured and less formatted.

I'd rather see Drupal core, Views, etc. spit out raw information, and then additional modules that you would stack on top of Views for example to render it out how Views does right now.

I don't like that Views loads a million includes by default; I'd rather only have it load the ones that I want. However, the Views module was designed as both a query builder, executor, AND formatter. I'd like to split that piece into a separate module, ideally.

Drupal is a much more extensible solution than WordPress or other CMSes because it does provide more of a generic framework than just a "CMS" - I actually dislike when people call Drupal a CMS as I consider it still a framework packaged with CMS functionality by default.

All the features you list above I consider to be part of a framework. Some of the "frameworks" out there are more "libraries" where it's a bunch of stuff to enable you to make more things, but out of the box doesn't do much.

IMHO, Drupal's power is it's framework+features out of the box. However, there's a little bit too much CMS functionality in there. Reducing it slightly would provide the power of user management/authentication/etc., utility functions, theming, session handling, modularity/extensibility, without the CMS or extra overhead for CMS-specific functionality. If you want the CMS functionality, turn it on. The hook concepts and such are extremely powerful and allows nearly infinite extensibility, not just for "Content Management" :)

Without doubt Drupal is one of the best CMS' currently out there, but as with all Content Management Systems there's a lot of code bloat, 95% of which is redundant for most uses.

If you are creating your own ("god forbid") app then this isn't a problem

I agree that a CMS get you far in "just a click". However, for the past few years I've been working with one of the aforementioned CMS's and it's been a frustrating experience. The system is getting in the way rather than helping me. So for my next project I'm basing on a framework instead. If you go with a CMS, be prepared on having to do things the way the CMS wants you too. If the CMS hasn't thought of your use case, you're out on deep water.

Regards,
Per Thulin

Hm... definitely an interesting article. I've some thoughts about this topic myself, as I quite recently was involved in creating two web sites/web applications, one using a CMS (Drupal), one using a Framework (Rails).

A bit of background: I started tinkering with Drupal some time ago, when 6.x came out, and also created some (if somewhat minor) code contributions. I started using Rails just a few weeks ago when I started the second project - and I have to say that I prefer it over Drupal.

Why? Well, there are some things that have always annoyed me when using Drupal, and I have found that most of them are gone when using Rails.

The one that I maybe found most annoying is that Drupal is really UI-centered. You install Drupal and some modules, and then you use the admin interface to customize your site.
At first, I liked that. But it's quite a tedious process - which would be no problem if you only have to do it once. But, say, you want to add a new feature, tested out some module on your local dev system, decided that it's good, and want to use it on your production site.
So... you can check in the module code into source control, but you cannot check in the configuration! I really don't want to repeat all the steps I did locally on the production server. The Features module is a great step forward here, but it only solves this problem for some modules.

When you use a framework, everything is in code. There is no setup process you have to go through first (Drush could help here - but only when using Drupal 7), so setting up a development server is really easy! People can just check out the source code and start developing a new feature, tweak the design or whatever. And in the case of Rails, you can deploy code, install additional modules ("gems") and run database migrations by typing in just one single command (using Capistrano).

I believe that Rails actually saved me time and increased my productivity in this project, and I really wish I had used it for the other project, too.

I hope that didn't sound like a Drupal bashing or something - after all, I still like Drupal! So maybe you can help me there: if you want to add a new feature to a drupal site, how do you do it? I've always wondered how "Drupal professionals" handle such problems, so I'd love to hear from you.

I've felt that way for a while, to me using a framework for a website is wasting time reinventing the wheel and you also end up leaving out alot of features you'd otherwise have in a framework.

I'd say the framework is not dead because the CMS in this case chooses the framework. So if you select a CMS to build on top, I'd suggest you also look at the frameworks it uses. I like Magnolia CMS for that reason. A solid base foundation rooted in Java and JCR to build on top of.

presentation about this subject from last years magnolia conference

I think Drupal8 could be a step in the right direction towards making Drupal more frameworky which might please some critics who work on real custom stuff that don't need a CMS.

A good example is that I used to do applications for state government and Drupal wasn't a great fit for that for several reasons. A small-core focused Drupal would have been lovely. Drupal underneath is really nice so if you can decouple things like the user system then that might give you 1 CMS/framework to rule them all and wouldn't that be lovely?!

i think i couldn't agree with you.
many CMS easy for general purpose and general user. But base framework more flexible for developer, so framework will be still exist side by side

Using CMS as a base for your work is not secure, hard and not considered a good scenario.

And to people who think that Drupal is the best, I have never worked so hard to make some basic functionality out of Drupal.

For me, the idea that a framework is not the better choice when creating a "website" is not new. Frameworks are especially useful for create web applications, CMS are more useful for creating websites. This reasoning follows a simple principle: There is always a right tool for the right job. Frameworks were never made to create "websites".

CMS and Frameworks like CakePHP are very very two different things.
Drupal it's the best choice for CMS, but can't be for all the things.
Like Aziz already say, "There is always a right tool for the right job."
You can't be so radical.

Well, obviously, if your looking to manage content, a CMS is perfect, but if your doing anything more complicated, like building a backend in php and a front end in flex, well, drupal is just wrong.

Your doing web developpement, most probably your right about your job and your projects, but the tree is hiding the forest.

CMS sucks!!..)) RAD frameworks like ror, django, symfony are future CMS it's a past. CMS it's a whole bunch of s**t. Code from different devs .. ha-ha. None respected company ecpecially IT company don't be using CMS. CMS security is sucks to...

I agree that unless you're creating business logic, then a CMS is definitely the way to go (in the language of your choice). However there is, as always, a middle way. Depending on the project, I tend to prefer taking the CMS and injecting new business logic into it with a combination of JavaScript and a framework, with the CMS acting as a candy shell to keep everything tidy. My personal combination for this is Wordpress with CodeIgniter and jQuery, but to each their own.

The real exception that I would take to your post is your choice of CMSs. Drupal (unless it's changed radically since I last looked at it) is complex and requires you learn a whole new quasi-language. Joomla is bloated beyond belief. Concrete5 and ModX are both horribly documented, etc.

At least with a framework, I know how to take it apart, as opposed to a badly-written CMS, which might require just as much time to decode as it would take me to code it straight up.

If you're using a CMS for more than content management, than you ARE using a framework - even if it doesn't have a name.

Many CMS systems are becoming frameworks in their own right now. What about CMS systems built on frameworks?

Not everything is about content. I've done a lot of work for companies who originally had their "bespoke" systems made in Drupal/Joomla but the development costs to change basic things were overwhelming for them so they turn to a bespoke system made in a framework.

A framework makes sense and they're all maturing to a point where the area of CMS/Framework is becoming even more blurred. There are many plugins/modules you can throw into a framework to support a CMS system now without much fiddling.. Then you can do all your bespoke development as you normally would.

Square peg in a round hole doesn't always work.

If you're on a tight budget and limited time then I guess a CMS is a good solution. Personally as a web developer I want to code. I don't want to be just stitching random modules together to make them work and do a half-assed solution to my clients problem.

You can't make a statistical point based on the number of projects that you see. You are simply in a market which is generally served well by using a CMS versus building one from scratch. There are also shops out there which see the opposite numbers because they are in a different market (especially prominent Rails developers considering there are no Drupal equivalents in Ruby that I know of.) I suppose this mostly depends on how you market yourself.

As others have mentioned, you need to use the right tool for the job. A CMS will never be the right tool for all jobs (or at a great enough percentage that it no longer makes sense to continue building frameworks.)

Generally I see the dividing line sitting between web applications and business portals which often seem to be not too far removed from the days of brochure sites. As an example, Facebook probably could have been originally built on Drupal. Eventually that application would have evolved itself out of Drupal due to scalability issues and feature changes. A great example is the story of how The Onion moved from Drupal to Django.

In some cases, an application has requirements that so little of a CMS could serve that it just makes sense to start out from scratch. However, I certainly wouldn't want to have to build a CMS for every client site which comes through the door. Generally the demands I see for timeline, budget and features call for a CMS, but again, that's just my market.

If you think about very home office solutions where the client is not interested in extensibility, maintainability, security and much more from the field of enterprise requirements than you are right.

, you are totally right.
I

From what I've seen, you have this backwards. The great era of the CMS was 2000 - 2006. The CMSs were overly rigid, so frameworks came along to replace them.

Back in 2000 there were CMSs like MoveableType and PHPNuke and, on the high end, stuff like Radio Userland, and then on the very high end there was Vignette (which cost over $100,000). Around the year 2000 the big criticism of CMSs is that they were too expensive. Then there came a flood of open source CMSs. An important turning point is when MoveableType raised their prices in 2003. This lead to a lot of development of open source CMSs such as TextPattern and Blossom. Out of all of this activity, there eventually emerged WordPress and Drupal.These eventually got to the point where they were able to offer features that were comparable to what Vignette had been charging $100,000 for, but WordPress and Drupal were both open source.

Nevertheless, the old criticisms of CMSs remained: too rigid. Thus, in 2005 Ruby On Rails ignited intense interest as a framework, and lead to a lot of work on frameworks in almost all languages. And that continues to this day.

In so far was when to use a CMS, versus a framework, and how much each tends to cost, more information is here:

http://www.teamlalala.com/blog/2008/11/12/how-much-do-websites-cost/

Also, from what I've seen, the best CMSs are built on top of frameworks, so it is good to know the framework. For instance, Apostrophe, which is built on top of Symfony:

http://www.robertspeer.com/blog/apostrophenow-a-cms-so-easy-even-your-mo...

So for an update... The framework isn't dead. It's just sitting behind the CMS systems ready to break out some smooth moves when you want to put some plugins/modules/changes together.

I'm guessing this is the 'year' of the CMS-Framework.

I have been custom Apps for a while now, usually using WEB TCL and perl, so what is the actually learning curve for a CMS I have poked around at Rails but always found Frameworks Restrictive, I have tried few other frameworks, again it comes down to usability I can normally find TCL and Perl on almost ever *nix box out there that runs Apache web servers so what is the learning Curve for CMS comming from my background?

I've heard and agree with the idea that Drupal is a framework, functioning as CMS. And when building a website, why not start with something like Drupal, and contribute to making it better if it doesn't 100% fit your needs. It won't work for everything under the sun, but it can do quite a lot.

I've used Drupal for 2 years now and I enjoyed it as a web designer because of CCK, Views, and Image Cache. You can really architect information in Drupal.

However, Drupal has a few nuances that just won't float for all designs. I would say Drupal brings you about 80% of the way. It's that last 20% that makes your website better than others though.

Creating a custom website with a customized Admin UI definitely adds value for a customer because THEY will love using their new web application instead of hating how Drupals admin UI is laid out.

Drupal 7 admin UI improved, especially in listing content. How Drupal 6 didnt have that simple functionality is rather ridiculous.

Drupal is also slow for people logging in because it stops caching. Wow that sucks, now people who were enjoying a relatively fast website are now downloading huge pages with 50+ http requests. Awesome....

Drupal is the best open source CMS if you need to architect information and do not have a PHP/SQL developer to assist. But if you got the time to learn how to reinvent the wheel, you'll be driving your designs further than you ever have and your clients probably won't hate you for giving them something they don't like to use.

So sorry to say but I disagree with you. As a former Drupal user I'm aspiring to use Frameworks more. You're going in the wrong direction in my opinion.

Totally agree with the previous comment..
If you know how to code then you should go for a framework.

Drupal 7 is waaay too slow.
Big bloated beast...if you put d7 in shared hoting without apc and your site starts getting traffic you are doomed:/

i disagree for this framework is better then cms...

Thanks for this excellent article with all comments, it opened my eyes on Frameworks as an alternative to CMS. I am struggling since a few days searching for a moderately easy solution to implement a CMS for a quite simple and rather static site, but with a very specific Backend for a client and it looks like no existing CMS can do the job. I'd like to find a CMS that has no Backend UI at all - only a well documented CMS API, with all necesary CMS functionality that I could easily use to create my own Backend UI, and add to the UI some client-specific behaviour and functionality. Perhaps it will be better to use some Framework than hack into existing CMS and rewrite their UI.

Small and medium projects -> CMS
Large projects -> Framework

If you have a client that needs a very special design then Drupal can become hell, and you should have used a framework. Even if you then have picked a framework this can also be hell.

My preferred option is often to use components from Zend and Pear, or components from other places that fit my purpose, and roll out my own framework - this will often mean that your have full control over the building of your website.

If people needs a CMS then Drupal is often a great choice, but if the features become highly specialized then the Drupal system can become an obstruction.

So since last viewing this others have seen what I thought was happening which is the unraveling of Drupal as a whole.

Many of the good developers making useful plugins are leaving and probably not coming back. The links below give a good overview of the situation at hand.

http://www.unleashedmind.com/en/blog/sun/the-drupal-crisis
http://www.unleashedmind.com/en/blog/sun/crisis-conclusions
http://www.drupal4hu.com/node/300

Well I'm not a guru in coding as well as in a CMS. I am learning as well as coding in PHP since from last two years and has created very strong base of web programming. Things were going good, I learned bunch of technology as time passed like JavaScript, AJAX, jQuery and etc. Now I was entering into IT market, and got surprised. In now a days I observed more than 80% peoples want their sites to be built using any CMS like Drupal/Wordpress and many others. Suppose a person who wants to his website build by other, their is 90% + chances that he does knows about programming very well. That's the main reason why he wants his website to be built using a CMS where he can maintain his website by using easy to use admin interfaces instead of hiring any IT person for little changes. That I personally think, is the main reason why CMS are getting high.

Now here comes a big question in front of me. SHOULD I LEARN A WELL KNOWN FRAMEWORK OR A MORE DEMANDING CMS. However I tried learning both and there are obvious problems with them both.
First: Both requires a good learning time. Means you have to commit for any one for at-least some months or may be upto a whole year. Unless you commit for any one, your mind may float between them choosing a best option, lol....
Second: Suppose I choose to start with frameworks, I will dedicate my 90% time designing logic and when it comes to look and feel, I will be either tired or monotonous.Means framework may kill your good UI. And if i choose a CMS it's absolutely either going to kill the logic or I will be their devoting 90% of my time stiching plugins and templates together.

So could not decide yet what's better a CMS or a Framework and Now Want to here from you guys......

From all of the comments i understood one thing i.e,

use CMS to build wonderful websites.
use Frameworks to build wonderful web apps.

I Recommend you choose what to learn based on your immediate need but when you are free you can always just check the other one as knowledge is always precious.

Good strong post, but i think the right tool for the job still applies and thankfully we still get requests for projects that are creative enough that a great framework is the best starting point. For those situations thats Rails for us.

Other times silverstripe is a much better choice because of the functionality it brings. Its also built on a framework good enough to allow for lots of customisation & creativity without the pain.

Iv'e found other CMS's fall short of claims they can expand beyond their core expertise - their architecture just isn't adequate for the task. I'm not talking about Drupal though, i know some fine people who say its great. Never used it.

I definitely don't agree that if the project budget is huge over a long period of time the foundation doesn't matter though. Thats exactly when you need to make sure that the foundation allows for your requirements to define the solution in the most painless way possible.

I am both a designer and developer, and I love Drupal. However I have been asked by a client to recommend a CMS for multimedia - it's a Design school specialising in still photography and video so they need a CMS that is great for streaming large files and working with images.

Drupal 6 is terrible for images (Even simple galleries need upwards of 15 modules and fine grained access control is still a dream), and Drupal 7 still hasn't really completed the Media module. I have used Joomla and I really don't like it. Can anyone tell me what Wordpress is like for a website with mostly video, audio and image content?

Wordpress has strong image capabilities. They recently updated the upload & edit systems & its really good - its nicely made too with a backbone based architecture. One thing to consider is the image sizes / thumbnails you are going to need. Its worth having a good think about all the sizes you will need and specifying them in the functions.php file. WP doesn't create them on the fly, it makes them on upload, so its slightly tricky to change thumb sizes later (although there are good plugins to do this)

For video, its fine. The main thing you need to consider is formats, and how you are going to playback movies - I've used longtail player before which has been really good - it plays html5 formats & has a flash fallback so all devices are supported. There is a WP plugin for longtail that gives you shortcodes etc to place movies in pages.

Frameworks should be used for applications not websites.
E.g at work I create applications that run through the web (previously desktop). I think its fine to use frameworks for this sort of project because CRUD is mostly what you need along with roles, logins, and capabilities.

Besides that you may need the odd "do this when x happens" and other event driven features but a framework will suffice in most cases such as .NET MVC in my instance.

For websites, use CMS like Drupal, Joomla, Wordpress, Dot Net Nuke, etc depending on your language/hosting preference.

From my experience CMS are only much use for companies that tend to pump out a similar type of site (e.g - a typical content site) and even then there are issues.

At my previous place of employment we tried Drupal for a while, but we found it to be too inflexible, it was fine for a mid traffic bog standard content site, on the other hand anything a bit out of the ordinary or that had a lot of stuff that could not be cached to death was a problem and vastly inferior to a framework.

There were also other issues, upgrading between versions was a joke, many modules were full of bugs that were either never updated or took months for the owner to address, which somewhat defeats the point if we have to re-write half the modules.

Furthermore the actual code was not very good, rather clunky and the general view was not a pleasure to work with both from programmers and designers who hated the spaghetti like template system.

Then there was the performance... On a busy site if you could not cache the output to death the performance is abysmal, both in terms of actual speed and in regard to the sheer amount of server resources it takes compared to a typical framework.

Thankfully it was decided Drupal (or any other CMS) was not going to cut it and just increased overheads. training requirements, inefficiencies, etc

It's 2013 now and it turns out that it's the CMS's that are dying.

It's 2013 and Drupal 8 is built on the Symphony2 Framework.....

That last word says framework.