What if Drupal was started today?

One of the things about maturing software is that there is lots of legacy code based on decisions that were made long ago. Oftentimes this is refactored or removed, but sometimes the concepts are so deep that they are there to stay. Something that has been rattling around in my brain for a while is a question about what we would do differently if we started Drupal today. There are tools that are available today that weren't available 10 years ago and the web has fundamentally changed since then. There are many things that should be done the same but other things that it would be nice to have a do over on. The purpose of the post is not to call for a fork or to start a new project. It is to take a step back and look at the project as a whole and not from a legacy standpoint. Hopefully it will allow us to see the forest for the trees.

Things done well

Node/Entity Concept

The idea that (almost) everything is a node, and in Drupal 7 everything is an entity, is one of the best design decisions made by the Drupal community. Having used several CMSes before Drupal, I know the pain of the other way. In other systems I'd install the blog module and the forum module. They didn't talk to each other or know anything about each other. All the data was stored in their own tables in unique ways. If I wanted to add a five-star rating system, I'd have to hope that someone had written a five-star expansion for the blog and a different one (that kinda-sorta worked the same) for the forum. The great thing about nodes and entities is that they allow items on your website to all be extensible in the same way. Those who have never used other systems may not fully appreciate how big of a deal this really is.

Easily Extensible

Regardless of what type of extensibility system a software system uses, it needs to be easy and pervasive. Drupal has done this remarkably well. I often tell new programmers that if they are writing more than 5 lines of code to do something they are doing it wrong. The fact that we can do so many tweaks with so little code is a testament to how well done the extensibility system is. Regardless of what happens in Drupal 8, 9 or 34, it needs to remain very easy to extend.

Great Site Building Tools

One of the things that really sets Drupal apart is the site building tools. The ability to create content types, define fields, set up displays and generate views of data; without having to write one line of code is one of the most amazing things Drupal has achieved. Think about that for a second. In the past people had to hire a programmer who created database tables and wrote SQL queries with libraries to fetch, parse and deal with html and forms. Programmers are no longer needed to achieve that in Drupal and it can be done with nothing more than a web browser. This will be one of the lasting legacies of Drupal. Figuring out some of the UI needed to do complex system designs.

Users/Roles/Permissions

Another thing that Drupal really pioneered on the web was the users/roles/permissions system that allow for fine grained (but manageable) control of users. Prior to this most CMSes were designed around building out brochure ware or static type websites. Drupal, being "community plumbing," did a great job designing from the ground up around users and permissions. While there are still ways it could improve, the general design is awesome and still far ahead of other popular systems out there.

Community

To anyone who is not involved in the community: you are missing out. Drupal has by far the most amazing community around a software product that I have ever been involved in. People are genuinely helpful and available and there are fun and exciting groups all over the place. There are regular camps and cons that push the envelope forward and drupal.org is a good (and improving) place for collaboration. Without the community Drupal would be only fraction of what it is today.

Things done differently

Ruby vs PHP

If Drupal were started today, hopefully we would choose a different language. PHP has it's advantages in that it is easy to understand and very forgiving. While this encourages new and inexperienced programmers, it also encourages bugs. PHP is also growing up as a language (finally adding proper objects). But still has lots of little crazinesses. Hopefully we would choose a language like Ruby that is an absolute joy to write and was properly designed from the beginning. How many times have you written if(! something)? In Ruby you can do unless(something). If you haven't gotten to know Ruby yet, try it out and be amazed. I really wish Drupal was written in Ruby instead of PHP.

Base on existing framework

The old debate about Drupal being a framework or a CMS is a good one. It is a bit of both but not a terribly good programming framework. There is a lot of work being done trying to clean up lots of the APIs but compared to "real" programming frameworks there is still a lot of work to do. This begs the question of why it doesn't just use another framework. There have been discussions about leveraging other frameworks more for some of the core initiatives. I'd hope that if we were starting Drupal today we could pick a framework to base it on. For PHP it could be Zend or Symphony and for Ruby maybe Rails.

REST server based

One of the fundamental changes to the web is that sites are no longer just html pages. They are more of a repository for company information that has to interact with multiple devices, the desktop browser being one of them. Designing around this paradigm would need to be paramount if starting Drupal today. Everything should be done as a REST server and the web server would be one of many ways to display the data. I'm very glad that Dries has identified this as an important Core initiative but I wonder if we can really decouple everything to the amount needed without a complete rewrite. If we were starting from scratch this would be much simpler to do.

Object Oriented

Drupal is inherently not object oriented and this really hurts it. Passing around massive data arrays as configuration is a pseudo object oriented system that is very easy to break and lacks many of the benefits of a true object oriented system. Again, if we were starting today we would definitely need to do everything object based to add integrity and order to some of the things going on.

MVC Seperation

Drupal is very easy to use but does a terrible job separating out the parts of the MVC framework. A great example of this is the Form API. It should primarily be part of the View and pass the logic to the controller. For example, on a node form submit it should call node_save() (the controller) and the node_save() should report back whether or not there was an error. The Form API would then either render a successful response or redo the form with the errors. The concept of having validate and submit handlers in the form is a bad idea. It is a mix of the view and controller and makes it very difficult to do any controller work apart from the Form API. Try saving a node without doing a drupal_execute! It is getting better but properly separating these concepts would go a very long way towards cleaning things up.

Separate Site Building From Site Admin

Our admin section is primarily geared around building out the site. The site administration is tacked into the middle of it. This produces a very confusing interface for the average system admin. We constantly have feedback from our clients that it is too difficult to understand. A big reason for this is that there are way more options than they need. What we should do if starting Drupal today is to split these into two different admin areas. One for Site Building tasks and the other for Site Administration tasks. Any changes to the structure or design should be in the Site Building tasks and site admins should only be given a very simple interface for administering the site. This is probably something we could do today with Drupal 7/8 but would be a must if starting over today. One of the things that drew me (and many others) to Drupal was not only its power but how easy it was to program and understand. The only thing I worry about some of the items listed above and the D8 core initiatives is that they will/are making it more difficult for beginners to really understand what is going on and contribute. This is a nasty tradeoff and one that will need to be managed carefully. What thoughts do you have? What else did Drupal get right? What else would we do differently if we started again today? Photo Credit: http://www.flickr.com/photos/jonasb/3090295208/