I've been building websites in Drupal since version 6. Back in those days I used FTP to transfer data from my local machine to the production server. I also had no idea that update hooks existed, meaning that pretty much every change I made in the interface I did again on production.
Drupal 7 brought quite a bunch of changes. The Entity API was one of the best, even though it was partially complete. No longer did you need a contribute module for adding fields to user objects. And although Drupal 7 was pretty good, there were some serious downsides. Lack of separation between content and configuration made deployment difficult, and what to think of the logic that was all over the presentation layer? Contributed modules solved these problems, although some were incomplete.
So, what’s going on?
And now, Drupal 8 is coming. And this time something is different! Many of the problems that troubled Drupal 7 have been tackled. There has been work done on a complete Entity API, we now have Twig as a templating layer, and there is something called Configuration Management.
Let’s also not forget that since a few years mobile users became a much larger group of the browsing population. In Drupal 8 mobile users are covered with responsive themes and modules leveraging the power of HTML5.
But under the hood we see a larger change which is important for the future of Drupal. We went from procedural code to actual OO (object oriented) code.
Important for the future
Of course the fact that Drupal core is fundamentally changed has it’s downside. But it most definitely has advantages.
Everybody knows that for developers the Drupal’s learning curve is huge. Now that we are moving away from doing our own crazy things, we can embrace other modern frameworks that developers outside of Drupal also know! I think this will certainly enrich the already vibrant Drupal community.
For Drupal companies it will also become easier to get Drupal developers, which seems to be nearly impossible at the moment. Solving this problem will help Drupal grow.
But what about the current developers? They are going to be in for quite a ride as it seems, a lot of these developers are not familiar with OO code. There’s already been a fork of Drupal that doesn’t want this change.
The Drupal community might lose some of the hobbyists, but it will gain professionalism and expertise.
Although there’s a lot of good things to tell about Drupal 8, and we will be looking into some of them next time, there are still issues that really need to be sorted out.
Currently the performance of Drupal 8 is not great, it’s quite a bit slower than Drupal 7. It can be expected at this stage though, we just landed in the beta phase. There has been no focus on increasing the performance yet, but this will happen before the release. Also OO code is slower than procedural code. But then again, the new core will be much easier to plug into caching tools and mechanisms. My bet is that Drupal 8 will be slower than Drupal 7 out of the box, but can be tuned to perform a lot better!
My biggest fear is that we won’t have enough or good enough documentation when Drupal 8 is released. I don’t want to search the entire web for proper examples how to do certain things, I’d rather find it on the official site.
When it’s done.
And what about the release date of Drupal 8? Simple, when it’s done.
Optimistically speaking, Drupal 8 will be released in the Q1 of 2015. Realistically though, it will probably be in Q2.
Next time we’ll further explore changes in Drupal 8. There’s still a lot to talk about!#3