Template Technology Agnosticism

Brad Frost recently wrote about managing technology-agnostic design systems. In his post, he recommends using a technology that doesn’t tie itself to any specific framework.

When I was at Yahoo!, we took a very similar approach. We knew we wanted to build out these components and be able to use them across multiple projects. And due to product acquisitions or teams deciding different stacks, we knew that we had the real possibility of needing to support templating in JavaScript, PHP, and Java environments.

Mustache

We chose Mustache because of its agnostic approach. (Pattern Lab—of which Frost is a contributing member—also uses Mustache under the hood.)

It’s an approach that worked well for us at Yahoo! and one that I’ve been advocating for ever since.

Like Frost says in his post, we wired up much of the system using some lightweight JavaScript for simple interactions. Some components, however, had a full JavaScript API. Something like an autocomplete widget would have Mustache, CSS, and JavaScript counterparts that would all be part of the final deliverable to other teams.

Our prototyping engine was able to render (at request time) a small part or a large part of a page through a combination of file hierarchy and naming convention. And all of this was done outside of any team’s engineering efforts.

The advantage to separating this out from other teams allowed us to avoid the complexity of their build process and release cycles—of which, different teams had different processes and different cycles.

Single Stack

On the flip side, when I was at Xero, I had made a different recommendation. Instead of an agnostic design system, I recommended picking a specific tech stack.

Xero, too, had different tech stacks used across the application. Unfortunately, the plethora of platforms was more a hindrance, slowing down the ability to iterate on design and maintaining a consistent experience across the entire application.

Some parts of the application wouldn’t have a team looking after it and thus would languish. Likewise, it was difficult to have people who had knowledge of all the tech stacks to roll design changes out system wide. As a result, inconsistency grew over time.

By choosing a single tech stack, the intent was to build an API that allowed new projects to ramp up quickly while also allowing designers and front-end developers to roll out changes across the entire platform.

Decisions

When do you choose an agnostic platform versus a specific one? I believe it comes down to an organizational one.

At Yahoo!, the Mustache templates were the source of truth. Thus, any design changes started within the prototyping platform and then pushed out to other teams.

For that approach to work at Xero, a generic platform would need to be established as a source of truth and then pushed to an intermediate stage. Personally, I’m not sure that the intermediate stage is necessary. The more layers between designers and production, the more resistance to change is likely to occur.

As Brad Frost intimates, if you’re using an intermediate step, you’re going to need a build process that converts the generic components into platform-specific ones. You’ll want to do this to avoid platform-specific implementations from becoming the new source of truth for any implementation. Otherwise, changes will have to roll back and forth between intermediary and preliminary stages.

Conclusion

I’m a big fan of Mustache, even over its more feature-laden cousin, Handlebars. I like it because of its simplicity and because it requires the heavy work with the data to be done before it sees a template. (This is a strategy I’ve been using in web development for 15 years now and I find it works well.)