Click here to watch The history & future of Drupal theming.

<UPDATE>

Slides available here: http://www.slideshare.net/c4rl/history-and-future-of-drupal-theming

RenderAPI code available here: https://github.com/c4rl/renderapi

</UPDATE>

Okay. Once upon a time there was a content management system that needed to render markup. So this Content Managment System returned strings of HTML. Well that really wasn't that great because there were these people out in the world called Front End Developers and it just so happens that Front End Developers actually care about what the HTML looks like. Oh, by the way, this Content Management System is named Drupal.

So the Drupal changed. It created something called a theme layer, which allowed Front End Developers to override the markup that was produced. And it provided some templates that the Front End Developers could use like they were used to when they wrote old skool HTML in their favorite text editor. There were these magic Preprocess functions that allowed the Front End Developers to change the variables that were injected into the templates themselves. After some head scratching, the Front End Developers became happier, because they had more control. But they also had more tools to learn.

Well some time went by and this other group of people called Back End Developers decided that markup was being generated too soon by the theme layer, so they created something called the Render API. The Render API was Yet Another New Tool. Well actually, Render API was a bag of magic beans that promised many things; it delegated markup creation. Nevertheless, the bag had a few holes in it, and some of the beans turned out to be actually wadded-up gum wrappers and a few stale raisins. But by this point, the Front End Developers were overwhelemed. "Theme Functions Overrides, Preprocess Layer, Template Overrides, Process Layer, Alter Hooks, Theme Wrappers, Page Array? ZOMG AND A HALF DOT COM."

The bough broke. Coderage swept across the land. Front End Developers and Back End Developers formed a vicious, tangled rivalry fought in the trenches of whatever Major Social Media Providers could provide.

But admist the anger and confusion shined a light of hope; A beacon, a renaissance. A tiny voice asked: "Yo theming is way broken. So, um, what if we started this over again?"

Such words were spoken at DrupalCon Denver. The brokeness of the past could be fixed: *This. is. Open. Source.*

Thus began a journey. In the forest, we found, amidst the dew-laden leaves and mossy oak, a totem of things to come: a Twig. The Twig was powerful had some ideas. The ideas were refreshing. The ideas were new. The ideas began a conversation, and that conversation discovered new things. There was momentum. The Front End Developers took action.

But we soon discovered the Twig was only the tip of the iceberg. Our refactoring sights are eyeing some tasty entrees, including but not limited to:

• theme system architecture
• theme registry as a service
• theme() callback deprecation
• An OO Render API and death to the arrays of doom
• Overlaps with TypedData API and EntityNG

Now is the present. The rising OO tide lifts all ships. The theme layer as we know it will change, and needs to change. We have made a lot of progress. There is a lot to be done.

Come to this session and hear the next chapter of the story, and contribute your own ideas.