Papa's Perspective

JavaScript Libraries: Picking the Right One for You

As more JavaScript libraries spring up and battle to survive, developers stand to benefit from great solutions that fit a variety of needs.

Today's Web landscape is fraught with numerous JavaScript libraries that are valuable. So it's inevitable that you'll ask yourself, "Which ones should I be using?"

I spent several weeks this spring at various developer conferences, user groups and code camps. The biggest change I saw from this time last year was the tremendous uptick in JavaScript libraries and the interest they generated. During one discussion, someone made the astute observation that the group had mentioned more than a dozen JavaScript libraries in a matter of minutes: jQuery, jQuery UI, Bootstrap, JsRender, KnockoutJS, Backbone, Kendo UI, Jasmine, QUnit, Upshot, Modernizr, jQuery Mobile, Underscore, AmplifyJS and several others. I imagine casual observers listening to that conversation must have been left more confused than when they started.

Often, libraries cover the same ground. You might use QUnit or Jasmine for testing JavaScript code. You could choose jQuery UI, Bootstrap or Kendo UI for UI widgets, but you wouldn't use all three. However, jQuery and Modernizr are two libraries you might use alongside any of the other libraries.

What Do You Need?
The key is to first figure out what you want to achieve. I like to categorize my needs and see which JavaScript libraries can assist with each category. Then I evaluate each library's API documentation, community adoption, performance, stability and feature set (in no particular order).

Most of this research can be done by checking GitHub, Stack Overflow and Google Groups to find out how other developers are using the libraries. After evaluating the libraries, the tools I thought I'd choose often aren't the ones I end up picking. That's why it's always worth doing a quick gut check before getting started.

JavaScript libraries overlap, some of them don't play well together and some libraries appear to be the flavor of the month. Many of these JavaScript libraries are in survival mode, similar to a gunfight at the O.K. Corral.

So why is there so much churn in this space? First, you have to understand that innovation in the JavaScript world isn't just beginning - it's been happening for 15 years. Perhaps the biggest influence was the introduction of jQuery, which many agree is the most pervasive JavaScript library. jQuery has helped make cross-browser development much simpler with a small, consistent API that performs well.

Many JavaScript libraries are dependent on jQuery. Some tools aren't, but they can adapt if jQuery is present. JsRender is a templating library that doesn't depend on jQuery, but it works quite well with it. jQuery continues to influence libraries, which seem to be springing up all the time.

Which brings us back to the point that manages to confuse a lot people: How do you deal with the high churn rate in this space? How do you know which ones are good and which ones will stick?

Picking a Winner
The problem isn't the churn rate, but rather that developers are predisposed to picking a winner. We place a lot of emphasis on the best choice - the one library that will last the longest, and have 10 more versions. The JavaScript library that will make other developers bow down, awed by our ability to pick the proven winner. Hey, I do it too.

Maybe, just maybe, in this space it's not crucial to pick the winner. Maybe it's OK just to pick a horse in this race that's great, but maybe not the best. I think that's one of the exciting parts of developing in this era. You get to choose from a stable of great JavaScript libraries. We learn far more by being different, and embracing that difference, than we do by being the same.

Yes, I know companies like to hear about the roadmap, the longevity, the support for the technology. But you have to consider what problems you're trying to solve first. Companies primarily want to know that a technology will do the job well, and that their developers can continue to use it and adapt it as needed for a reasonable number of years. It's a mind shift for sure, but one that's reasonable and has many benefits.

So what do you do? Ultimately, the winner in this race is not a single library. It's the developers who use the JavaScript libraries, the companies they work for and the consumers of the Web applications. So instead of trying to make sure you find the next Wyatt Earp, you might be OK with a Doc Holliday. They both survived that battle at the O.K. Corral, and while they were very different people, you might find that you're the one who benefits from seeing the different perspectives.

About the Author

John Papa is a Microsoft Regional Director and former Microsoft technical evangelist. Author of 100-plus articles and 10 books, he specializes in professional application development with Windows, HTML5, JavaScript, CSS, Silverlight, Windows Presentation Foundation, C#, .NET and SQL Server. Check out his online training with Pluralsight; find him at johnpapa.net and on Twitter at twitter.com/john_papa.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube