Why Pattern Lab vs. KSS Node or other tools?
Randy: Pattern Lab has a lot of direct support and options for precisely the workflow that we’re looking to use. It is built from the beginning to adhere to the component-driven design principles that we use at Four Kitchens while allowing flexibility for modifications. Out of the box it has categories for atoms, molecules, organisms and etc., and if that categorization doesn’t work for your project they can be easily renamed and restructured.
Evan: It wasn’t super clear from the beginning, but one thing we did know is that Pattern Lab has a lot to offer. From the biggies like the atomic design structure to the niceties like a built-in UI with search, responsive testing and hiding/showing pattern data globally.
Randy: Pattern Lab also comes with tools for reviewing the project with an eye towards all device sizes. One such tool resizes the page presentation to small, medium, large, or extra large so that components and templates can be reviewed at the correct size. Each time you choose a size, like small, it resizes to a random dimension that is considered “small” so that you don’t run into the issue of only reviewing small screens at just the dimensions of an iPhone.
Evan: For me, having a styleguide built around atomic design principles in such a strong way—reinforcing it at every step for developers and stakeholders—was a huge benefit. I did have some critiques though.
What were your critiques of Pattern Lab?
Randy: While we were reviewing Pattern Lab there were a number of criticisms that were wiped away when they released the latest version, so my answer to this question is much shorter than it would’ve previously been. Currently my main criticism is that Node support is lacking, though I will admit that it is improving.
Evan: Yeah. We wanted to choose a tool that could be a standalone prototyping tool to be used with any given system. In other words, we wanted the UI to be portable and not require the designer to have system-specific knowledge to build. Even within Four Kitchens, we have teams working on various CMS projects and teams working on Javascript/Node projects, but we wanted our clients to have that same portability as well, regardless of their current system. We all initially rallied around have Node-based solution, as that technology is fairly ubiquitous currently. The first version of Pattern Lab (the current version when we started our research) didn’t specify Node support.
Randy: When Pattern Lab was first released it was PHP only and that is the version that we’re currently using. While this works for our Drupal projects, I’d rather have a more portable code base that can be used with any of our projects that may be on a platform that isn’t PHP. There is a node version of Pattern Lab and the last time that I reviewed it, I ran into a number of bugs and issues which forced me to just continue to use the PHP version. It has been a while, maybe I’ll go and give it another shot now…
Evan: We also preferred to be able to write pattern data easily, and Pattern Lab v1 required you to use the JSON format, which was not our favorite.
What were your critiques of KSS Node?
Evan: KSS Node has a big gap in terms of the default UI. That’s still a gap in the open source space right now (at least last I checked)—a great Pattern-Lab-ish theme.
Randy: I want to say that right out of the gate I thought that KSS Node was going to be the right direction. KSS has been around for years and has wide support. But once I started to use it, I realized that I had to invent a supporting process around using it. I had to answer how to organize the components, where do the files go, and how is everything presented? I’m usually up for creating my own custom solutions, and I started that with KSS Node, but once I started seeing what Pattern Lab was doing I just couldn’t justify the time to reinvent the wheel.
Evan: Yeah, the lack of atomic design reinforcement by default was a negative for me. Also, just personally, I never liked the aspect of putting component descriptions into CSS comments.
What finally pushed the frontend team over the edge in deciding between the two?
Evan: The release of Pattern Lab v2. We were all on the fence before that, and then they took care of our two biggest issues, namely Node support and data in YAML vs. JSON.
Randy: The decision was neck-and-neck until Pattern Lab made a large update release that removed most of my objections to Pattern Lab.
Evan: Also though, Twig became a first-class citizen in v2—the implementation worked really well out of the box. Also, v2 separated out dependencies at the core level, which at least made it a little more clear what was happening under the hood.
Randy: Then it was like a big kid getting on a teeter-totter and Pattern Lab won.
Thanks to Evan Willhite and Randy Oest for this discussion.
Read the rest of our Frontend Style Guide Miniseries:
- Part one: Introduction by Joe Tower
- Part two: KSS Node by Randy Oest
- Part three: Pattern Lab by Evan Willhite
- Part four: Discussion with Evan Willhite and Randy Oest
Making the web a better place to teach, learn, and advocate starts here...
When you subscribe to our newsletter!