There has been a lot of chatter about Drupal 8. Will Drupal 8 be performant? Will Drupal 8 be easy to develop modules for? Will I have to learn Symfony? I want to address these concerns and explain why Drupal 8 introduces such big changes.

Why the big architectural changes in Drupal 8?

Lessons from the past: the pain before the gain

The reason Drupal has been successful is because we always made big, forward-looking changes. It’s a cliché, but change has always been the only constant in Drupal. The result is that Drupal has stayed relevant, unlike nearly every other Open Source CMS over the years. The biggest risk for our project is that we don't embrace change.

The downside is that with every major release of Drupal, we've gone through a lot of pain adjusting to this change. I first wrote about it in 2006 when trying to get Drupal 4.7 released:

So let's capture that thought for future reference. Sweeping changes are required to make major advances in technology, and often times there is a lot of pain before the pay-off.

We decided that big changes were required

Drupal 7 is a fantastic CMS, but at the same time there are some fairly big limitations, including an incomplete Entity API, a lack of separation between content and configuration, leading to deployment challenges, a lack of separation between logic and presentation in the theme layer, and more. We created solutions for those challenges using contributed modules, but those solutions were in many cases incomplete. In Drupal 8, we decided to tackle a lot of these problems head-on, through the Configuration Management Initiative, the Twig templating layer, and a complete Entity API.

The web landscape has also dramatically changed around Drupal since January 2011, when Drupal 7 was released. Mobile browsing is ubiquitous, and so are third-party services that people may want to integrate their Drupal sites with. Web site users expect a much higher bar when it comes to ease of use. We anticipated these trends and as a result, we spent the past 2.5 years working on Drupal 8's mobile features and user experience improvements.

But are all these great improvements enough?

We need to modernize Drupal 8

One of our biggest challenges with Drupal, is that it is hard for organizations of all sizes to find Drupal talent (developers, themers, site builders, etc). Drupal 7 didn't address this problem (e.g. we held on to procedural programming instead of object-oriented programming), and in fact made it a bit worse with the introduction of even more "Drupalisms" (e.g. excessive use of structured arrays). For most people new to Drupal, Drupal 7 is really complex.

The most effective way to address the Drupal talent issue, as well as the complexity issue, is to bring Drupal in line with modern frameworks and platforms, so there is less Drupal-specific knowledge to learn in order to become proficient. We decided to adopt modern PHP concepts and standards, object-oriented programming, and the Symfony framework. While a lot of the Drupal concepts (Fields, Views, Entities, Nodes) continue to exist in Drupal 8, they are now implemented using object-oriented programming design patterns.

The advantages and disadvantages of object-oriented programming are well-understood. The disadvantages are size, verbosity, the amount of work it takes to write (including the design planning that goes into it) and slower performance. For people new to object-oriented programming there may be a steep learning curve; some of the key programming techniques, such as inheritance and polymorphism, can be challenging initially. The advantages are encapsulation (both to hide implementation details and to avoid tampering with internal values), faster development thanks to re-use, extensibility, and better maintainability. Compared to procedural programs, object-oriented programs are easier to maintain, extend and refactor. So although a lot of work is spent to write the program, less work is needed to maintain it over time.

For Drupal 8 this means that the code will be more abstract, more verbose, and slower, yet also be more maintainable, more modular, and more accessible to non-Drupal developers. The end result is that Drupal 8 should help us attract new people to Drupal in a way Drupal 7 didn't.

This is exactly what happened with other projects like Symfony; Symfony 2 was a complete rearchitecture of Symfony 1. A lot of people were alienated by that, yet at the same time Symfony 2 took off like a rocketship. The same thing has happened with the major releases of Drupal as well, despite how much change each one brings.

Change is scary for the existing Drupal developers

However, as we get closer to the release of Drupal 8, existing Drupal developers have become increasingly aware of the massive changes that Drupal 8 will bring. This has resulted in some fear; some people feel like they have to re-learn everything they know, and that developing for Drupal 8 has changed to the point where it's no longer fun. This fear is completely understandable. Change is hard, it can be scary, and often takes a long time to be absorbed.

