There are lots of goodies coming in Drupal 8. A lot of work has gone into bring Drupal up to modern web standards. In addition to digging into Drupal-specific problems, a lot of work has gone into removing some of the custom overhead we have by incorporating a number of external libraries—that is, code that other communities have created and maintain, and does not live on Drupal.org. Adding external libraries means that we are working with these other open source communities to maintain our code, and that lets us focus on the Drupalisms we need, instead of re-inventing the wheel all over the place. This is the biggest growth for exernal libraries that we've ever seen, and I decided to take a look at what we have in core now.
A Little History
To give a little bit of context for this, let's take a quick look at what we've done with external libraries in the past. Originally all of Drupal was custom code. We wrote and maintained every line of code. We would ocassionally look to other libraries for inspiration, but even then we wrote our own version (see XML-RPC in Drupal 4.7).
In Drupal 5 we finally saw the wisdom in using a specific tool that had its own community making sure it rocked. We included jQuery in core so we could stop hassling with custom JavaScript and use a proven, supported library. At the same time, we also included Farbtastic.js to provide the theme color picker instead of trying to write one from scratch.
For Drupal 6 we kept plugging along and didn't add anything new. We were fine with external JS, but we still ruled the PHP.
Drupal 7 included a bunch more libraries for the first time, but they were almost all additional jQuery libraries (jQuery UI being the really big one). For the first time we added a new PHP library though: Archive_Tar. You may also recall SimpleTest going in at this time, but truth be told we rewrote it in a Drupal way. We did things our old way, of finding a tool that was kind of what we wanted and then building it ourselves. Drupal SimpleTest != SimpleTest Project.
Drupal 8 External Libraries
So, what have we switched up this time? Well, there are several significant changes going on. First is the rise of JavaScript libraries designed to build an entire web application, not just to make the front-end look flashy. The second sea change is with regards to mature PHP frameworks, and Drupal's need to pull itself into the modern PHP age, using Object Oriented Programming (OOP). So, without further ado, here's a brief list of what we have to play with in Drupal 8.
Please note that this list isn't comprehensive, but hits most of the big tools. This gives a quick summary, where we will go into more detail on some of these new tools in future blog posts.
PHP
Unlike in the past, we added a lot of PHP libraries this time to handle tricky issues that have already been solved in other projects.
Symfony
Symfony is an open source PHP framework. It has lots of interesting bits and pieces, which are called components in the Symfony world, and you can use those to construct your framework with just the bits you need instead of everything under the sun. Drupal is taking advantage of this component-based system by incorporating some individual components we like. We aren't using a most of the framework—just a few select bits. The folks over at Cross(Functional) have a pretty good hit list of components that have been included. In addition to the components, we've also added Composer, which is a PHP dependency manager to help us manage all these new bits.
<rant>
I also want to point out that there has been a lot of FUD about Symfony in core that I think has caused people to misunderstand the implications. You do not need to learn Symfony to use Drupal 8. We are using these components as underlying tools, and you will simply use them, much like you use the hook or menu systems today. You don't need to understand the internals of those systems to get your work done. You do need to learn the new way we use these tools, but Symfony internals are not something you need to touch (unless you want to). I certainly never played with the internal of the core menu system beyond the hooks I was given to use. The big change for Drupal 8 development will be the fact that we have moved to PHP Object Oriented Programming (OOP), but this is a modern PHP change—not a Symfony-specific thing. So, please, relax. :-)
</rant>
Assetic
This is an asset manager, which will help us keep track of things like JS, CSS, and media files.
PHPUnit
A mature testing framework that works well for testing OOP classes.
Guzzle
A PHP HTTP client.
Doctrine - Common
Doctrine consists of a a bunch of libraries to work with databases. We have only incorporated the "Common" library, which gives us the concept of annotations. Annotations are a way to provide some additional meta data in your code.
Twig
Our new templating engine. This is replacing Drupal's version of PHPTemplate (of course we didn't use actual PHPTemplate; we wrote our own). This should make it much easier for non-PHP folks to dive into Drupal theming, and it let's us make our templating system more secure by default by pulling out all that PHP.
JavaScript
We have quite a lot of jQuery in Drupal, and have had so for several versions. In Drupal 8, we kick it up by adding non-jQuery libraries.
Backbone.js and Underscore.js
Backbone is a lightweight JavaScript framework, similar to Angular. It only depends on one library, Underscore. Underscore is a set of low-level utilities for manipulating arrays and objects, while Backbone is a framework that gives us an MVC (Model - View - Controller) solution for working with JavaScript. In Drupal core it's used on contextual links and in the toolbar.
Modernizr
This is a handy library that a JavaScript library that detects HTML5 and CSS3 features in the user’s browser. Basically it weeds out the old, crunky browsers that can't handle your new, slick web code, and let's you add conditions to handle them.
CKEditor
We now have a WYSIWYG in core. You can add different editors if you like, but CKEditor is the one that is shipping with the Drupal 8 code base.
So, as you can see we've made a big leap in external libraries, which I think is a smart move for Drupal. We should use open source as it is intended, and stop reinventing the wheel for components that other people are spending a lot of time and energy on. We can take advantage of this solid work, so we can focus on the work of creating a solid, kick-ass CMS. Extending our external open source libraries also brings us closer to those other communities, and I hope this fosters more sharing and growing together—in the classic open source idealogy.
A lot of the starting material for this post was taken, with permission, from Camilla Krag Jensen's (naxoc) "Introduction to new technologies in Drupal 8" presentation slides.
Add new comment