In a spate of recent projects, I often found myself trying to solve similar problems.
Part of me appreciates this process, given that every time I work something out, there is an opportunity to gain additional insight into the issue. Another part of me, however, is wondering if my time might be better spent elsewhere.
For example, what’s the best way to mark up pagination on a page? Do I add a class to the container only? Do I add classes to the list and each item? Every link as well? Which element gets the active state?
These aren’t hard problems, but multiply them over many projects, over an entire career, and it starts to feel like wasted time.
One solution to the dilemma is a framework. Frameworks offer a comprehensive set of components and scripts to aid in the building of a website. These frameworks will also dictate, to a degree, how particular components should be marked up.
Diving into the world of frameworks can be tough, because it feels like an all or nothing proposition.
The ninja leads a simple life, and walks the world framework free. It codes HTML from scratch, and when a problem presents itself that is greater than its own knowledge, it will reach out for a focused, single-purpose solution.
The power of this approach is that for any given problem, the ninja gets to search for the best. It will employ only the most powerful scripts to solve a particular problem, but the ninja has no loyalty, and on the next project will start fresh again.
The ninja, however, can often run into problems. When the requirements for a project start growing, cobbling together disparate tools can start to get unwieldy. Errors become harder to debug and problems become harder to find. The once sleek and nimble ninja can quickly become burdened by its own tools.
The cyborg comes prepared for any number of challenges. It doesn’t rely on stealth, but raw power. It comes to the project with an arsenal of tools, and if they aren’t used right away, it still has access to them down the road.
Because the cyborg comes prebuilt, we know its tools will work as expected. We know conflicts and errors are minimized, and behind the cyborg is a support team, a community to help should problems arise.
The cyborg, however, doesn’t feel appropriate in all occasions. Using one or two of its components seems like a waste for a tiny project. Also, what happens when it doesn’t do one particular thing well or at all, is it going to be easy to swap out just one piece? What if we need to swap out two or three pieces? At what point do we start wondering why we chose the cyborg in the first place if we end up replacing parts of its functionality?
I started thinking about frameworks primarily because at one level, they offer consistency. There are a lot of ways to tackle any particular problem, and when a bunch of smart folks put together a handful of solutions, that’s something worth looking at.
On the other hand, can focused and high-quality individual components outshine a package of average ones?
My assumption is that as the world of web development matures, standardization is going to become important. The nature of web languages means that for any given problem, there are a tremendous amount of solutions, making the search for a right answer difficult.
Perhaps there will never be a single right answer, and perhaps the process of searching is just as important.