But even if we completely streamlined the Drupal 8 developer experience, Drupal 8 will still look and work radically different under the hood. As mentioned, there are advantages and disadvantages to object-oriented programming and modern design patterns. But if we care about the long-term success of Drupal, we can't preserve the past. The risk of sticking with the old Drupal 7 architecture is that we won't be able to attract many more Drupal developers, and that over time, Drupal will become the odd one out.

There is a lot of work left to be done

Part of the fear out there is well-founded because in the current state of development, Drupal 8 isn't good enough. While there are many things to like about Drupal 8, I'm also the first to admit that we have work to do on the Drupal 8 developer experience (as well as performance) before Drupal 8 can ship. Creating a well-designed object-oriented application takes more time and design work than creating a procedural one. Some major improvements have already landed, but we're still working hard on improving the developer experience. We need more help, especially from Drupal 7 developers, on how we can make Drupal 8 more approachable for them. I'm not afraid to make major API changes if the developer experience improvement is suitably large. So if you have concerns about Drupal 8, now is the time to step up and help. In return, I promise we'll work on Drupal 8 until it is ready. Thank you!


Matt Farina (not verified):

A big part of good developer experience, especially through a change, is having good tools to help people learn. Documentation, tutorials, examples, and more. When I've spoken with people about this area I've gotten the impression it's not covered.

What is the plan to provide the material people need to work through this transition?

xjm (not verified):

Great question! And I agree wholeheartedly... A big part of making D8 successful is creating good documentation and tutorials.

We're building a resource hub at to provide tools and information to upgrade their developer tools to Drupal 8. The goal is to aggregate all the great materials that are already being created on D8, and provide it in an easily browsable/searchable format. Please help out by contributing to this site! It should be "launched" on Drupal Planet within the next week, in time for DrupalCon Prague.

We're also working on an open-source curriculum of quick introductions to Drupal 8 topics:

jhodgdon (not verified):

Just what we needed: yet another web site to go to for information... It looks like there also are other new sites, like, linked from this site.

All of the information developers need to use the Drupal API ought to be at and on, and the change notices should be in the change notice section. If that information isn't complete or is wrong (and it currently has a lot of problems), that's the real D8DX problem.

If people are spending time writing blog posts on new "portal" sites instead of writing documentation that gets into our official documentation spots, that is also a problem.

Sigh. Why the fragmentation?

webchick (not verified):

We've got that, fortunately!

But I think the bigger pieces we're missing are things like a full 8.x port of, updates to some of the key pieces of documentation at, a D8 version of, and so on. To a large extent it's premature to really start on these since APIs are still in flux, but the sooner they get underway, the better I think everyone's going to feel.

Incidentally, these also happen to be great places for people new to Drupal 8 to jump in. There's nothing like trying to explain something to someone else to teach you how something works! :D If you find things confusing, hop by #drupal-contribute on IRC and we'd be happy to help anyone who's working on docs or tools to make transition to D8 easier!

soulfroys (not verified):

Oh yes, I've seen this, it's great work. Actually, what I wanted to point out is the usability in CKEditor 4 Docs site:
- All documentation in one place.
- A great search and navigation.
- Nice organization/categorization

Obviously this demand is not new in the Drupal community, and there are already some initiatives in this direction here and here (besides the hard work done by the core maintainers and doc team). An "idea" has even been posted on 2014 roadmap brainstorming, but it should be a "state policy" in Drupal Community: make documentation an first-class citizen.

We'll get there!

xjm (not verified):

I am the first to agree that good API documentation is essential, and that Drupal 8's API documentation needs a lot of work. The goal is just to provide a centralized and searchable listing of other formats of information (videos, events, community blog posts, etc.) since doesn't yet have the tools for this, along with a feed of relevant reading.

Gyorgy Chityil (not verified):

Do you have some stats for the statement: "Symfony 2 took off like a rocketship?"

AmyStephen (not verified):

@Gyorgy -- here's a good visual -- it's anticipated Drupal 8 uptake will be follow similar pattern.

Berend de Boer (not verified):

I have been working a bit on Drupal 8, and I must say there is a big gap between what people in the PHP think what OO is, and outside. I can't believe that developers will find Drupal 8 easier to learn. The enormously deep layered OO spaghetti produced by Symfony is not much progress.

