nick am•os•ca•to (nĭk ăm əs `cä tō) n. A software engineer, designer and musician from Pittsburgh. [Italian.]

On Bootstrapping

Not too long ago, I was pretty much against using any kind of bootstrapped, boilerplate framework. Part of it had to do with my determination to prevent my projects from looking like others. I had this seemingly naive perception that by using an existing framework, I would be constrained. But more importantly, I felt that I would lose ownership of the project. There was something about being able to build something from scratch – after all, that’s what people did before these things existed.

Since I started back at The Resumator, I have started using some of these frameworks including Bootstrap, Compass and AngularUI’s UI Bootstrap. I have to be honest, it took some time to get used to this approach, but I have learned a lot in the process. No, I have not suddenly become a passionate advocate for front end frameworks, but my perspective has certainly changed.

First of all, the perception that I would be constrained in such a way that the work I produced would bear similarities to other projects built from the same framework was a myth. Sure some of these frameworks work right out of the box, enabling people to simply latch onto the defaults. However, as indicated by its name, a “framework” is meant to be a starting point; it is meant to be adapted to one’s needs. This seems obvious, but for some reason, it took me a while to come to that realization.

Adapted, not overridden. I think that’s the key. In my limited experience thus far, I am inclined to believe that the scalable organizational patterns provided by these frameworks are more important than actually using them. In some cases, I think it even makes sense to only use relevant parts of the framework, so as not to bloat your project with irrelevant fluff.

But that’s a lot easier said than done. It’s easy to throw in a quick hack that overrides or disregards existing aspects of the framework. However, these hacks are not scalable; you might as well just write things from scratch because you’re missing the whole point of the framework. Instead, a strict focus is necessary to adapt the framework to one’s needs. The framework’s reusable patterns become a model for the development of the entire project. In this respect, the project becomes its own scalable framework, an extension of the initial template.

Looking back on it, I don’t regret my decision to avoid these frameworks for so long. In fact, I would recommend starting off that way. You learn a lot when you build things from scratch – namely how to hack your way through any situation, a skill that is later used to adapt frameworks.

But you really don’t learn how to build a scalable architecture by hacking away from scratch. That requires some teaching. And what better way to be taught than to be exposed to existing frameworks themselves? Maybe someday, I will have been exposed to enough to begin making educated decisions on my own, but for now, I am looking forward to learning, using and comparing the frameworks out there today.

@namoscato: "Finale is to Sibelius as Nikon is to Canon."