Obviously niche, but the GOV.UK Design System is very well supported in Rails.
There's a form builder and library of components (built and maintained by me) which, between them, provide full coverage. Most new Rails services use them.
It's a good match because accessibility is one of the Design Systems' primary concerns so JavaScript is used very sparingly and only to enhance.
They're not official, only Nunjucks is supported by the Design System team.
Hey I've seen you work before I didn't realize it was an outside effort, also second the remark about accesssibility I wish my government could foster a project like that one.
We used your repo as inspiration for a separate US gov't design system (not uswds) at the beginning but ended up shifting focus to building web components just before I left.
Awesome work and hope your gov't sees the value of this work and oss work in general!
Not to nitpick terminology, but I don't think it's helpful to equate "design system" with component library. A design system is the design tokens used to describe an organization's application(s), and largely independent of the exact technologies.
I worked with our UX team at a mixed tech company (Rails, React, mobile) who defined the patterns and tokens, and then my team implemented so that we could use across our stack.
Largely this was accomplished via ensuring the design system could be used via CSS and we settled on Bootstrap with custom theme. This made it easy enough to use across Rails views/view components and React components.
Bootstrap is not sexy to devs now but you could do same with Tailwind and Daisy UI with custom theme.
With that said, component libraries are really helpful, but I prefer to align them with the design system and not the other way around.
You are absolutely right. The perspective is simply a practical question of, can we grab a component library that feature a design system (that we can hopefully update with our preferences).
Yes this basically why we used Bootstrap. The components and patterns UX wanted to use were a close match for Bootstrap's components, aside from colors, fonts, etc which we then adjusted.
We didn't have an automated pipeline since the UX team wasn't really tech savvy enough to dive into detailed styles, so we relied on recurring syncs every 2 weeks. The DS changes tended to be slow and incremental from the UX side as well which helped.
Bootstrap (like Tailwind and others) has a configuration for generating the full component class and styles from a few variables, so updates to fonts, colors, spacing, etc were easy to manage and roll out to wide usage incrementally.
Totally get the struggle — I spent way too many hours figuring which design system should I use for my next project. Ended up creating a site to compare the options: [https://rails.style]. Might help others in the same spot.
Worth noting that the poor performance of erb has been debunked[1] and it'd be helpful to add some caveat or clarification in the rendering solutions table.
Everyone seems to have their own opinion on what something like this should and should be or do. Nitro Kit is my opinion and I'm getting a lot of joy from using it on my own sites and services.
It's free and open source and, full disclaimer, there's a paid premium offering too.
I've had a good experience so far working on an admin dashboard with BeerCSS (and Datastar which is unrelated). It implements a lot of the Material Design stuff and it is opinionated but between the examples on the main site and documentation on GitHub it was pleasant to work with. It's easy to get started too, just add three links in the <head>.
It's not just that many design systems are tied to a particular framework, it's that they don't play well with HTML, and therefore classically server-rendering frameworks like Rails, Django, PHP, etc.
With custom elements you can just drop `<my-dropdown>` in your server template and that's where the dropdown widget will be.
Something like Shoelace[1] would be very nice to use with Rails.
Custom Elements don't play well with HTML either. And "just dropping <my-dropdown>" is not much different from "just dropping <div id=app> and running some framework code on it"
It's strange to see people downvoting this when custom elements still can't be properly rendered on the server. All the attempts are very framework specific, e.g. lit's list of caveats https://lit.dev/docs/ssr/overview/ (and shoelace referenced above depends on lit).
There's nothing very special in sending a html tag and then attaching functionality to it with javascript when it's loaded in the browser.
Framework server rendering is framework specific... Seems like a framework problem.
At least custom elements can just be including in framework-specific templates and be included in the rendered output, even if not deeply server-rendered.
It's actually very difficult to do this correctly and at scale with a framework like React, because in React you need an ID and JS call to initialize each embedded component, when custom elements initialize themselves.
Anyway, you have an axe to grind, so have fun with that. I'll see you next time I make a positive comment about web components I guess.
Github's https://primer.style/product/getting-started/ does a good job of making a cohesive design language that works just as well for server-rendering Ruby views and "upgrading" parts of the ui to React views when you need more interactivity. That's a constraint that I wish more of the Rails ecosystem design tooling would attempt to solve for.
I really think that a design system solution has to be framework/implementation agnostic. It’s why I’ve never been too interested in shadcn, impressive though it may be.
Right now I’m trying to build a tool that produces an intermediate representation of your UI components, which can then be transpiled into whatever target format you prefer.
That way we can build design systems that aren’t coupled to a specific downstream tech stack.
I came here to ask the same thing. Bootstrap 5 still rocks, at least for those of us who inexplicably don't love adding 40 classes to every element.
One of the things most frequently ignored on the comparison chart is the fact that there's a massive ecosystem of free and paid Bootstrap themes which can massively shortcut development.
There's so much bikeshedding and yak shaving when it comes to this topic. Folks spending their time considering options that also won't be Cool in two years instead of actually building The Thing.
Yes, I have to maybe add a small note that might not be clear. I need something I can include for people in my Rails template. If it's fully commercial, I cannot redistribute it and my customers would need a license.
Obviously niche, but the GOV.UK Design System is very well supported in Rails.
There's a form builder and library of components (built and maintained by me) which, between them, provide full coverage. Most new Rails services use them.
It's a good match because accessibility is one of the Design Systems' primary concerns so JavaScript is used very sparingly and only to enhance.
They're not official, only Nunjucks is supported by the Design System team.
https://design-system.service.gov.uk/
https://govuk-form-builder.netlify.app/
https://govuk-components.netlify.app/
Hey I've seen you work before I didn't realize it was an outside effort, also second the remark about accesssibility I wish my government could foster a project like that one.
We used your repo as inspiration for a separate US gov't design system (not uswds) at the beginning but ended up shifting focus to building web components just before I left.
Awesome work and hope your gov't sees the value of this work and oss work in general!
I'm so glad you found it useful. Thanks for letting me know.
Not to nitpick terminology, but I don't think it's helpful to equate "design system" with component library. A design system is the design tokens used to describe an organization's application(s), and largely independent of the exact technologies.
I worked with our UX team at a mixed tech company (Rails, React, mobile) who defined the patterns and tokens, and then my team implemented so that we could use across our stack.
Largely this was accomplished via ensuring the design system could be used via CSS and we settled on Bootstrap with custom theme. This made it easy enough to use across Rails views/view components and React components.
Bootstrap is not sexy to devs now but you could do same with Tailwind and Daisy UI with custom theme.
With that said, component libraries are really helpful, but I prefer to align them with the design system and not the other way around.
You are absolutely right. The perspective is simply a practical question of, can we grab a component library that feature a design system (that we can hopefully update with our preferences).
Yes this basically why we used Bootstrap. The components and patterns UX wanted to use were a close match for Bootstrap's components, aside from colors, fonts, etc which we then adjusted.
Interesting - did you set up your own pipeline from the DS to each platform? How did you manage parity and consistency over time?
We didn't have an automated pipeline since the UX team wasn't really tech savvy enough to dive into detailed styles, so we relied on recurring syncs every 2 weeks. The DS changes tended to be slow and incremental from the UX side as well which helped.
Bootstrap (like Tailwind and others) has a configuration for generating the full component class and styles from a few variables, so updates to fonts, colors, spacing, etc were easy to manage and roll out to wide usage incrementally.
I came across CSS Zero recently:
https://csszero.lazaronixon.com/lookbook/pages/overview
which bills itself as an "opinionated front-end starter kit" specifically for Rails and includes Stimulus.js code for JavaScript functionality.
It seems the benefits are that it is no build (pure CSS with CSS variables) and easy to modify and extend.
It also has the additional benefit of not being based on Tailwind, unlike most of the others listed in the original post and comments here.
Yes, it's a good one. I'll include csszero in the updated version of the post.
Totally get the struggle — I spent way too many hours figuring which design system should I use for my next project. Ended up creating a site to compare the options: [https://rails.style]. Might help others in the same spot.
Worth noting that the poor performance of erb has been debunked[1] and it'd be helpful to add some caveat or clarification in the rendering solutions table.
[1]: https://news.ycombinator.com/item?id=43550721
cool
I'm currently building one called Nitro Kit.
Everyone seems to have their own opinion on what something like this should and should be or do. Nitro Kit is my opinion and I'm getting a lot of joy from using it on my own sites and services.
It's free and open source and, full disclaimer, there's a paid premium offering too.
https://nitrokit.dev/
Here's a video about my reasoning behind building it:
https://www.youtube.com/watch?v=Li-RPk561l8
Following along closely!
Just want to say I stumbled across your Youtube channel a while back and have been delighted by the content. Keep up the good work!
Thank you so much!
I'll add it to the post. I have seen it before but it slipped from my mind.
Came here to look to this!
It’s too bad most UI libraries ate tied to a particular framework like React, Tailwind, etc. instead of self-contained web component elements.
I've had a good experience so far working on an admin dashboard with BeerCSS (and Datastar which is unrelated). It implements a lot of the Material Design stuff and it is opinionated but between the examples on the main site and documentation on GitHub it was pleasant to work with. It's easy to get started too, just add three links in the <head>.
https://github.com/beercss/beercss
https://www.beercss.com/
It's not just that many design systems are tied to a particular framework, it's that they don't play well with HTML, and therefore classically server-rendering frameworks like Rails, Django, PHP, etc.
With custom elements you can just drop `<my-dropdown>` in your server template and that's where the dropdown widget will be.
Something like Shoelace[1] would be very nice to use with Rails.
[1]: https://shoelace.style/
Sadly Shoelace doesn't play well with Rails' FormBuilder...
Custom Elements don't play well with HTML either. And "just dropping <my-dropdown>" is not much different from "just dropping <div id=app> and running some framework code on it"
All the reasons are here: https://dev.to/stuffbreaker/web-components-and-ssr-2024-edit...
It's strange to see people downvoting this when custom elements still can't be properly rendered on the server. All the attempts are very framework specific, e.g. lit's list of caveats https://lit.dev/docs/ssr/overview/ (and shoelace referenced above depends on lit).
There's nothing very special in sending a html tag and then attaching functionality to it with javascript when it's loaded in the browser.
Framework server rendering is framework specific... Seems like a framework problem.
At least custom elements can just be including in framework-specific templates and be included in the rendered output, even if not deeply server-rendered.
It's actually very difficult to do this correctly and at scale with a framework like React, because in React you need an ID and JS call to initialize each embedded component, when custom elements initialize themselves.
Anyway, you have an axe to grind, so have fun with that. I'll see you next time I make a positive comment about web components I guess.
Note that we're talking about embedding them in a Rails app.
- all SSRed custom components are framework/library specific and cannot be rendered outside of javascript runtimes
- you need a JS call to initialize each custom component (though this is likely provided by the bundled JS)
- since when providing an id in a server-rendered HTML become an insurmountable challenge?
- and they have many additional issues. Example in the sibling comment: https://news.ycombinator.com/item?id=43641081
> Anyway, you have an axe to grind,
I don't have an axe to grind. I correct the magical wishful thinking that exists around custom components
Github's https://primer.style/product/getting-started/ does a good job of making a cohesive design language that works just as well for server-rendering Ruby views and "upgrading" parts of the ui to React views when you need more interactivity. That's a constraint that I wish more of the Rails ecosystem design tooling would attempt to solve for.
Just saw a BugBytes video for a new one that might be interesting - https://devdojo.com/pines
I really think that a design system solution has to be framework/implementation agnostic. It’s why I’ve never been too interested in shadcn, impressive though it may be.
Right now I’m trying to build a tool that produces an intermediate representation of your UI components, which can then be transpiled into whatever target format you prefer.
That way we can build design systems that aren’t coupled to a specific downstream tech stack.
I honestly think the same.
I am curious - why is Bootstrap not on the list?
I came here to ask the same thing. Bootstrap 5 still rocks, at least for those of us who inexplicably don't love adding 40 classes to every element.
One of the things most frequently ignored on the comparison chart is the fact that there's a massive ecosystem of free and paid Bootstrap themes which can massively shortcut development.
There's so much bikeshedding and yak shaving when it comes to this topic. Folks spending their time considering options that also won't be Cool in two years instead of actually building The Thing.
I use TailwindUI for many of my rails projects. Or just grab some Tailwind things from around the web.
Tailwind has really rekindled my joy in creating views.
Yes, I have to maybe add a small note that might not be clear. I need something I can include for people in my Rails template. If it's fully commercial, I cannot redistribute it and my customers would need a license.
Is RailsUI superior to all of these?
I think now the ergonomics are now better - use vite-ruby, inertia.js and your fav design library with rails either with Vue | React | Svelte.