But the think I dislike most is using code in comments. That's a horrible feature.

PS: having said that I still think Drupal 8 is a welcome step forward. It's snappy, I like the routing options, twig is actually quite nice, and the configuration changes are a game changer.

Mark Sonnabaum (not verified):

> I have been working a bit on Drupal 8, and I must say there is a big gap between what people in the PHP think what OO is, and outside. I can't believe that developers will find Drupal 8 easier to learn. The enormously deep layered OO spaghetti produced by Symfony is not much progress.

I respectfully disagree. There certainly isn't a single view of OOP outside of the PHP community, each language's approach is influenced by the conventions and capabilities of the language itself. Symfony's components are really not that complex on their own, I definitely would not describe them as "OO spaghetti." The patterns used there should be recognizable to anyone with an OOP background.

> But the think I dislike most is using code in comments. That's a horrible feature.

It's not quite accurate to call annotations, "code in comments." Retrieving the contents of docblock (supported in the language) to parse for metadata is not a new thing, we've been doing it for documentation purposes for a very long time. These annotations are no more "code" than the contents of a yaml file. That said, the approach we've taken where we put everything in a single annotation looks more like code than annotations typically do. I'd like to see us take an approach similar to doctrine with a single annotation per line.

Larry Garfield (not verified):

Annotations are a native language-level feature in a couple of languages. The PHP core team has rejected them for PHP at this point (sadly), so we make do with what we can. As Mark said, it's not "code in comments"; it's more "info hooks in comments", where info hooks are definition/declaration, not code. The main advantage is that it keeps all data about a given object/class/resource/whatsit in one file in one easy-to-find place.

Our error handling around the parser could definitely use improvement, I won't argue, but the concept of annotations is not itself a bad thing and we're hardly the only project to be using them.

Rob (not verified):

Yeah, it's weird. We're moving away from structured arrays (aka maps) just as PHP introduces a new syntax to make them really easy to work with. Most web developers these days will be much more familiar with JS objects than Java classes, and PHP's arrays actually work more like JS objects (when used for data, at least). Newer languages like Clojure make maps a preferred approach for most lightweight/flexible data storage even though a more class-like option (records) exists. Perhaps there was a time, in 2008 or so, when object-oriented PHP made more sense than the alternatives, but the world has moved on and Drupal's fixation on re-opening this debate is a bit odd.

That said, I basically agree that the actual functionality in D8 represents a big step forward. Configuration management is such a huge win that it dwarfs everything else.

Fabien (not verified):


The success of Symfony2 vs Symfony1 can be seen from many different angles. Let me give you some facts.

First, some hard numbers: after the launch of Symfony 2.0, the traffic on the doubled in less than 10 months. On Github, Symfony2 has been the most forked and starred PHP project almost from day 1 (as Symfony was one of the very first significant PHP projects to adopt Git and Github as a platform). In 2012, Symfony was the 4th most active project on Github, out of millions (with 4 merged pull requests every single day). As of today, 870 developers contributed to Symfony compared to perhaps 20 or 30 for symfony1 (we were not tracking contributions at that time).

This "success" is due to many factors but probably because we were one of the first frameworks to recognize and embrace the changes of the web and PHP: PHP 5.3 vs PHP 5.2, Git vs SVN, components vs a monolithic framework, Twig vs PHP, dependency injection, ... Symfony2 is a revolution, not just a big evolution of the platform.

The success can also be measured in terms of adoption by other Open-Source software (Drupal being "just" one of them). Since the launch of Symfony2, a lot of other PHP projects have adopted some of the Symfony components. That's great for us but that's also great in terms of interoperability for the PHP ecosystem as a whole. Last, but not the least, thanks to the modern architecture of Symfony2, we attracted a lot of developers who were not interested in symfony1 (we probably lost some developers too, but all in all, the community grew faster than even before).

I'm convinced that without breaking BC so hard between symfony1 and Symfony2, the Symfony project would be dying today. Instead, because we decided to fix our mistakes, because we decided to embrace the new PHP features and the new web paradigms, Symfony2 set the foundation for a more powerful and open framework.

