The problem is, well, it’s what I said right up there. Frameworks really aren’t an all-in-one solution are they? For all that we’ve made them modular and easy to customize, sometimes they just don’t have what we need.
A framework might have a lot of things we just don’t need. Some of my most frustrating work ever involved manually searching through Bootstrap’s massive CSS files to change some small bit of code that was wreaking havoc on my design.
Just take Bootstrap’s navigation bar component for example. It’s great, it works flawlessly, and it looks good. But if you try to change the way it looks in any big way, you have to change a whole lot of styles, and it takes a while to find them all. If it’s just a horizontal list of links at the top of the page that you want, it might be easier to code a new one from scratch.
But hey, the more popular frameworks out there, Bootstrap in particular, have a lot of customization tools, right? Yes, and that’s a great thing, but the default options don’t give you quite enough room to work.
Simply put, if your focus is on creativity, a massive framework is probably not the way to go. Sure, you can hack it, but that will take a lot of time.
Specifically, there was this one time when I tried to integrate a couple of jQuery plugins into a design based on Foundation. This isn’t a deal breaker all on its own, but it’s more time spent debugging.
Of course, this was some time last year. I honestly don’t know what would happen if I tried the same thing with the new versions of the same framework and plugins, but it is still something to consider.
In summary, there are times when frameworks simply aren’t the answer. This is where the toolkit comes in, and you should have one.
So what is a toolkit, and how is it different from a framework?
A toolkit, in the context of this article, is a self-collected and curated set of tools, snippets, plugins, and resources that allow you to code your projects that much faster. People will often find these resources over time and become attached to them. It’s a personal thing, and you really have to make your own.
- Toolkits and frameworks are both largely made up of code designed to help you get started.
- Their job is to make your life easier, but they can’t and shouldn’t do all of the work for you.
- They both need to be maintained and updated to reflect the latest technologies in play.
- Toolkits don’t make any design or structural assumptions, frameworks often do.
- Toolkits are usually made up of things that come from entirely different sources.
- It’s not just code, toolkits can include software, bookmarked links, and so on.
- Toolkits usually don’t have any “default files”, leaving you to pick and choose.
So when should I use which?
The advantage of a toolkit over a framework is its sheer versatility. As stated before, in projects where you intend to push the boundaries design-wise, a framework is often just too cumbersome.
That same quality is also the framework’s downfall in small-to-medium size projects. Are you building a promotional landing page? A one-page website? A simple blog? Then a framework is probably just unnecessary. You’re better off starting from scratch, and making every detail of the project yours.
I’d go so far as to say — this is just my opinion — that most content-driven websites don’t need a fully-fledged framework. The exception would be for massive sites, like ars technica for example. For something that big you should use a framework, but you should probably develop it from scratch yourself to meet the website’s exact needs.
Where frameworks like Bootstrap and Foundation truly shine is in web application development and app-driven websites. It is in these projects that the relatively rigid constraints come in handy, instead of slowing you down.
How to make your own toolkit.
Making your own toolkit is a question of time, patience, and experience. I mean, sure, you could just go and do a search for “web design resources”. You’d get thousands upon thousands of hits, and in a couple of hours you could download more bits of code than you could ever possibly use.
But that is not a toolkit. That is a library that you’re never going to touch, because sorting through it would take far too long. We’re busy people, so I’ve taken a more organic approach to this: when I encounter a problem, I Google it.
Snippets are often too long to memorize, so if I find myself repeatedly searching for the same thing, I add it to my toolkit. The same goes for software: if it’s something you know you’re going to use a lot, you add it.
That’s not to say that you should never set aside time to just experiment with some new “toys”… you should. If you hear about a particular resource that could change the way you work for the better, by all means check it out. But remember that toolkits are better kept relatively small. You should focus on keeping only what you require to meet the needs that you encounter regularly.
Again, I’ll reiterate that toolkits are something you have to make yourself, to meet your own needs. Still, I’m going to list the things in my toolkit to give you a better idea of what to look for as you create your own.
A CSS pre-processor
- They extend CSS basic functionality with variables, mixins, nested selectors, etc.
- They make coding CSS faster.
If you haven’t already tried coding CSS with a pre-processor, I urge you to do so now. Right now. I’ll wait.
A well-organized list of bookmarks can be greatly beneficial when you need something that you can’t save on your local hard drive. I bookmark things like CSS3 generators, sprite generators, color scheme creators, and other tools that help me to quickly accomplish tasks that take just that much longer when you do them by hand.
Semantic.gs: a layout engine
Grid systems are so 2000s. Ever since responsive web design became an actual thing, grid systems have become increasingly complex in order to meet the needs of myriad devices.
And what if you need a custom grid system? You could hit up one of the many online responsive grid system generators, but they’re limited.
The solution comes in the form of semantic.gs. Now, while its own author calls it a grid system, I choose to call it a layout engine, because it’s not one grid. It’s a tool based on CSS pre-processing (you can use it with LESS, SASS, and Stylus), and it allows you to generate any grid you like, fixed-width or responsive, on the fly.
All you have to do is change some numbers in a .less (or SASS, etc) file, and go.
Emmet – formerly known as Zen Coding
Emmet is a collection of plugins that turn abbreviations into full lines of code, in both HTML and CSS.
Basically, it turns this:
<div> <ul> <li><a href=""></a></li> <li><a href=""></a></li> <li><a href=""></a></li> </ul> </div>
How cool is that?
Snippets are those little bits of code that you keep using over and over again because they’re just so useful and you love them to bits, and you want to remember them all but you just can’t.
Any good text editor usually has a way to store and easily retrieve them. Right now, my favorite bunch of snippets would have to be this one for WordPress. WordPress’ template functions and options for functions.php can be difficult to remember, so this is a life saver.
As I said before, I’m not a real programmer. So when any kind of advanced animation or UI functionality is required, but not so much to make a framework worth the trouble, I turn to individual plugins.
Some of my favorites are:
- Scrollto.js: a smooth scrolling script.
- idTabs: for when you need any sort of tabbed UI.
- Supersized: for when you need a whole page slideshow.
- ResponsiveSlides.js: what the name says. It’s a responsive image slider. What more could you want?
It’s never too soon to have your own personal library of useful things.
What tools would you like to see in your toolkit? What resources couldn’t you live without? Let us know in the comments.
Featured image/thumbnail, mathematician’s toolkit image via Marc Kjerland.