Will Drupal 8 be faster?

Will Drupal 8 be faster than Drupal 7? Will Drupal 8 gain the speed we lost when converting from Drupal 6 to Drupal 7? We know some things can be faster and many site will use the new features for flexibility, not speed. D8 will offer more choices and, like D7, the choice will often be flexibility or speed.

In Drupal 6 you added a field to a node using a module and the module developer chose the way she or he used the database. You had the flexibility of choosing a different module and of choosing not to use any module. There was also the choice of the dreaded CCK that did something similar to the add-on module but with massive processing overheads and no choice about how the data is stored.

Drupal 7 included a module named Fields that did something similar to parts of CCK and replaced CCK but did not reduce the overheads. The core Fields module received more attention than the add-on CCK and a tuning effort by many people resulted in some improvements to the performance of Fields. You really need to keep up to date in Drupal 7 to get the performance improvements. At Drupal 7.14, there are still performance enhancements going into core and you still have to add on a lot of modules to fill all the holes in Fields.

Drupal 8 started out using some parts of the Symfony framework to change the theme system. As soon as the first tiny bit of Symfony slipped into Drupal 8, the promoters of Symfony jumped in and promoted Symfony as the cure for every problem, much the same as the CCK fanpersons promoting CCK to solve every problem in Drupal 6.

If the adoption of Symfony in Drupal 8 follows the pattern of Fields in Drupal 7, Symfony will be pushed into Drupal 8 in more ways than are beneficial and we will need a Drupal 9 to clean up the mess. There is nothing to suggest the decision process in Drupal 8 will be any better than the decision process in Drupal 7 and most of the decision process has moved out of the public discussion are. We are seeing online discussions about how we could do x but starting with a comment that the decision was made prior to the start of the discussion and it is too late to do anything.

All or nothing

Symfony is supposed to be flexible enough to let you use any combination of Symfony and your code. There are several frameworks making the same claim. When you use them, you find the basic code locks you into using the framework. When you adopt the error management of a good framework, and I am not saying Symfony does or does not fit this category, you need all your code using the error management. The easiest way is to grab all the database and other critical code from the framework. You are locked in. The alternatives are a lot of work.

You cannot change the framework

Open source projects are built be herds following the leaders and the leaders are the politically motivated who want their idea to win, no matter what the cost. The result does not matter to the herd because every member of the herd can jump ship and use a different application, or framework, for their next project. Most of the herd are paid for the end result, not the code they use, and there are often several choices with only slight differences in effect over a big project.

Why would you fight for improvements to Symfony if you can switch to the Zend framework for the next project?

The Drupal project is big enough to influence the Symfony project because Symfony lacks a successful CMS built on Symfony. The Symfony developers will help Drupal convert and many Drupal developers will help because they want Symfony on their resume. The big question is, would Symfony change a major architectural feature to fit Drupal? Unlikely.

What is happening with Symfony, Zend framework, and the general framework market is a move to make them work together and that means lots of political fights of standards in an area where there are either no standards, or there are competing conventions posing as standards. Most new Web projects ignore the frameworks and use something that works out of the box. Frameworks started to die out a long time ago.

After 15 years of social Web site development, the market was flooded with Myspace, Youtube, Twitter, and Facebook. Now Google is working to replace them and the market is so contracted that Myspace has disappeared. None of the big activity depends on the existing frameworks. Google and Yahoo build their own frameworks. To continue to exist, Symfony needs Drupal more than Drupal needs Symfony but the instant Drupal 8 is released, Symfony will be after another market and Drupal will have to use whatever Symfony decides is needed to attract other users.

Code generation

Symfony is one of many alternatives offering code generation to make some things faster. Symfony is not the fastest framework so a decision to use Symfony is not based on speed. Drupal already has caching to make things faster and caching has a bigger effect than code generation.

When you look at the code generation features in Symfony, they are really only internal changes, they do not improve the user interface. Drupal needs some huge leaps forward in the user interface area and those leaps forward have nothing to do with Symfony, in face you could easily add the changes on to Drupal 6 or Drupal 5.

The Drupal 8 developers look like they will use one part of Symfony, a part named Twig, to alter part of the theme process. There will be code generation. There is no sign yet that the change will include improvements to either the user interface or to performance or to security. What it might do is make those types of changes easier by moving some things out of themes back into the theme processing engine, which will make the changes instantly available to every theme.