passerby (not verified):

But is referring to OOP as "modern" ahistorical? Marketing language? OOP has been around since b4 many Drupal developers were in their cribs. I'd like to see stronger justifications for this change than calling it modern. Also the choice is not between changing and not changing, but among which set of possible changes we choose. Framing it generically as "change" is not very persuasive either.


Object-oriented programming has been around for 30+ years. While it is not new or modern in the strict sense, it is relatively new in PHP. In PHP 3 and PHP 4, objects were essentially containers of properties, much like associative arrays. You couldn't do much else with them. And to make it worse, PHP3/PHP4 objects were passed around by value, and not by reference. It wasn't until the release of PHP 5.0 that we started to see a significant step forward in PHP’s object-oriented programming capabilities.

Larry Garfield (not verified):

It's not just OOP that's "modern". As Dries and Mark both said, "modern" and "OOP" are language-relative terms.

It's really only since 2007 or so (PHP 5.2) that we've had a good, stable OOP model in PHP at all. (Earlier PHP 5 versions had some issues.) PHP 5.3 is a game-changer with what's possible, and that only came out in 2009. Using clean dependency injection is still not as wide-spread as it should be in PHP, although it's getting there. Composer is a tool that's only sprung up in the last 2 years, coinciding (coincidentally) with Drupal 8's development cycle.

So it's not that using classes makes Drupal 8 "modern". It's that Drupal 8 is the first release that is really looking toward the current state-of-the-art in PHP at large and trying to leverage it to the best of our abilities.

One could argue that the state-of-the-art in PHP is a rather low bar compared to some other languages; one could probably win that argument, too. :-) (I know Mark Sonnabaum makes it all the time.) But Drupal is a PHP project, so that's the relevant state-of-the-art we look to.

just-passin-thru (not verified):

I've commented on other blogs about being skeptical about the so-called improvements of Drupal 8. However, until now I haven't seen it stated as fact that it will also be slower as well.

The steady slow down of Drupal release after release is actually what's most concerning at the moment. While enterprise sites can throw more hardware and technology (with their required performance tuning experts) at the speed issue, there are lots of places where that simply can't happen-- and I'm not talking about free or shared host type sites. There are tons of basic or small business type sites that aren't enterprise with an unlimited budget.

While personal opinion of the acceptability of the DX changes can be debated-- it can certainly be overcome. Its just requires time to learn it.

The continued performance degradation can not. Shops that can't afford the price of acceptable performance will be forced to look elsewhere. And that's the scariest thing of all.

Mark Sonnabaum (not verified):

It is in no way an inevitability that D8 will be a performance regression. Yes, it is currently, but we are not done. Once APIs stabilize a bit more, we can start doing more performance work to fix the regressions.

Also, we've been working on caching more aggressively in core using the new cache tags API, which we've never been able to do before. Partial page caching will be much easier to implement in D8, whereas it was prohibitively difficult in D7, so it was rarely done.

Kelly Bell (not verified):

I agree, though I've only been playing around periodically with D8 dev releases, and certainly haven't done anything demanding or complex yet. But my experience so far is that it does feel "snappier". And maybe I'm wrong, but the typically-draggy theme layer should also show improvement with Twig... so I'm pretty optimistic that between the tuning that's yet to come (as above) and the other improvements (like partial-page caching), at the very least we'll break even on performance, and hopefully see net improvements.

