Building Bridges, Linking Islands

The world of PHP development is changing. The past few years have seen the rise of a new wave of frameworks, the birth of component-based architectures, the advent of Composer and Packagist.org, and even our own standards body, the PHP-Framework Interoperability Group. A new "Proudly Invented Elsewhere" culture (because everyone loves PIE, right?) has grown exponentially on the reusable community engine of PHP. The future of PHP is now unquestionably in assembling and using decoupled components, from a variety of different sources.

Specializing and cooperating

For PHP developers this evolution means building with tools from a variety of different sources, not just from Drupal.

When I first started using Drupal nearly a decade ago, PHP was a very different place. Every framework or application was its own universe, and the differences between projects made it normal to buy into one universe or another and hard to get to know many of them.

Drupal, my universe of choice, prided itself on being not really an application nor just a framework. This allowed it to be a "jack of all trades", even if master of none. Getting really, really good at Drupal could serve a developer very well because it let them find creative solutions to many different challenges. At Palantir.net, we had a saying for a while that "Drupal may not always be the best solution, but it is almost always a solution." We could take on almost any project, CMS-ish or framework-ish, knowing that one really good tool really well.

That's not the case anymore. The PHP world – Drupal included – has come together dramatically in recent years and the market has shifted. Drupal itself has evolved, too, to be less a framework and more a first-class Content Management Platform. As it's done so, it has ceded some "pure framework" use cases while pure frameworks have had a renaissance in the form of Symfony2, Zend Framework 2, Aura, Laravel, and other younger projects. The days when knowing just Drupal (or Joomla, or WordPress, or Symfony, or whatever) was all one needed to know are fading. Instead, the future is purpose-built tools born out of common components.

I can work with that!

So where does that leave Drupal 7 developers? It turns out it leaves them with Drupal 8, a child of this new era of PHP. Drupal 8's architectural redesign was driven in a large part, very deliberately, by a desire to bring it more in line with The New PHP, a robust library of tools ready for developers to remix them. The conceptual difference between Drupal, as embodied in Drupal 8, and other major PHP projects is vastly smaller than ever before, providing PHP coders two key advantages: it makes it easier for non-Drupal developers to learn Drupal and it makes it easier for Drupal developers to learn non-Drupal systems.

That's good for everyone for many reasons. For one, it can serve as a solution to Drupal's talent shortage: the easier it is to train experienced, accomplished developers on Drupal, the easier it is for organizations with Drupal sites to find and hire people to maintain them. The most common feedback I get from other PHP developers upon seeing Drupal 8 is "Huh, cool, I can work with that!" I've even gotten that feedback from non-PHP developers, who are another untapped (but now tappable) resource to grow the pool of Drupal service providers the market has been asking for.

On the flipside, this all opens up new opportunities for Drupal developers outside of Drupal. Heretical as it may be to say, Drupal is not the answer to all problems. As software developers, our job is to solve problems, not to solve problems only with Drupal. The more tools we have in our kit, the more problems we can solve effectively. When Drupal isn't the right tool, we need to be able to pivot quickly to the one that fits the job. Pivoting from Drupal 8 and back again will be far easier than ever before.

The future is now

At Palantir, we've already started that process. Last year, we built a REST-centric decoupled CMS platform for a media client using Drupal 7 and the Silex micro-framework, which is based on the same Symfony components as Drupal 8. Earlier this year we built a low-touch site for a client using Sculpin, a PHP-based static site generator that uses some Symfony components but more importantly Twig, the same templating engine used by Drupal 8 (and Symfony, and Oro Platform, Sylius, Foxycart, eZ Publish, phpBB, Piwik, and others). As I write this, my main client project is a two-install all-Symfony project.

Could Drupal have been used for those cases? Quite possibly, but it would not have been a good fit. And that's OK. Look at the commonalities of those projects: Drupal 8, Symfony, Silex, and Sculpin. All four can use Twig templates. All four are built on similar service architectures. All four use, or can use, any of the 30,000 PHP packages available on Packagist. Three of them use the same request/response/routing pipeline. That means any of our engineers can move with relative ease between those systems with only limited retraining. We can use the right tool for the job without having to learn several completely different tools. To do all this all developers only have to learn one main tool: Modern PHP.

The future of PHP is much more heterogeneous than it has been in the past. Of course, such potential is only useful if we’re prepared for it. Every platform has its strengths and weaknesses, and as professional developers we have a responsibility – to ourselves, our clients, and our employers – to know what those are so we can recognize and use the right tool for the job. Modern PHP ties the whole population of solutions together.

Be the bridges connecting the islands

Two years ago I called on developers to Get Off the Island and attend conferences outside of their comfort space: to meet new faces, learn new things, and open their minds. I've been pleased to see many doing so, with Drupal developers showing up and presenting at general PHP conferences and general PHP developers attending and presenting at DrupalCons and Drupal Camps.

In 2015, let's take that a step further: Don't just learn; Build.

Make it your goal in 2015 to build and launch something meaningful with a new PHP tool. If you're traditionally a Drupal developer, build an all-Symfony project. If you normally use Symfony, build a Zend Framework-based project. If Zend Framework is your home turf, build and ship a project using Aura. If Aura is your happy place, see what Laravel has to offer. If Laravel is your go-to tool, launch a site with Drupal 8. Or even combine pieces of all of them – you can do that now – each playing to its strengths. Get out of your comfort zone … discover a bigger comfort zone!

But don't just build; Teach. Document what you learn by going through the new process. Blog your experiences with your new tools. Share your new insights with your colleagues at your company, at your user group, at conferences.

Be a part of The New PHP by helping to build it and the community around it. Be the bridges that are bringing the islands of PHP together, and become a better developer in the process.

Let's learn, let’s teach, and let’s all build something good together.

Guest Dossier

Image credits

bridge_navajo.jpg - Image by Glyn Lowe - https://www.flickr.com/photos/glynlowe/7183121469 - License https://creativecommons.org/licenses/by/2.0/

bridge_peace_calgary.jpg - Image by Dave Bloggs - https://www.flickr.com/photos/davebloggs007/15267799517 - License https://creativecommons.org/licenses/by/2.0/

bridge_glasgow.jpg - Image by Moyan Brenn - https://www.flickr.com/photos/aigle_dore/4019285756 - License https://creativecommons.org/licenses/by-nd/2.0/

bridge_sunset.jpg - Image by F Mira https://www.flickr.com/photos/fhmira/5019343521 - License https://creativecommons.org/licenses/by-sa/2.0/