Switchboarding

I've been working on two separate projects, one made in Drupal 7, the other one made in Drupal 8. While 8 is definitely more front-end dev friendly, I pretty much ended up using the same methodology to output the desired html. The approach I ended up with also taught me a thing or two about how I wanted to structure my css work in future projects. For a while now I've been meaning to rethink the way I handle css, the Drupal work actually showed me a proper way to go forward with that.

To better explain what I'm getting at, I'll be using the telephone switchboard operator analogy, since that's what I felt like I was doing most of the time. For those of you who don't know what a switchboard operator did (way back in the day), the operators connected calls between people. The caller dialled a number, got connected to the operator, told her who he wanted to talk to and by switching the necessary wires the operator made the connection with the recipient.

Essentially, a switchboard operator functions as a mid-layer between two different systems that connect to each other in a many-to-many relationship.

Drupal

A system like Drupal, which has been around for 15 years or so, has a lot of history that its carrying with it. Things get fixed between versions and many improvements are made with each increment, but in the end what happens in the Drupal back-end has little or no connection to the front-end it should eventually produce.

There are many ways to solve a problem in Drupal and each of those solutions renders its own html output. There are views, blocks, content types, panels, fields and layouts all intertwining to create a mashup of unlegible, impractical html code. And I'm sure I've only scratched the tip of the iceberg so far. In the end though, all a front-ender wants is a list, a container, a content type or whatever component is needed. For years, that's been the constant struggle between front-end and back-end developers, but as it turns out it's mostly unnecessary friction.

Drupal 7 and 8 gives you ample tools to separate the front-end from the back-end. Drupal 8 does a way better job with Twig imports and extends (greatly improving your DRY rating), but it's not exactly impossible to achieve with 7 either. In the end all you have to do is write the different front-end output options using the correct variables and use whatever view/block/panel id you have to connect it to the wanted output option.

CSS

The past few years I've been battling a similar problem when writing css code. Design and semantics don't always match. Sometimes instances of the same semantic element are styled differently, sometimes different semantic elements are styled exactly the same. It's a big issue that we've been facing ever since we first started writing css, eventually leading to the hollowing of semantic html and resulting into the success of various css frameworks.

Solutions like less and sass provide us with the means to keep our html sane and our css clean though. Just write your html the best way imaginable, write abstract mixins/classes for your designs and couple them together in a layer in between. It's a bit different from the Drupal example in the sense that it will generate more css than necessary (compared to the css you need when you litter your html with senseless classes), but that's a trade-off worth examining I think.

So far I haven't had the time to try this out for real, but preliminary tests seem to indicate there's little standing in the way of working with css in this way (probably just some organizational challenges).

Conclusion

Even though we've been trying to decouple back-end, html, css and javascript for the past 20 years or so, we've never made much effort to do so properly. In the end people have always focused on doing their part as well as possible, demanding from others to adapt to fit their needs. Looking at the switchboarding principle, it allows us to move forward in a way where everybody could feel comfortable doing their job without compromising on the quality. And if anything, the middle layer could serve as an extra layer of documentation that makes the code that much more understandable.

From what I've experienced so far, it's pretty easy to accomplish and doesn't require excessive skills, nor does it make a project excessively more complex. Food for thought.