Of course, the proof of that will be seen "in the wild", as everyone gets their hands dirty solving real client problems. And to that end, I agree too that great documentation / tutorials / best-practice "clues" and recipes being made available from trusted sources BEFORE release (so there's time to practice before being thrown into the fire) could make all the difference in the world. If we can get people doing things the right way coming out of the gate it will pay huge dividends for developers and clients, as well as for Drupal's reputation in the larger developer and business communities.

Django Beatty (not verified):

Bear in mind that while layers of abstraction slow down raw performance, they allow scalability and provide further points for smarter caching.

Drupal 7 is an example of that - while overall less performant out of the box on a single server, significantly it moved the bottleneck from the database to processing, and so can be scaled horizontally. That was a much more difficult and specialised job in D6. In addition D7 allowed the use of reverse proxy caching such as Varnish, which is now used very widely. So in effect performance improved a lot in D7 and those gains became more accessible to the wider community.

Drupal 8 in turn promises significant performance improvements with the use of partial page loading, which addresses the currently specialised issue of performance for dynamically produced pages (e.g. authenticated users). This is the hardest performance problem most projects encounter in Drupal 7.

Larry Garfield (not verified):

At the micro-level, OOP code tends to involve more stack calls (functions and methods) and therefore slower runtime. Adding layers of abstraction does tend to slow down micro-benchmarks. However, the trade-off is that the better separation of concerns and better encapsulation makes optimization and performance tuning easier. For example:

- In Drupal 8, you can still shift your caching to memcache or whatever else for better performance than the default SQL-based cache. However, you can now also shift "state data" from the database to a dedicated key/value store like Redis or MongoDB (or whatever you prefer), which will handle those lookups much faster. You can also move the config cache to something other than SQL, which I predict will be one of the first "pro optimizations" for D8 sites (much as "use memcache instead of SQL cache" is what anyone with a dedicated server should be doing already in D7).

- With more and more code shifting to injectable objects, we can shift more and more of our tests to PHPUnit tests. Those are only about 1000 times faster than Webtests, which means if we get far enough along with that process it becomes more feasible to write real unit tests for modules and custom code. That means they'll actually get, you know, written at all. :-) That in turn means more robust and more stable modules, fewer bugs, and better sites. (There's still work to be done in core to make sure everything is nicely injectable and testable, so this is a great place to help out.)

- We're still working on making partial page caching practical. Mostly that comes down to more controlled channels for how blocks get rendered, including their metadata, and eliminating global state. Once that's done, we can do for-reals block caching that is actually usable. Even without leveraging ESI, we should be able to do better in-process caching than we could in Drupal 7. That in turn should make authenticated page rendering much faster. Again, though, this is still a work in progress that could use help, especially from people familiar with the problem space.

So yes, OOP code is "slower than procedural", but only in the naive sense. If done properly it opens up a lot of options for performance improvements that are simply not possible in a procedural-code / global-state system like Drupal 7.

moshe weitzman (not verified):

However, you can now also shift "state data" from the database to a dedicated key/value store like Redis or MongoDB.

It is deceptive to take a benefit of D8 and claim that we have it because of OOP. We could easily have had a state system without OOP. I mean gosh, we conflated state and variables in D7 and those are already routinely backed by memcache on D7. Splitting those systems had nothing to do with OOP.

Larry Garfield (not verified):

It's been mathematically proven that procedural, OOP, and functional are all equally expressive. That is, there is no algorithm or concept that cannot be implemented in one or another of those paradigms.

However, certain concepts are WAY easier to implement in one paradigm or another. "Swappable implementations of a given task" is a concept that is extremely well-suited to OOP. The entire interface/class concept is tailor-made for that sort of use case.

So sure, we *could* have implemented swappable subsystems in procedural code, and for some systems we did do so in the past. However, it's *way* easier to do in an OOP model, and if you've built a good DI-based framework it's often easier to do so than not.

netol (not verified):

I am happy to know that Drupal 8 will be released when it's ready. I would rather wait 2 years than have a bad release in 6 months

Larry Garfield (not verified):

Nice writeup, Dries!

Another important point is that a well-factored OOP-based system is, generally speaking, easier to extend and improve without breaking APIs than a naked-arrays-all-the-things approach (Drupal 7). There's a TON of things we couldn't do in Drupal 7 without breaking APIs. In Drupal 8, the number of things we can add or change without breaking APIs should be much higher. That in turn means that, if we did our job right, we can improve Drupal 8 in point releases while maintaining backward compatibility far more than in Drupal 7. It also means that some changes for Drupal 9 that would have been API breaks in the past can, potentially, be done with fewer or no breaks. (Not everything, of course, but more things.)

See this previous article of mine, plus my upcoming Prague Core Conversation:…

Writer (not verified):

I liked the procedural aspect. I thought it made the dev process more agile, and not the Agile project management type.

