The reactions are always interesting when I tell people that Pattern Lab requires PHP. Invariably there's an "Ew" or audible groan followed-up by the seemingly incredulous question, "Why?!" The obvious practical consideration is that PHP is what I know best so it would seem to make sense that that's the reason why it's written in PHP. But I could have learned something new if I had wanted to. The real reason why I'm using PHP for Pattern Lab? PHP keeps things simple and simple is good.

Dependencies are a Barrier

One of the primary goals of Pattern Lab is to reduce dependencies. Viciously reduce dependencies in fact. We want to make using Pattern Lab simple and easy no matter your level of experience. Consider our install process on a Mac:

That's it. No dependencies to install. No command line. Not even a need to configure and start Apache. Pattern Lab basically works out of the box. Really. And on your Linux flavor-of-choice or Windows there isn't much more that's required.

I've been doing web development for 15 years. I feel I'm experienced. If your project requires Ruby, Node, and Git to get set-up and running my eyes glaze over. Not only does the set-up appear to be a pain in the ass but I really don't want to deal with the maintenance of all it and how it might affect other projects. Now consider the newbie developer or designer. It can be just plain intimidating.

With Pattern Lab we wanted to deliver a product that anyone could download and have it just work. Simple. For example, a designer who is making the shift from designing in Photoshop to designing in the browser. This means bundling as much as we can. That's not to say there aren't things that they'll have to learn. Do they have to learn Mustache? Sure, but by being logic-less there's not a ton to learn. Do they have to learn the conventions of Pattern Lab? Yes, but at least they're conventions rather than configurations.

By aggressively limiting dependencies we've tried to lower the barrier to entry for something that I consider to be an amazingly useful change to all of our workflows, the use of modular systems of mark-up for development and client review.

But the reduction of dependencies, keeping Pattern Lab simple, doesn't mean that we put shackles on more advanced users. In fact, I think it makes the entire system more flexible for advanced users.

Progressively Enhancing the Dev Stack

The beauty of simplicity? You can build whatever workflow you want on top of Pattern Lab. By default, Pattern Lab offers its own watch, auto-reload, and page follow services. Conversely, it doesn't include things like a CSS pre-processor or JS hinting services. It's doesn't have an opinion about the latter. Pattern Lab is a very vanilla though hopefully capable base where parts of the default "stack" can be progressively replaced.

Want to use Sass with Compass? Have at it. Prefer LESS with Node? Sounds good. A developer can choose a pre-processor, let Pattern Lab watch for changes, re-generate the site and refresh the browser. Don't like Pattern Lab's watcher? Use Grunt to watch for changes, let Pattern Lab re-build your patterns using a shell task and still use Pattern Lab's auto-reload service. Or better, just use Grunt and LiveReload if that's your thing.

PHP allows us to sort of isolate and sandbox the core of Pattern Lab away from the rest of your stack. PHP doesn't mean that it can't be used with Node-based task runners. And I have a feeling that's how most people will approach Pattern Lab. Just one more simple task in their workflow that they don't really touch.

The Difference Between Using a Library and Editing a Library

Ultimately, my honest question to people who wonder about PHP or say "Ew" is, "Were you going to actively hack at and contribute to Pattern Lab if it was written in [insert hot language]? Will you now not even fire it up because of PHP? Really?" The primary task of the back-end of Pattern Lab is pretty simple: compile data and build patterns. It's a relatively specific task that shouldn't step on or duplicate any other part of your process. It shouldn't matter what the hell language it's written in. As others have already shown, it fits nicely as a Grunt task. Node and PHP being mixed? Oh the humanity.

Wrapping Up

Pattern Lab has its rough edges and has a ton of room for improvement. I have a list of things as long as my arm that I want to fix and tweak. One thing I'm not going to fix is our commitment to reducing dependencies and to keeping things simple. PHP, to me, is an important part of that.

About Me

My name is Dave Olsen. I'm a programmer and sometimes project manager with West Virginia University. I use this little corner of the web to share my thoughts on mobile. The views expressed on this site are mine alone and do not necessarily reflect the views of my employer, West Virginia University.

Upcoming Talks

I don't currently have any talks scheduled. If you're interested in having me talk at your conference, school or online event please contact me.

Smashing Mag's "The Mobile Book"

I was lucky enough to be a contributing author for Smashing Magazine's The Mobile Book. Filled with 336 pages of great content from the likes of Brad Frost, Trent Walton, Stephanie Rieger and many more The Mobile Book covers responsive design strategy, patterns, web performance, and the nitty gritty of wireframing and prototyping for mobile. It comes in both printed and eBook flavors. Learn more about the book, try out the free sample (8MB PDF) or buy your copy now.