Fabricator – modular website design system | Hacker News Reader

Fabricator – modular website design system

fbrctr.github.io

46 pointsim_dario16 comments

Great! Looks quite extensive and deeply thought-out at first glance. Respect for the discipline required to ship something like this by yourself. Keep at it :) Iterate till you win.

Some constructive criticism, if it helps: it takes a while to understand what this is. On the home page, if you can have two panes, some code on the left with your framework and output on the right to quickly get a grasp perhaps?

Good luck!

Thanks for the feedback. I'll see what I can do to make the purpose of the project a little more clear.

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) 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.

Interesting. Looking around at the source now, it looks like it's not optimized to imply that sort of architectural thinking. That's a bummer. I'd love to have seen it take the React style approach of co-locating all the relevant parts to a module together.

Creator here. The lack of architectural direction is very much intentional. I'm a strong believer that those decisions will vary from project to project and developer to developer. My goal was to provide the least obtrusive set of tools as possible.

I do have some plans to create a boilerplate toolkit that includes some of the architectural patterns I use often. Hopefully that helps guide developers who are less experienced with building large modular systems.

What is Fabricator? A framework?

Edit: A UI toolkit-toolkit for building design systems.

It's really a set of tools to help you build a design system/toolkit. My goal was to bootstrap the development of (Twitter) Bootstraps for clients.

Nice looking design, but I had no clue what the tool was because I had clicked though too the documentation first! Also, say something about what problems pertaining to design guides this tool solves specifically somewhere front and center.

Yikes. I haven't revisited the site copy/design since I launched it months ago. I'll see what I can do to make the messaging more clear. You're right, it takes a bit of digging to discover what Fabricator actually does.

I like the logo!

Done by the super-talented Abby Putinski https://dribbble.com/abby-putinski

why?

Because a big part of learning is reinventing the wheel. Bonus points for creating a whole new taxonomy for things that have decades-old names in the industry :).

Which "decades-old names" are you referring to?

For instance:

http://fbrctr.github.io/getting-started/what-is-a-toolkit.ht...

Reading this I see a lot of things described by new names that we're used to know as "components", "modules" or "widgets".

And the page calls them "modules". Where is the new "taxonomy" you describe?

Reply on news.ycombinator.com