"So although a lot of work is spent to write the program, less work is needed to maintain it over time."

I work with Drupal sites that have multiple year maintenance cycles. Nobody in sales or project management at my place complains about the maintenance, they complain about the initial rollout time.

ianmthomasuk (not verified):

Maybe you're waiting until Prague to discuss this, but I'm interested in the plans for post Drupal 8. Are there big initiatives that we need to work on immediately, or could we afford a period (say a year) of API stability? We'd still be improving Drupal, but working on changes that could be committed to Drupal 8 and therefore used by the community in a matter of months rather than the years we'll need to wait for Drupal 9.

I think it could also help encourage new contributors to core, as you'd avoid the need for the "Issues must be fixed in Drupal n+1 first" policy.

mchampsee (not verified):

I'm a bit of a noob to Drupal, and wanted to offer my perspective.

I remember reading an article that argued that D7 was D6 with some contrib modules put into core. Obviously, this isn't exactly true, but it does juxtaposition the vast changes in D8 that needed to happen in core. Obviously, CMI, Web Services, Symphony, Twig, etc. could only really happen in core as well as the move to OO. D8 looks to be revolutionary both in terms of our community's ability to compete with CQ-level projects as well as WordPress.

At the same time as we've pushed forward on that front, D7 hasn't been fully integrated into our DNA. We are looking at a scenario where d.o. is still at D6 and we could be in the situation of releasing d.o. on D7 at around the same time that we release D8 publicly. There are still prominent contrib modules that are in RC or beta in D7 and many others that have never had a big push to get upgraded from D6 to D7.

As such, I'd propose the following:
-Hit Pause. Perhaps D9 should be our "Snow Leopard" where we focus on re-factoring without making big functional or api changes. Let contrib modules be upgraded to D8 as well as d.o. and give people time to learn the new object model.

-Add more contrib modules to core in D9. I'm glad to see that a WYSIWYG is now in core. I've had somewhat tech savvy clients say that when evaluating between Drupal and WordPress that they would install both and test them out. There is no comparison if you don't add a few contrib modules to Drupal when comparing to WordPress. I know that this is all part of a bigger debate, but would it hurt to have pathauto, 403 redirect, token to name a few in core? This would make Drupal much easier to work with out of the box for newcomers to Drupal.

-Make it mandatory for d.o. to be upgraded concurrent with a major Drupal release. I saw this advocated some where else. I didn't start using D7 until about a year after it was released. Imagine if the D8 release creates a large amount of hoopla and an excited customer goes to their neighborhood Drupal shop who tells them that they really should build a site in D7 until the contrib modules have a chance to be released and stable. Forcing us to upgrade d.o. will ensure that each major release is usable on day 1.

Thank you for reading.

Leighton Whiting (not verified):

I agree with a number of your points. Drupal 8 is a huge shift in thinking and development, but I think it will pay off in the end. But we do need to make sure we aren't putting the cart before the horse and make sure that things work WELL before we release, as Dries also pointed out. I'm in no hurry to rush things before they are ready. Good job to all of the people who have been working hard on D8!

Pierre ORFINGER (not verified):

I hope that the use of an important outside object oriented piece like Symphony 2 will assure better portability between Drupal version than before.
I am for and was very happy of the quick enormous evolution of Drupal in the last 5 years and could understant the lack of compatibility between versions related to it but now it's time for maturity and invest in long term continuity. I am available to invest my experience in migration/compatibility tools to let younger guy be more inventive !

Pedja Grujic (not verified):

Great post, there will always be users who will fight the change. I have seen this happen to every open source project I have ever been involved with from linux kernel to Drupal. Debates will always happen however the road map for Drupal 8, at least for me is pretty clear and yes there is more work to be done before its ready.

One issue which you also touched on that is a big concern for me is the Drupal talent pool. We are currently experiencing a very high demand for Drupal developers, and that is why we need to focus on growing the programs that will provide talented developers to clients across the globe. Increasing involvement and the number of new users is an effective method to keep the Drupal project strong and community growing.

This issue is the main reason I am running for DA board to expand the reach of the Drupal project by growing programs which will help new users get involved, learn Drupal and replenish both the project and community pool. You can read all about my plan to solve this issue:

