My two cents: I work for a medium-sized company that has used Fabricator to build UI component libraries for clients. In each project where Fabricator was used,

My two cents: I work for a medium-sized company that has used Fabricator to build UI component libraries for clients. In each project where Fabricator was used, the deliverable source code (CSS and JS) has been both messy and inconsistent. This is due to that fact that Fabricator does not assist or guide the developer when they develop CSS and JS for their modular design components. (See http://fbrctr.github.io/building-a-toolkit/assets.html http://fbrctr.github.io/building-a-toolkit/assets.html) This diminishes any ability to reuse components/widgets/atoms etc across projects. The tool does enforce and encourage atomic design architecture when it comes to HTML. At best, I'd describe Fabricator as a static-site/documentation generator. However, I wouldn't recommend using it Fabricator to generate documentation in the 'toolkit' way that's recommended in it the docs because it tightly couples that static site/documentation generation to UI library source. There are plenty of static site generators that work well for generating docs that I'd rather use (jekyll, hugo, etc). I'd encourage developers considering Fabricator to proceed with caution. Although, it boasts ease of UI development based on atomic designs, the tool does not aide in code modularity or UI component re-usablity.