one man show dev: part 2

rise of the framework

Over the past years we've seen many frameworks spring to life. Just a few years ago we had one or two javascript frameworks to choose from, now we can also find frameworks for our html and css work. We can even go deeper and download boilerplates to build our own framework, going completely Inception on our everyday job.

Frameworks are usually built for one of two main reasons. Either the job has become too complex and time consuming to learn by heart, or there's a repetition of successive tasks that needs to be executed a lot. Being a professional web developer means you're using the framework for the second reason, saving yourself time to spend on more pressing issues. Sadly though the reason I stated first is one of the prime successes of the frameworks out there today, leaving many people clueless about the finer points of the job.

This ties in with what I explained in my previous post. Back in the days writing html used to be quite simple. You didn't have too many elements to choose from, writing an h1 instead of p class="title" was considered excellent coding and even though people were working hard on the next-gen html, nothing much ever changed. The need for a html5 boilerplate indicates that writing html these days is a bit more complex than it used to be, and so frameworks are created to help people overcome these complexities.

the beast within

I've voiced my concerns about frameworks before and I still believe these concerns are relevant, probably even more so, today. Frameworks can be extremely useful to get started with a language you aren't familiar with, hiding most of its nasty bits, but at the same time they will limit your knowledge and creativity.

Using the jQuery example once again, it's perfectly fine to use this fine library for avoiding the cumbersome task of querying elements on a page. The dom selector engine in jQuery is a real time saver. But even then, actually knowing how to do this cross-browser with regular javascript is definitely necessary is you want to sell yourself as a javascript expert. Once you start fiddling with jQuery UI components though, you're entering the territory of quick and dirty coding. From what I've seen from these components, the html code is crap and most components are far from accessible.

The bigger the task you are trying to capture in your framework, the bigger the chance you will yield sub-optimal results. And if you only know to work with a certain language through a framework, your output as a developer will never rise above the strengths (but more importantly, weaknesses) of said framework. You'll be confined by the limitations of what your framework can do for you, trying to solve problems with the limiting tools you have (or can find online) rather than going for the best possible solution.

conclusion

Frameworks offer many out of the box solutions, but most of the time these solutions are of moderate quality (trying to put it mildly). I have never seen a CMS out there that generates decent html by itself, I haven't seen too many javascript UI components that generate something I would put in my code without a definite sense of shame. Of course most of these out of the box solutions look quite okay when viewed in the browser itself, and if that's the level of quality you're aiming for then that's fine I guess, but I would hope that most modern web developers have higher standards.

Use frameworks when it saves you time on repetitive tasks or when you really lack the resources to get a pro for the job, just don't fall into the trap of relying on frameworks without knowing what it is actually doing in the background. You'll lose the ability to properly judge its output, which will directly reflect on the quality of the job you're doing. It may be true that it's easier than ever to built a site all by yourself using frameworks, but the quality of the site will be reflected in this approach and in the end there will only be one person accountable for that.