When Chris wrote his idea for a Boilerform, I had already been thinking about starting a new project. I’d just decided to put my front-end boilerplate to bed, and wanted something new to think about. Chris’ idea struck a chord with me immediately, so I got enthusiastically involved in the comments like an excitable puppy. That excitement led me to go ahead and build out the initial version of Boilerform, which you can check out here.
I was asked to do a little session on this the other day. I'd say I'm underqualified to answer the question, as is any single person. If you really needed hard answers to this question, you'd probably look to aggregate data of survey results from lots of developers.
I am a little qualified though. Aside from running this site which requires me to think about front end development every day and exposes me to lots of conversations about front end development, I am an active developer myself. I work on CodePen, which is quite a hive of front end developers. I also talk about it every week on ShopTalk Show with a wide variety of guests, and I get to travel all around going to conferences largely focused on front end development.
So let me take a stab at it.
The following is a guest post by Tom Genoni. Tom is going to introduce us to the thinking and process behind Optimizely's new UI library / Sass framework. Part 2, by Daniel O'Connor, looks at some of the technical and integration bits.
When I first started working on web projects, stylesheets were seen as a necessary evil. It was neither a real language to be taken seriously by a computer-science minded engineer nor simple enough for a designer to fully own and understand. With few best practices, organization of the CSS was always ad hoc—“type styles in this section, colors in that section”—and every company did it differently. But as web applications, and the teams building them, grew larger and more complex it became harder to manage ballooning codebases while maintaining consistency across teams and projects.