The past few years have been witness to an explosion of frameworks and libraries: CSS frameworks, WordPress theme frameworks, JavaScript frameworks, PHP frameworks…frameworks for just about any language you might want to write code in.

On one hand, this is great. As developers, we tend to solve the same problems over and over again. It makes sense to take advantage of code that’s already written that solves the problem we’re solving right now. On the other hand, it’s so easy to become over-reliant on frameworks. It’s so easy to solve every issue by looking for a a bit of code somebody else already wrote to solve our problem.

What’s so bad about frameworks?

I think that probably the biggest problem is one that I see growing and growing – new and junior-level developers who learn frameworks rather than learning to code from scratch. Rather than learning vanilla JavaScript, they learn jQuery. Rather than learning to make multi-column, responsive CSS layouts, they learn Foundation or Bootstrap. Rather than learning to build WordPress themes, they learn Genesis or Headway. Why is that a problem?

Because someone who’s got jQuery and Bootstrap down can build just about anything, right?

It’s a problem because there’s no real understanding of how the underlying languages work. There’s no knowledge of cross-browser CSS bugs and differences and how to work around them. There’s no knowledge of all the quirks and idiosyncrasies in JavaScript and how they can work for or against what you’re trying to accomplish. There’s no craftsmanship. There’s no deeper understanding of how multiple languages fit together or how the whole is greater than the sum of its parts.

If you can’t create a complex layout without using Foundation, then you’re not a front-end developer. If you can’t code up a slideshow without using jQuery, then you’re not a JavaScript developer. If you can’t create a WordPress theme without using Headway, then you’re not a WordPress themer.

If you don’t know how to create a multi-column, responsive layout that works across current versions of all major browsers without the use of a framework, then you simply aren’t equipped to properly evaluate a CSS framework and determine if it’s the right one for the project at hand.

As my good friend Alex Vasquez likes to say, every framework has a point of view. The person or persons creating the framework have to make certain assumptions, and he/she/they will have their own viewpoints on best practices, how best to deal with Internet Explorer, how best to deal with situations where JavaScript is disabled, etc. The best frameworks for you to use are the ones that match best with your own point of view, assumptions and opinions.

When is it appropriate to use a framework?

You might think after that little rant that I don’t use frameworks, but you’d be wrong. I do. In fact, there are a few that I’m downright smitten with. All their potential drawbacks aside, there are times when it just doesn’t make sense to re-invent the wheel. Let’s be pragmatic. When should you use a framework?

1. When you can read through a framework, understand everything it’s doing, and why it’s doing it. When you can understand what decisions were made, and agree with why they were made. Go grab an uncompressed copy of jQuery and read through it some time – it’s beautiful, it’s simple, it’s elegant, it’s smart.
2. When you wrote it yourself. Any developer finds themselves solving the same issues over and over – if there isn’t a pre-built framework that matches your style, create one yourself. You’ll learn more than you thought possible about the language you’re working in and will develop an even deeper and greater understanding.
3. When you are not, and do not desire to be, a developer, but you really just want to get something accomplished fast. In the real world, sometimes a business owner really does want to build out their own website. They don’t care about making a CSS layout work cross-browser for anyone but themselves. They’re unlikely to ever tackle a web development project again.
4. You’re learning and you need a leg up to be competitive. There are a million caveats here, but let’s face it – we all need to pay our rent, or land that job, or finish that project before the deadline. If this is where you are, see if you can poke around in the framework you’re working with to understand what’s going on. Read the documentation to understand the point of view of the creator and the assumptions that were made. A well-written framework can be a great learning tool. Be very careful not to rely too heavily on a framework – that’s like a baby that continues to crawl long after he should have learned to walk. Take every opportunity you possibly can to work without a framework so you can learn.

Hand-crafted by master craftsmen
(and craftswomen)

On a recent episode of The Big Web Show, Jeffery Zeldman described a perfect analogy.

Let’s say you wanted to learn to be a luthier – a violin-maker. You could attend an all-weekend intensive course in violin-making. There, you’d learn how to choose the best pre-cut pieces of wood to assemble into the violin body. You’d learn how to evaluate the different types of violin strings on the market and how to buy the best ones for the type of wood you used for the body. You’d learn how to buy the right bow to match the violin you made. You’re a luthier, but you’ve taken many shortcuts to arrive there, and you continue to take shortcuts while you ply your craft.

Or, you could go and be an apprentice in Stradivarius’s workshop. There, you’d learn to walk in the forest and select just the right tree to fell for the wood. You’d learn how to cut and cure the wood. You’d learn how to cure and cut sheep gut to make the strings. You might even learn which shepherds would sell you sheep that produced the best possible raw materials. You’d learn how to gather and treat horsehair to create a bow – what breeds of horses, what age of horse, etc. were the best. And eventually, after months or years of working with journeymen and masters, you’d eventually be awarded by a panel of masters and be allowed to join a guild and call yourself a master luthier. No shortcuts taken.

You can tear a poem apart to see what makes it technically tick, and say to yourself, when the works are laid out before you, the vowels, the consonants, the rhymes or rhythms, “Yes, this is it. This is why the poem moves me so. It is because of craftmanship.”

But you’re back again where you began. You’re back with the mystery of having been moved by words. The best craftsmanship always leaves holes and gaps in the works of the poem so that something that is not in the poem can creep, crawl, flash or thunder in. – Dylan Thomas, My Definition of Poetry

In our hurry-hurry world, we’re always in such a rush to get where we’re going, but there are no shortcuts to becoming a master.

It takes time to learn the nuances. It takes time to develop an appreciation and a deep understanding of a complex craft and to learn to do it well. And it takes time to continue learning as things change – as new browsers are released, as new versions of JavaScript and CSS and HTML are developed, as the web moves forward. It also takes a community of journeymen and masters to help you along your way.

Dig into the nitty-gritty details. Read up on different opinions about progressive enhancement and graceful degradation and form your own. Tear apart frameworks, looking for the assumptions, the points of view, the opinions. Look for all the places you can ask “What happens if …?” and find out. Experiment. Play. Ask questions. Anticipate the unexpected. Learn your craft and execute it beautifully.

Because code really is poetry.

Image credit: Alice Carrier