Quiet UI - My Creative Outlet

I recently released a side project called Quiet UI. It's, perhaps unexpectedly, a component library. This begs the question:

“another UI library? But why?”
— somebody on Hacker News

You probably already know about Shoelace, an open source project I started more than eight years ago. It got pretty popular and was ultimately acquired by Font Awesome. Of course, I joined the team and we held a very successful Kickstarter to reintroduce the project under a shiny new name: Web Awesome

Over the last three years, we've assembled a dream team to support Web Awesome and build out Web Awesome Pro, an optional upgrade to sustain the open source project.

Aside from weekly bug fixes and daily human support, the Web Awesome team and I have designed over a dozen pro themes, a collection of professionally-curated color palettes, a growing library of patterns, new pro components, a custom theme builder, a web application with auth/payments/et al, a really cool dashboard, and infrastructure to support our free and pro CDNs.

As you can tell, we've been busy. And we have a lot more to build. Web Awesome is full-steam ahead and we'll be launching to the public in October. 😅

Back to the basics #

Through all the effort and excitement, I found myself longing to build something for fun. I'd see new Web APIs drop, but didn't have the time or space to explore them at work given other priorities. Furthermore, Web Awesome has designers that can run circles around me. The folks with actual design skills are rightfully in charge of design now.

I'm no visual designer, but I can build components pretty damn well. But I missed designing them. And I wanted to play with bleeding edge features that weren't available in all browsers yet. Things like ElementInternals, Custom States, and the Popover API just to name a few.

None of those had decent browser support a few years ago. And they definitely couldn't have gone into Web Awesome.

One night I had the urge to build a button. I wanted to take everything I learned from developing components over the years and challenge some ideas, try new things, and bake in opinions that I've traditionally veered away from. It felt liberating.

Since I wasn't responsible for the form-associated custom element migration in Web Awesome (that was all Konnor), I built a text field. This is where I learned ElementInternals. Watching a custom element work with Constraint Validation for the first time was incredible…and impossible in the earlier days of Shoelace.

Oh, and I might need a spinner so I made one of those too because spinners are easy, except this time I used SVGs instead of rounded borders… 🥲

At this point, I didn't have a name or even a proper project. I was just creating files in a folder with a handful of custom elements and hardcoded styles.

Moonlighting in color #

Around the time Evil Martian's released its Harmony color palette, I began experimenting with color-mix() and the OKLAB/OKLCH color spaces. Years ago, I tried to generate color palettes for Shoelace 1.0* using HSL and, because it's not a perceptually uniform color space, the results were always meh. With OKLAB/OKLCH, we get much better results.

I went on a mission one night to recreate every swatch in every one of Harmony's color palettes using pure CSS. To my surprise, I got really, really close!

Taking learnings from Shoelace and other projects I've been involved with, I created palettes using color-mix() and OKLCH. Primary, neutral, destructive, and constructive — each one generated from a single, mid-tone color with pure CSS.

Next, I created smaller palettes: each variant contained a subset of five colors. Eventually, I'd switch to using volume as a metaphor, which is easy to remember and fits with the name.

With these “design tokens” in place, I soon revisited all the components to retrofit the tokens. It took some tweaking, but with adaptive palettes and the occasional use of color-mix(), I was able to style every component. And they looked really good. It turns out, constraint encourages consistency, and consistency is critical in a component library.

And just like that, the project that would eventually be called Quiet had a theming layer.

What's in a name? #

Over time, I kept hacking away at new components, some wildly different than anything I've explored before: a joystick for touch devices seemed fun; a stamp that “stamps” out templates might be useful; slide-to-unlock is a throwback to early iOS; a lorem ipsum generator would be cool…

As more components were added, everything that came before it slowly got polished or improved. When I didn't feel like coding at night, I'd read through what was there and fix typos. Or colors that were too dark. Or borders that were too round. Or find and fix random things I'd stumble on while clicking through the demos.

