OCT 23, 2020Avoiding time-wasters and unnecessary complexity

It's 3:35am now, and I've literally wasted three and half hours trying to get StorybookJS to work with SurfaceUI. I've previously tried Storybook and discarded it because of its complexity, before trying it again today I knew the odds were that I'd end up in shame, but I needed to give it a second try again because I assumed that the effort required to setup a documnetation site with preview for React components, would take more time and effort to maintain compared to a solution like Storybook with the docz action. Turns out that I was wrong.

In my opinion, the complexity a solution like StorybookJS brings to the table is not worth its use for a simple component library like SurfaceUI. This is a simple component library, maintained by one person who's both the designer and engineer means that speed and ability to iterate on the fly is far more important to me than any other thing else. Spending time on configuration files, making Storybook work with TypeScript, making documentation work properly with MDX format, and the fact that with each additional component, Storybook build times increases, means I'm incurring more downtime in my workflow that can be totally avoidable without any downsides.

If SurfaceUI is used by a large team of designers, and engineers across a broad prooduct ecosystem, them maybe using Storybook alongside its complexities would be worth it, but still who knows?

Have a great day.