Should output be framework agnostic?

[derekjohnson]

Issue

This design system's output is either React Components or the CSS from the components in a state that needs transpiled. In Barnardo's we make extensive use of Rails, Gatsby, Drupal and plain HTML/CSS prototypes, and have encountered issues applying the DS to all of these except Gatsby. Therefore is a framework agnostic DS a good idea?

@reggieb can shed more light on this but right now it seems postcss is an encumbrance with Rails, and the separation of concerns that components provide is not the separation of concerns Rails works best with.

The Drupal site has a fudged and bodged version of the DS, although that has as much to do with how it's built that the DS.

JavaScript frameworks come and go. We will almost certainly not be using React/Gatsby in 10 years, however browsers will still understand plain HTML, CSS and JavaScript long past then.

How others are tackling it

This is a problem other people have been dealing with. Salesforce’s Lightning design system lists:

• semantic and accessible component markup.
• cross-browser compatible CSS.
• icons, font, and design guidelines.

In a blog post detailing their thinking they state:

We chose to abstract the markup to make it framework agnostic, based on accessible HTML and CSS scaffolding we call component blueprints. Lightning Design System component blueprints: Framework-agnostic, accessible HTML and CSS elements used to create components.

Brad Frost recommends a core system of HTML, CSS and JS and framework specific tiers of the design system.

This is the approach taken by Pattern Lab, Github's Primer, Microsoft's Fabric and IBM's Carbon.

Carbon and Primer also provide a link to the built CSS as a flat file, useful for designers looking to create a quick HTML & CSS prototype without having to figure out node, npm, postcss and terminal before doing anything.

Further reading

• https://hackernoon.com/design-systems-should-be-javascript-framework-agnostic-2a0c47129ec8
• https://www.designbetter.co/design-systems-handbook/building-design-system
• https://noti.st/sturobson/yc1gwN#s1k0NBo
• https://blog.usejournal.com/3-reasons-why-i-went-framework-agnostic-and-why-you-should-do-that-too-f39ba81c6001

[reggieb]

Using PostCSS within Rails isn't particularly hard, and there are some things it's hard do to without it. Specifically applying fills to SVG files within CSS.

It is the the separation of concerns into components that is problematic.

[wagg-matt]

Have done some research and read the links shared in Further reading above and have the below thoughts:

• Going framework agnostic is the dream scenario and something that is worthwhile aspiring to
• This will remove a framework dependency and we can pass on all of the well researched principles in the design system
• Best way to future proof as frameworks come and go, they can also drastically change the way you build with them (Angular 1 > 2 for example)

For initial steps we could do a spike (this might be a difficult undertaking and keeping it simple may be challenging) to see how easy this would be and what potential pitfalls we might find. As described in Brad Frost's article, the framework agnostic version would be the source of truth and the frameworks we then use can simply ingest it. We can can then use platform specific versions, such as React components, Ruby gems, Twig templates for Drupal etc.

After a chat with @derekjohnson we could recreate the design system exactly as is using pure HTML, CSS and JS that can then be ingested into a framework. Since the currently version is built in Gatsby, that could be our first platform specific version that can ingest the newly created framework agnostic version. Does this make sense? Ideally, it would still use NPM and be split into components but use the minimal amount of compilers/transpilers in order to allow the individual project to dictate what is appropriate for that project.

After a spike it would be good to outline the dream scenario and then look at stages in which we can look to implement that.