Frontend Architecture for Design Systems

Chapter 10. Red Hat Process

At Red Hat, our frontend development team has the incredible advantage of working multiple sprints ahead of our backend development. We set long-term goals for the features we want to build or update, and once we have a signed-off prototype, we pass it over to our development team to implement.

In past projects, we might have said, “OK, here is the markup we want you to try to output. Please get as close as you can.” We would create markup in a siloed set of Mustache or Twig templates, and then ask our development team to create PHP, Ruby, Angular, React, or Ember templates that output the same markup. The problem with this approach is that half of the battle of implementation is trying to get the markup spit out by the backend anywhere close to our prototypes. We’d constantly be tackling bugs that were nothing more than “the markup coming from our CMS does not match our prototype.”

Even if we did get the markup to match our prototype, there was always the fear that either the prototype or the CMS code would get out of sync. Changes would be made to one system that were not made in the other, and eventually there was such a crevasse of technical debt that our prototypes couldn’t be trusted. We could never be sure that they represented what was actually in production, and any further work on that feature would have to be done directly to the CMS code. The problem was that the CMS and the prototyping tool were not sharing HTML templates, even if they ...