Global design system or component system

Global design system or component system
Photo by Amélie Mourichon / Unsplash

Once again Brad Frost has added another piece of naming to the zeitgeist that hits the nail on the head for an idea we've all likely had at some point: The Global Design System.

The idea is for an unstyled set of components for all the basic building blocks we keep building over and over again that either aren't in the HTML spec or missing common functionality. Alerts. Drawers. Carousels. You get the idea.

There's a lot of to say about the idea - most of which was walked through on the Shop Talk Show - but I sense that a lot of the focus will be on the design part.

But I'm more interested in the potential it could have on component frameworks like React, Vue, and Svelte. Would we really even need them if we had something close to Frost's GDS?

I'm aware that's a big jump. Bare with me for a second as I try to make the case for my pie in the sky dream of less component frameworks.

This theoretical GDS would need to be implemented in Web Components. WCs aren't perfect but it would be the only global implementation choice.

And every component would undoubtedly have what I call view-specific logic. A tool tip that knows to hide itself when clicked. A dialog that properly implements a focus trap. A tab group that tracks it's own state to know which tab is active. These are all examples of logic and state that is only there to provide a certain user experience.

This is different from what I call application-specific logic that happens to affect the view or is triggered by the view. When a certain button is clicked, a POST request is made to a back end. A table that should only display records that the user has access to. A logout button that is only displayed if the user is actually logged in. These are all examples of the specific rules of your application being implemented in the UI.

The view-specific set of examples are the ones senior devs have all written a gazillion times throughout their careers because the logic is largely application-agnostic. Doesn't really matter what app you're building, you're likely going to have an alert that needs to be dismissed. What drives this logic is user expectations on how web pages look and operate. Not your specific application.

I suspect a GDS would handle large chunks of that view-specific logic. But it's also what component frameworks like React, Vue, and Svelte are also helping you handle yourself. I've always viewed them as solving is view-specific reactivity. Of course, they add any kind of reactivity, but the view-specific reactivity is really where they shine. They're all about building components, which is fundamentally a UI concept.

And if I can pull that logic off of a global design shelf via a web component, then large chunks of my reactivity needs are handled.

I've always been a minority on arguing this point. I've felt for a long time that most of us aren't building applications that are super complicated. 80% of the pages I've built are along the lines of do some GET requests on page load, display the results, and hook up either a form or a button to a POST request. Most of the JavaScript I end up writing is all about this view-specific logic. Take that out and I've got a few HTTP requests per page and not much else in the basic use case.

So a GDS seems like a great way to get these basic use cases out the box and lower our dependency on component frameworks.

I'm aware it's a bit of a pipe dream. It's hard to imagine a world where the component frameworks don't run the software world. I doubt a GDS implementation would actually make a dent on the mind share that component frameworks hold. (Especially since I doubt GDS will actually get implemented.)

But it's an interesting thought experiment.

I could get used to a world where building apps is just about pulling components and their view logic off of a shelf and then slapping on a few handlers for the logic specific to my application.

Here's hoping someone runs with it.

Colby M White

Colby M White

A software developer with more than a decade of experience. Currently collaborating with the RedwoodJS team to add a AutoForm to its ecosystem.
Austin, TX