As we begin a new year, it seems appropriate that the discussion of backward compatibility has come up yet again in Drupal. It's a perennial question, and you can tell when a new Drupal core version is ready for prime time when people start complaining about lack of backward compatibility. It's like clockwork.
However, most of these discussions don't actually get at the root issue: Drupal is architecturally incapable of backward compatibility. Backward incompatibility is baked into the way Drupal is designed. That's not a deliberate decision, but rather an implication of other design decisions that have been made.
Drupal developers could not, even if they wanted to, decide to support backward compatibility or "cleanup only" type changes in Drupal 8. It is possible to do so in Drupal 9. If we want to do that, however, then we need to decide, now, in Drupal 8, to rearchitect in ways that support backward compatibility. Backward compatibility is a feature you have to design for.
Last week I was at DIG London, in London, Ontario. It's normally a gaming conference, but they've added a web track and asked me to come speak. It was a fairly good experience, helped in part by their keynote, the infamous Jeffrey Zeldman talking about responsive design and related topics.
One of the points Zeldman made was that users want content their way, not the way we (web designers, web authors, and web devleopers) want it. Visually impared users want content read to them, or resized. Color blind users want a different color scheme that they can actually read. Smartphone users want content in a narrow column, without a dozen sidebar blocks. Mobile users want content offline, so they can read it on a plane. Many users want just the content, no design, and so use tools like Instapaper to strip out everything but the text of an article. RSS feeds have been around for a decade, and are now growing rapidly thanks to mobile devices, and those are generally (mostly) layout-free. If you're doing responsive design, then you're not making a design but the framework of a design that will change, and possibly mostly disappear, under certain circumstances.
Of course, that to me begs a very important question. When I asked it during Q&A, even Zeldman didn't have an answer. (Yes, I stumped the King of Web Standards. Woohoo!)
In the modern web, does web design even matter?
(At BADCamp, several people were asking me to explain what the heck the Web Services core initiative was trying to do, so I got to practice my elevator pitch. This is essentially that pitch in written form.)
Drupal today is very page-oriented. Every request that comes in is responded to with a full HTML page. It is possible to return something else, and finally in Drupal 7 there is, sort of, native support to do so with delivery callbacks, but by and large any non-page response is an after thought at best and a hack at worst. The entire system is built around the assumption that we're returning an HTML page. Why else would we still load the theme system and form system for an auto-complete callback?
In the past, that hasn't been a major issue. The web was a series of pages, in practice, and Drupal is one of if not the most flexible page-generating machine on the web today. Drupal 7 is, arguably, the pinnacle of this page-oriented world.
Just in time for that world to be fading fast.
Earlier today, Dries committed a patch that adds two Symfony2 Components to Drupal: ClassLoader and HttpFoundation.
On its face it's a fairly simple patch; the new code in it is maybe a dozen lines. But it's an important part of a larger shift within Drupal to better embrace the modern web, on the server as well as the client.
This is not your father's Internet. When the Web was first emerging onto the scene, it was simple. Individual web pages were self-contained static blobs of text, with, if you were lucky maybe an image or two. The HTTP protocol was designed to be "dumb". It knew nothing of the relationship between an HTML page and the images it contained. There was no need to. Every request for a URI (web page, image, download, etc.) was a completely separate request. That kept everything simple, and made it very fault tolerant. A server never sat around waiting for a browser to tell it "OK, I'm done!"
Much e-ink has been spilled (can you even do that?) already discussing the myriad of ways in which the web is different today, mostly in the context of either HTML5 or web applications (or both). Most of it is completely true, although there's plenty of hyperbole to go around. One area that has not gotten much attention at all, though, is HTTP.
Well, that's not entirely true. HTTP is actually a fairly large spec, with a lot of exciting moving parts that few people think about because browsers offer no way to use them from HTML or just implement them very very badly. (Did you know that there is a PATCH command defined in HTTP? Really.) A good web services implementation (like we're trying to bake into Drupal 8 as part of the Web Services and Context Core Initiative </shamelessplug>) should leverage those lesser-known parts, certainly, but the modern web has more challenges than just using all of a decades-old spec.
Most significantly, HTTP still treats all URIs as separate, only coincidentally-related resources.
Which brings us to an extremely important challenge of the modern web that is deceptively simple: Caching.
As people spent the weekend trying to memorialize the 9/11 terrorist attack's 10th anniversary, I was reminded not of 9/11/2001, but of 9/11/2002.
For the first anniversary, a friend of mine asked me to write something for a memorial web site he was putting together. I do not know if that site still exists, so I have replicated it here in its entirety:
My article from the inaugural issue of Drupal Watchdog is now online. Design Patterns of Drupal is based on my original session from DrupalCon Paris. Although Drupal-centric, it serves as a great introduction to the concept of design patterns in general.
If you're going to be at DrupalCon London, watch for Watchdog issue #2 in your swag bag! It looks like I may have as many as three articles in it, discussing mobile web design, Drupal 7's improved node access system, and how to approach the "Drupal stack" when planning a new site. I'll also be on stage talking about Code Smells and how to avoid stinky code, plus teaming up with Peter Wolanin to talk about what it means to work with Free Software.
See you in London!
Any time a given Drupal core development cycle is more than six months old, people start asking "When will Drupal X be released?" The answer, of course, is always "When it's ready. Please help us finish it." That's well and good, and I don't propose that we change that position. Volunteer labor and fixed release calendars do not mesh well.
However, knowing when Drupal will come out, at least in a vague sense, is increasingly important for core developers. The web is changing rapidly, even more rapidly than it has in the past, and knowing what the web will look like around when Drupal 8 is released is critical. Not only so that we can target the right features to get ahead of the curve, but so that we even know what our available tools are.
Session submissions are open for DrupalCon London, in case you hadn't heard. But what should we be talking about?
Once again, I'm going to solicit ideas from the community (that means you).
Naturally my main work these days is the Web Services and Context Core Initiative for Drupal 8. However, that probably won't be main-track session material by London, and I am already slated to present an update on that front as part of London's Core Conversations track.
In recent years, I've been developing an ongoing "Architecture Series" at DrupalCons. My intent is to help Drupalers around the world raise the bar in terms of software architecture and design. So far, I've covered:
If you haven't been living under a rock, you know that AT&T is trying to buy T-Mobile. This is a generally bad thing, as we already have far too much consolidation in the wireless carrier market as is, but that doesn't mean it's not still likely to happen. The only blocker is approval from the FCC, who is, per policy, soliciting public feedback. (It's 11-65.)
I would encourage everyone to sign in and voice their opposition. More carrier consolidation is not what we need. I've included my own public comments below for reference. Feel free to borrow liberally.