Wading Through It All
How do you know which libraries work well together? How do you tell which libraries overlap in functionality. Sometimes you mix and match to complement each other. Other times you fill the gaps yourself. But you’d not want to use Angular with Durandal, for example. They overlap way too much and it wouldn’t benefit you to use both. But you certainly could use a stack that fits well together like HotTowel which uses Durandal (soon I will release HotTowel - Angular too).
First, I recommend you do not try to keep up with every new library. Be aware of them, sure. But you can’t know everything (or at least I know I can’t know everything). I personally like to be aware of what is out there and investigate ones that fill a gap or interest of mine. I use social media, newsletters, blogs, hallway chatter, and other easy to consume channels to increase my awareness. Awareness is easy, low effort.
For example, I became aware of React recently. I heard it was a presentation framework like Angular, Ember, or Durandal. That alone did not interest me to go further. However, I learned the Facebook team was behind it, which caused me to have more interest in it. So I spent an hour on their site looking it over to learn what it could do and how it was different from the others. I learned enough to know it’s interesting, but stuck a pin in it to come back if time ever allows. I may get back to it (knowing me I will), but I’m not worried in the meantime. If anything, I learned they have a very different perspective on SPA. if you want to learn more about React, check out this “Why” post.
By all means, don’t switch to a new library just because it is new and cool. Have some evaluation criteria that means something to you and creates a return on your investment (ROI).
When evaluating a library, the amount of time I put into the investigation and the criteria I use depends on the risk to my application. For example, if I am looking at a presentation framework (like Angular, Durandal, or Ember) I expect more from it and will spend more time evaluating it. I’m betting my app on that library so I better be sure it’s a good bet. If I am looking at spin.js or toastr.js which have very specific uses, are very small, easily swappable, and most importantly DON’T affect the critical path of my app, I’ll try it out and not do as much research.
Here are a few categories I use to evaluate a library. There are in no particular order and are not equally weighted. You may have others, and some of these may mean little to you, so of course your mileage may vary. The key here is to choose criteria that matters to you. Here is my list:
- Social Chatter
- Well Tended
- Owner Reputation
Quality and Value
Let's hit each of these here, starting with quality and value. If the library works as advertised, does it at a high level, and adds value to my app then I'm going to check those criteria off as positives. Point blank, the library is a tool and if the tool does its job well, I'm game. It also has to add value ... because it could be high quality but not add value. What? Think about it this way ... assume you are using ES5 and you are looking at a library that helps you create a
for loop over an array. That may be of high quality. But it's not adding much value since you can use the ES5 array.forEach() syntax already. And if you are using ES3, you could just use a simple
for loop. However, if the library is high quality and provides something you don't already have easily, then that adds value. Something like toastr is an example of this, where you could certainly create your own toast logic, but the time you save in using toastr adds value to me since I can spend that time on other problems (only so much time in the day).
I get a lot of questions (100's) that are phrased like this:
Can I use library X with library Y?
It is a great question. It is a question you should absolutely investigate if integration is important to you. To me it is very important, because I want the flexibility to use a different library and not upset the universe. You have to decide if it is important to you, and if so, investigate it for the libraries you are choosing.
StabilityIs the library stable? Does it have few breaking changes? When the breaking changes occur, do the update the version accordingly and document the changes? Hugely important questions to ask. Many libraries fail on this respect. Some of the best ones are Angular, Knockout, Durandal, and jQuery because they spend a lot of effort to make sure you don't have a bad experience.
If the library is paid, I
expect demand this. No if, ands or buts.
Community and Social ChatterIs there community support behind the library? Do folks watch the repo in GitHub? Do they ask questions on google groups, StackOverflow, and other social channels? Do you see folks speaking on these topics at conferences (or at least including them in their talks)? I'm not saying be a follower, but I am saying that were there is smoke, sometimes there is fire. Keep an eye on it and most importantly, learn from their experiences. You may not want to be first down the road so you can avoid the pits, but certainly don't step in those same pits when you travel that road later.
Well TendedHow often do the owners contribute to it? How often do they resolve issues? Do issues sit there forever, uncommented? A stale repo is bad news. No commits, not issues, no watchers, no pull requests could be a sign that you want to avoid that library. Be aware of it. However, just because there are a lot of activity on a repo, it doesn't mean it is awesome. So here you just want to make sure you aren't looking at an inactive library.
ReputationWhat is the reputation of the team behind it? This is hugely important to me. I know that Angular, Durandal, and Knockout have great minds behind them, both which have experience in this arena. Both keep things up to date. Both know what their tools do well and stick to that plan. Both pay close attention to the community. To me, that speaks volumes. It is foolproof? No. Just because Google runs Angular doesn't mean it will be the bees knees forever. Google (like Microsoft and other big boys) also has a history of moving on. Nothing lasts forever. So if you want a library to last forever, technology is not the space for you :)
The key here is know who makes it.