As web developers, we have a choice when starting work on a new project: should I build it all from scratch or should I use some existing code that has already been proven to work?

For obvious reasons, we usually favour the second approach. Using pre-built code can dramatically decrease development time and increase code quality by allowing you to focus on what is unique to your application, rather than solving problems that have already been solved by smarter people than you (they exist, look it up).

These days, we are blessed with a plethora of choices when it comes to libraries and frameworks we can leverage to deliver our projects, so how do we decide which ones to use?

Is it a library or is it a framework?

The two terms are often used interchangeably, so a definition is probably in order. The following is from the great Martin Fowler’s article on Inversion of Control.

"A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client. 

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points."

So, are you looking for a set of useful functions you can use (e.g. jQuery) or are you looking for something to help you structure your code and control the flow of logic in your application (e.g. Angular)

Does it solve a problem you have?

It seems like an obvious question, but it is worth asking yourself. In fact, what is the actual problem you are trying to solve?

Take dependency management as an example. Composer does a great job of this for PHP projects, but it solves a problem I just don’t have. The PHP libraries we use are relatively static, with few external dependencies, so keeping them up-to-date and synched is not something I spend an inordinate amount of time doing.  It’s a great piece of technology, but I have no real need for it.

Is it well documented?

This is one of the more important questions to ask. Poor documentation can erode any time-savings you gain by using a framework or library and is certainly one may to ensure your developers are steaming at the ears.

We had one case where we were evaluating a really cool JavaScript framework when it was first released, and the documentation was so poor it reduced our poor intern to tears.

Is it open-source?

I don’t necessarily mean free here, although that doesn’t hurt. It is more a question of whether you can view and modify the source code. There is nothing more frustrating when a bug in your framework stops you from getting on with your job, but the source code is not available or is obfuscated so you can’t get in there and fix it!

Reading the source code is often the best way to gain a deep understanding of third-party code too, so you can learn how get the most out of it and pick up coding tips along the way.

Do you think it’s pretty?

Picking a framework is a bit like dating… you might want to play the field a bit until you find one that you, you know, *like*.  Once you commit to it, breaking up can be hard to do, so don’t be afraid to spend a bit of time together before you get serious.

Have a look at some sample code, download the source, build a ‘Hello World’, do whatever you can to work out if is ‘the one’. Does the file structure make sense? Do you like the way it is designed? Is it easy to work with? Do the variable and method names make sense to you?

If there is anything that annoys you on your ‘first date’, they will *really* annoy you once the relationship is consummated, so swipe left and try something else.

Is it active?

How often is it updated? Is there a thriving community using it? How many times has it been starred on Github? Is there a commercial organization driving the product – if so, how are they funded? How many questions are there on Stack Overflow about it?

The last thing you want is to be stuck with a library written by a first-year Comp. Sci. student in a dank dorm in Utah then abandoned because the lure of Call of Duty was too strong.

When in doubt go where the people are - or follow the money.

How much of it will you use?

Do an audit of the features you will actually use (or may use in future) and express it as a percentage of the entire feature set. If it is less than 50%, you may want to consider something a bit more targeted towards your requirements.

Some libraries and frameworks (e.g. Modernizr, jQuery UI) allow you to create a custom build of just the features you want. This is great for users (as they don’t need to download unnecessary content) and great for developers, as it reduces the amount of code they need to understand to be productive.

Does it play nicely with others?

If you’re anything like me, you’ll have a whole bunch of code you have written over the years that you like to use on various projects. Before jumping to a new framework or library, it is worthwhile considering how easy it will be to use your existing code with a new framework. How much rework will you need to do?

Also, look at the entire stack of technologies you use – does it conflict with anything else you use, does it integrate nicely with your other libraries, or is it going to be the smelly child in the corner that nobody wants to talk to?

You show me yours and I'll show you mine

We don’t use all of these for every project, and the list is constantly being juggled as new contenders are created, but following are the libraries and frameworks we currently use at Future Büro (in addition to our own code).  

SASSCompassSusyjQueryUnderscore.jsBackbone.jsGreensock Animation PlatformIsotopeParsleyJSModernizrLazysizesRaphaëlFastClickRequireJSGoogle Maps APIYouTube APIFroogaloopGraph APITwitter APIWeb Font LoaderCKEditorQUnitCasperJSZend FrameworkIP2LocationCampaign MonitorPHPUnitPHPConsoleMagento APIBigcommerce API