Blog.ociat.co.uk Ociat Web Design and Development Company
Let’s start with an observation: I love me some frameworks. As an alternative to completely reinventing the wheel, or styling a button from scratch, again, it’s hard to beat having an all-in-one solution to your basic HTML/CSS/JavaScript needs.
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.
It’s impossible to include every possible HTML snippet, element style, or javascript function one could possibly need. But then, that can also be a good thing.
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.
One more problem that I’ve run into: JavaScript incompatibilities. As a guy who isn’t really a programmer, this was painful.
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.
Similarities
- 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.
Differences
- 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.
