Some of these libraries are practically must haves, employed by just about every site on the web. Others are more specialized—you need them only when you have specific functionality on your site. But all of them have managed to distinguish themselves from the rest of the crowd in one way or another (in alphabetical order):
Go ahead; admit that you’ve found HTML5 a little less comprehensive than you wanted it to be. AngularJS is here to remedy that situation. Many developers rely on the Model-View-Controller (MVC) approach to creating large-scale applications, and the AngularJS framework makes it possible to extend HTML by acting as the controller portion of MVC. Controllers are the behavior behind Document Object Model (DOM) components. AngularJS makes it possible to create new behaviors in a manner that is both natural and straightforward. The extensions end up looking like additions to HTML, rather than something bolted in place.
However, the coding can become complex and this framework may be more suited to enterprises than small startups. Even the simple examples on the AngularJS site rely on multiple files that quickly create complexity.
Backbone.js provides the model portion of MVC. The model is the representation of an underlying data source. For example, you might need a model of a corporate employee list or data from the company’s catalog as part of your application. Whatever the data source, the model describes the data, its format, and the means for dealing with the data. It creates an abstraction that makes it possible to deal with the data without tying it to the DOM. As a result, Backbone.js deals with events, such as whether the object is on or off, and model methods, such as getting or setting an attribute. In fact, it has a long list of features that make working with the model easier, but requires a relatively steep developer learning curve. Fortunately, the vendor also provides a relatively large list of examples so you can see how to perform key tasks.
Many websites are data or content driven. For example, if you go to a news site, the news changes nearly every time you visit. The information is definitely dynamic and trying to reconfigure the site’s setup every few seconds to support changes becomes impossible. The D3.js library is unique in that it puts the data and content first.
The main advantage of the D3.js library is its extremely flexible handling of content, sometimes at the cost of a bit of pizzazz. For sites devoted to selling products rather than presenting information, D3.js may not be the best choice. In addition to extreme flexibility, D3.js also tends to be fast because it eschews a lot of the baggage other libraries use to create slick presentations.
Few websites get by without using jQuery and jQuery UI. Yes, there are other libraries that perform the same tasks, but jQuery and jQuery UI are so good at the job they do and they receive so many quality updates that most developers rely heavily upon them. Many sites use jQuery for basic DOM manipulation for three essential reasons:
- First, jQuery is incredibly easy to learn. The site provides not just one or two examples like most libraries, but enough of them so there is a good chance you’ll find an example that demonstrates how to accomplish your specific task.
- Second, jQuery is incredibly fast. Because it focuses on performing specific tasks well, jQuery makes it possible to perform those tasks quickly.
- Third, there is a huge installed base of community support and add-on creators for jQuery.
Of course, there are costs associated with anything. For example, jQuery doesn’t always work exactly the same way across browsers. The vendor is actually up front about these concerns and you can find information about browser support on the JQuery site.
Also, unlike other libraries listed here, jQuery isn’t a complete solution. You need another product, such as jQuery UI, to build a complete application. Your site will be more modular and dependent on more libraries when working with jQuery (which isn’t necessarily a bad thing).
5. jQuery UI
You use jQuery UI to add basic graphic elements to your application after you incorporate jQuery. The jQuery UI library comes with all sorts of interesting widgets to configure your application to provide great services to the end user, along with a little visual spark to keep them interested.
Most importantly, jQuery UI works with just about any browser available: You won’t have a lot of people complaining that your application doesn’t work as expected. jQuery UI also boasts a vast number of available add-ons. For example, jQuery UI lacks a time picker, but you can easily get an add-on to perform that task from places such as http://trentrichardson.com/examples/timepicker/.
Many documents are easy to present on the web using common programming techniques. However, the Portable Document Format (PDF) file is a desktop document that defies easy presentation using standard web techniques. Given the amount of information found in PDFs, you really do need PDF.js in your programmer’s toolkit to ensure you can properly display this kind of document on screen.
React provides the view portion of the MVC. It doesn’t assume anything about the underlying technology stack that you’re using to model or control the data. All React is interested in is displaying the data on screen. With this in mind, it doesn’t rely on the browser DOM, but instead relies on a light virtual DOM that makes displaying the information quite fast. The price you pay for the speed and ability to use MVC is complexity. Even a small component requires quite a bit of code (as demonstrated by the examples on the vendor site). What you gain is flexibility and speed when working with really large projects. (As far as I know, React doesn’t support the newer Models-Operations-Views-Events, MOVE, approach.)
React is still in beta, but some developers are already using it for production work. It’s a good idea to be extra careful when relying on beta products, but React provides cutting edge features that you may not be willing to wait for, especially if you’re maintaining a really large site and MVC is essential to getting the job done.
Many websites still present multi-media effects using Shockwave Flash (SWF) files. Of course, you could just embed the SWF files as an object, but then you couldn’t provide a specific version of the SWF file to go with the version of Shockwave Flash installed on the client system. And your site would just sit there, apparently broken, if the client doesn’t have Shockwave Flash installed. The SWFObject library helps you overcome these problems by helping your site provide the sort of content the client actually requires. Even though using this library adds to the complexity of your application, it can help ensure most users see Flash effects as you intended, no matter what setup they might have.
It’s important to realize that every website and web application is unique. When considering any library, there are a few key things you need to take into account:
- Ensure your library is flexible enough to meet your needs so that you don’t have to worry about odd kludges or workarounds to get the job done.
- Check on how often the library is updated to meet new application requirements and to ensure compatibility with new standards.
- Verify that the library is secure before you use it for a critical application. Trying to fix security problems later can be nearly impossible.
- Ideally, choose a library with strong community support—you might be surprised how often you’ll need it.
- Check out some simple example applications to discover how well the library is written and whether the documentation is actually usable.