By jordanmsllvn on

Hey guys,

I'm currently in charge of front-end development at a small agency which currently uses Drupal 7 for its backend. I'm coming from a background where I have been able to modularly develop a site's front-end with clean OOCSS and modern javascript patterns/methodologies. As you might guess, I'm flustered with Drupal 7's output markup. It makes clean and proper (in my view of 'clean and proper' anyways) FED much more difficult than it needs to be.

So that you have an idea of where I'm coming from, the workflow environment that has existed as I have entered into the Drupal world as a Front-end developer is as follows:

  1. Backend developers create a nearly complete site without any theming
  2. Site is handed off for FED
  3. FED comes back to BED with required changes in structure
  4. Huge amounts of time and money are wasted as BED gives its best attempt to match the output to the newly defined front-end requirements
  5. BED come back with a list of structural changes that simply cannot be done without re-doing large portions of the backend
  6. More time and money lost as FED must implement non-optimal CSS and/or re-write the markup structure at client-side using javascript in order to math the visual design specs

In the end, the final product turns out fine, but there is so much time lost unnecessarily on both the front-end and the backend, and writing hacky css and javascript for every project isn't ideal. Not to mention the terrible looking css hooks.

In the past, with workflows using backend like rails and node.js, I have developed front-end code parallel or even before backend development. In the case of parallel development I have also had control of the view presentation code & templates (e.g. erb & jade files). This way of working has always been very efficient, as I can can deliver highly re-usable, modular front-end code and the backend developers can focus on the backend and not worry about trying to fit square pegs into a round hole for me.

I recently read up on Twig in Drupal 8 and this has given me quite a bit of hope for the future. I'd like to present a case to use company downtime to get everyone up to speed with this so that as soon as Drupal 8 is released we can already have a workflow developed and in place to take advantage of this new theming system.

I however, have some very large gaps in my knowledge of how Drupal works and I'm not totally sure I'm on correct path yet. I would like to ask you guys a few simple high-level questions about how this new theming system works. I have read up on the documentation, however my lack of Drupal specific knowledge leaves me with some uncertainties...

  1. Does it seem feasible to you to implement a modular front-end-first or parallel workflow within Drupal 8?
  2. Will a focused Front-end developer easily be able to go into the template files themselves and modify the markup structure? (currently with Drupal 7, as I understand it, a significant amount of php needs to written in order to provide completely custom markup)
  3. How is data exposed and available to the twig template?

Thanks for your time reading and or answering this post!

⋅ Categories: Drupal 7.x, Drupal 8.x

Comments

Jaypan’s picture

Jaypan commented

I can't speak for Drupal 8, but I can speak for Drupal 7. I've done both ways. I've done back end development followed by a design, then theming the output to match the design. And I've done the design first, followed by HTML, then build the back end to match the desired HTML. The latter always works smoother with less wasted time. As such, I always place a high priority on getting the design ASAP and working from there.

I see no reason that this shouldn't be the same in Drupal 8, as this is a development concept, not a Drupal specific concept.

Of course, doing both in parallel can happen, but you will always have some wasted time, as the back-end developer will be developing what they think will be needed, rather than what will actually be needed, and sometimes there will be a discrepancy between the two.

jordanmsllvn’s picture

jordanmsllvn commented

Thanks Jaypan, this really gives me hope for sanity.
Do you recommend any specific resources/guides for developing a backend for pre-existing design/markup? Now I will just need to convince the BE developers that this is the correct path and I'm not sure they have any experience with this.

Thanks again!

Jaypan’s picture

Jaypan commented

I don't have any specific resources, but consider it like baking a cake, without knowing what a cake looks like. You have all the ingredients to make the cake, and a recipe for how to bake it, but no clue what it's supposed to look like when it's done. As such, the final product isn't likely to look like what it's supposed to look like. If they have a picture of what the final product should look like before they start, they can customize the baking process so that the final product is what it's supposed to be.

Our process is as follows:

1) Create the design
2) Create the HTML and CSS
3) Create the backend, and use Drupal's themeing system to mostly match that HTML (and output the CSS). I say 'mostly' because it's a law of diminishing returns - completely overriding Drupal's output takes more effort than it's usually worth. So sometimes the HTML and CSS in step 2 need to be altered to match Drupal's output. But having that HTML and CSS goal ahead of time makes determining the process to get to that goal much easier.