DA elections are starting Sunday, please remember to vote next week

Jesse Beach (not verified):

As someone who would happily never write a line of PHP, and as someone who spends all my working ours in core, I hit points of frustration with Core quite frequently (if you follow me on Twitter you'll know this). The thing is, every time that frustration has abated and I've gotten into a new dev flow with Core PHP. The shock of the new is frustrating but it ultimately subsides.

I am beyond psyched about changes to Entities, Fields and the inclusion of a sane REST API right into core; route declaration changes and controller classes as well; access checking services and a cleaned up JavaScript layer, too. Drupal 8 is going to be a platform that supports complex, dynamic web applications. WordPress does not do this. It might never.

I've been in discussions with front end dev shops who take on clients with preferences for CMS systems. In the past, when a client requests Drupal or is already running on Drupal, one shop in particular would groan. Although they love the administration tools in Drupal 7 and 6, their interaction with the code is always painful. Their reaction to the features in Drupal 8 was downright elation. They see Drupal 8 as a platform that they can use to allow their clients to manage sophisticated content models and on the other side, a platform that allows them to get data through REST in JSON in order to build the front end UIs that their shop is renowned for. All of this was possible in Drupal 7 to some degree, but it required knowledge of modules and maybe a few custom modules for glue.

Client-side code is the future. Drupal 8 is positioned to be the platform that drives the content for those applications.

awasson (not verified):

Dries didn't say that... He said that it is well known that OOP code is slower than procedural code. If I had written that, I would have added:

The advantage of a properly executed OOP framework is that you have more control over it at a granular level and this enables you to fine tune it for performance better than a procedural pasta salad of code.

Also, straight up flat HTML is much faster than anything that hits the PHP interpreter so you can always use Boost or some other method of caching and make it lightening fast (just make sure to clear the boost cache when you're making changes).

AmyStephen (not verified):

Re: the 'HTML is faster' comment, Sculpin is a static site generator that will be ideal for Drupal 8's architecture. It's written and supported by Beau Simensen, a PHP dev. A key benefit to standardizing the architecture is the availability of tools like Sculpin that Beau wrote, and many, many other options that will work great with Drupal 8.

Ron (not verified):

This got me really worried.

I hate OOP. From my experience its the opposite of agile. You spend enormous time in planning the right model/hierarchy, just to understand down the road that you need to redo everything since the business changed, and then its a nightmare. See here for example…

"One of the biggest problems I've found with OOP is that it forces the developer to bake in structure long before the developer actually understands what that structure should be which then leads to the fragile base-class problem."

In my experience, Drupal's main problem is slowness for non-anonymous users. That's why it can't be used as API for mobile. Making it even slower doesn't sound good.

I spent a lot of time learning the 'Drupal way'. Now it seems that my investment may no longer be relevant. I'm not sure how many Java developers will jump to do Drupal dev, but I can think of some Drupal developers frustrated enough to look elsewhere. Anyhow, developers like an infrastructure because its easier to write code, its more flexible, it has better performance, works better with other infrastructures, has great community etc. Not because its harder to code but easier to maintain.

Last time I heard a talk on d8, I remember the initiatives (separation of conf / data, etc) and the architecture core changes (moving to symphony), doing lazy loading to keep Drupal's footprint low - i.e. increase performance, etc. I don't remember 'moving to OOP' as one of stated goals / lessons learned.

I'm probably over reacting here since I haven't had the time to look at d8, so take this into account. Maybe what would make me less worried is reading a 'migrate your d7 to d8' tutorial. If its 'think about your business logic and express it as classes and interactions', I'll jump to the river. If its 'change your hooks to be methods' or something it'll sound better.

Rob Black (not verified):

I have seen a number of comments from people worrying about the use of OOP. I have heard arguments against OOP about performance, speed of development, learning curve, etc. Some of these I have sympathy for and others I disagree with. However, they are missing the point.

OOP is here to stay for one simple reason; it is much easier to secure. On the web this is a killer feature. It is a direct consequence of encapsulation.

If we want high-profile websites of increasing complexity to run on Drupal there really is no other option.