alex-ketch
commented
5 years ago To expand on:
We build our own system as outlined above, but don't have layered themes. Instead we decouple as much of our logic as possible from our framework specific components, and share it across multiple UI-specific components. (Here's a way to theme Material Design for the web)
A real possibility is that even if we do go with a fully custom solution with a swappable theming layers, we still won't be a native citizen of any ecosystem without heavy interference at the component/markup level, and we will always feeling a bit out of place. An example of this are the skins for Bulma and Bootstrap which are "inspired" by Material and Fluent designs, and they get close to replicating the design systems, but fall short of the real thing.
An option we could explore would be to accept the inevitability of having to use different markup, and work to create "renderless" components. These would encapsulate all of the logic, shareable across all systems, but would require customization at the render layer. The benefit of this is that we can pull in the official design systems of the respective platform and integrate it with our requirements. Downside being that we'd likely end up changing markup for even moderately complex components.
Some reading material regarding this topic:
- https://kentcdodds.com/blog/introducing-downshift-for-react
- https://adamwathan.me/renderless-components-in-vuejs/
- https://github.com/thomashoneyman/purescript-halogen-renderless
Bulma themes for:
- Material Design: https://jenil.github.io/bulmaswatch/materia/
- Fluent: https://mubaidr.js.org/bulma-fluent/
Bootstrap themes for:
- Material Design: https://mdbootstrap.com/docs/jquery/components/
- Fluent: https://github.com/mdbootstrap/bootstrap-fluent-design
nokome
We have a few active projects with differing style requirements, and more projects are likely to come in the future.
To keep development manageable, consistent, and streamlined, I propose structuring this project into following areas of concern:
The big question is, how important is it for us to share work between the different visual layers? Do we instead fully invest in a third party design system, and can we even do that considering the list of targets above?
Proposal
I suggest we use Tailwind to skip the first layer of structural/layout styling. The composable nature lends itself well to building custom designs while abstracting away a lot of the boilerplate. This means we can we can delegate a lot of the structural/layout to an existing framework, letting us concentrate on fleshing out our own design system (the Visual Modifiers part). The ability to extract component level classes from identified patterns will help with consistency within and across projects, as well as allow us to create themed variants for different visual styles. The components should be built up in an Atomic way, reflecting both our design and development processes.
Brand assets are mainly for sharing things like logos, colors, icons, and fonts, amongst various projects, and can be split up into multiple sub-packages if we'd like.
Documentation
We should better utilize Storybook.js to create and document our components. I suggest selecting a logic layer to both build our framework-specific component library as well as to document the CSS-only framework.
While this does go against the idea of framework agnostic design systems, I think it will reduce overhead of maintaining two sets of documentation, a pure HTML and a JS framework variants. We could also look into deriving the pure HTML documentation (with just the CSS class names), from the framework specific one.
Distribution
Due to the close dependency of the various projects, I think it would make sense to have a monorepo managed by a tool like Lerna to allow working and publishing changes across projects easier.
Drawbacks
Prior Art
A good example of such a system in use is Microsoft's Fabric UI. The project has an underlying CSS package, and is consumed by several different framework-specific implementation. Please see how they declare and use a Button component in React.
Design Systems
Frameworks to Consider
Logic Layer
The likely de-facto candidate is React. However an interesting candidate to keep an eye on could be Svelte if we are interested in producing very small/AMP like publications. The elimination factor for Svelte right now is complete lack of TypeScript support.
Articles
Alternatives