I kept track of bugs and ideas in Bear which, if you're in the Apple ecosystem, I highly recommend. When I stumbled on a good idea for a component that might be fun to build (sup, flip card), I'd write it down.

But a component library isn't complete without the usual suspects: badges, cards, dropdowns, form controls…the basics. So I built those too. What value is a library of components if it's incomplete?

At some point, it only made sense to give the project a name. I looked up all the words that had the letters “UI” in them and, lo and behold, nobody was using “Quiet” for a UI library. I really loved the simplicity of it and, shockingly, the domain was available.

Thus, Quiet UI was born.

Wrangling AI #

These days, you can't open a browser tab without hearing about AI. I previously avoided it, but now feel it's inevitable and decided I didn't want to get left behind.

Quiet was a perfect place to experiment with AI without affecting actual users. This is where I learned how to use (and how not to use) Claude, Grok, ChatGPT, et al.

To be clear, I don't vibe code components, but I do use AI to speed myself up. I design every single API myself, then generate a prompt carefully explaining the API and how I expect it to work. Providing code examples from components I've written by hand for code style/convention helps a lot. Then I carefully review everything the LLM spits out. Sometimes it's wrong and needs to be adjusted manually. Sometimes it's spot on.

If my keyboard was a hammer before AI, it feels more like a pneumatic nailer now.

For comparison, I built a splitter from scratch in a matter of hours. When I built a very similar split panel for Shoelace, it took me a few days. (For this experiment, the AI was unaware of the Shoelace component and went solely off my API design and instructions.)

So yes, in some cases AI can be used to increase development speed, but I think that's largely due to the modular nature of the library and my familiarity with designing APIs for components I've built numerous times before. I'm not convinced it would perform as well in large or complex codebases [yet].

Quiet + Web Awesome #

Quiet has come a long way from a couple misfit components in an unnamed folder to a fun library that I'm really proud of. It's taught me a lot of things over the last few years and, since I enjoy doing this type of work, I've decided to release it for others to use.

Which brings me back to Web Awesome.

Quiet is my creative outlet. It's not trying to compete with Web Awesome. It's intentionally simpler in a number of ways.

I like building things, and I see Quiet more as a testbed for things that may or may not make it into the more stable and mature Web Awesome. In fact, we've already adapted a number of components from Quiet into Web Awesome, including popover, slider, intersection observer, scroller, and soon we'll be bringing in file input and toast.

- <wa-popover>
- <wa-slider>
- <wa-intersection-observer>
- <wa-scroller>
- <wa-file-input> (coming soon)
- <wa-toast> & <wa-toast-item> (coming soon)

If you've backed Web Awesome, you're in good hands. October is going to be a very exciting month for you!

If you're looking at Quiet UI and wondering why it has more components than Web Awesome right now, that's because Quiet is my personal playground. There are things in there that probably don't belong in Web Awesome, and none of Quiet's components will work with Web Awesome's robust theming system.

The components that make sense to upstream into Web Awesome will be adapted in time. But that's not a decision I make. It's a decision everyone on the Web Awesome team makes together.

Why not open source it? #

I intentionally chose not to release Quiet under an open source license. Instead, I've made it source-available so anyone can use it and learn from it in noncommercial applications. This ensures nobody can fork the project and, for example, compete with Web Awesome.

And, since everything is getting more expensive in the world, I decided to sell commercial licenses for anyone who's interested in using it in a commercial application. I'm proud of it and I think there's a lot of value in Quiet UI and it would be a shame to not let people use it.

But offering licenses for Quiet is akin to painting pictures in my garage and selling them at the craft fair. In contrast, Web Awesome is a Michelangelo.**

Web Awesome ranked #3 for the most-funded Kickstarter projects in the software category when the campaign ended. We're building a massive pro offering on top of it. It has an active and growing community. And it has myself and full team behind it making damn sure it's stable and successful.

But for those nights and weekends when I just want to play around with new ideas or learn something new…I'm reaching for something quiet.