Chapter 2
Libraries, Frameworks, and Plugins
In addition to following best practices, you should build your app on a solid foundation of libraries and plugins. Sure, you could write everything yourself, and there is indeed a time and place for that. But in most cases, it makes more sense to rely on the open-source work released by other developers.
Libraries and plugins can help speed up your development process and jumpstart your app with a boilerplate of basic functionality. Best of all, the well-known libraries have a huge community behind them, with excellent developers writing and rewriting the code, and a vast user base uncovering any bugs. With the more established, tried and tested libraries out there, you can be confident in using them in your application.
Plugins, on the other hand, are a little spottier when it comes to code quality. A good plugin saves you loads of time, while a bad plugin may end up creating more problems than it solves (and force you to spend more time debugging it than you would have spent writing it from scratch).
In this chapter, you discover how to choose the right JavaScript library for your project. I compare jQuery, Zepto, and writing your own vanilla JavaScript. Then you learn about the larger frameworks Bootstrap and jQuery UI. After briefly discussing how Modernizr can streamline cross-browser CSS issues, I show how HTML5 Shiv builds support for HTML5 elements in older browsers.
Next, I discuss HTML5 Boilerplate, which is neither a library nor a framework. It's a best-of-both-worlds template that you can use to gain all the advantages of a framework that can speed up setting up a standard HTML5 application.
Finally, I dive into jQuery plugins. You will look at good places to find new plugins, as well as a ten-point checklist you can use to determine whether the plugin is good enough to integrate into your project.
Choosing the Right JavaScript Library
One of the most important decisions you'll make at the beginning of a JavaScript project is which library to use (or whether to use a library at all). A good JavaScript library can streamline your development process, providing you with a variety of standard utilities that you can use and reuse on future projects.
Of course, this choice will be influenced by your level of experience with each library. But that said, don't be afraid of working with a new library if it's the best choice for a given project. Libraries tend to share a lot of syntax, so once you become familiar with one, it's a lot easier to adapt to another one. A number of popular JavaScript libraries are out there: jQuery, Closure, Mootools, Zepto (to name a few). My personal favorites are jQuery and Zepto, which I compare in this section.
jQuery
jQuery is arguably the most widely used JavaScript library on the web. It provides a variety of utilities and other API functions that you can use to build the components you need for your application.
Advantages of jQuery
The main advantage of jQuery is its scope. It's very robust, offering more APIs than any other library I've used. It's also really easy to use, for a couple reasons:
• The semantics of the API are very forgiving for beginners, allowing a variety of missteps without throwing JavaScript errors
• There are many convenience functions. A convenience function is sort of a gateway function—for instance, jQuery.post(), which is a proxy to jQuery.ajax().
• Most jQuery methods are chainable, which means that each method returns itself so that you can link any number of methods on one DOM reference. For example:
jQuery('.my-element').addClass('my-class').fadeIn().click(myClickHandler)
All of these factors produce a low barrier of entry for jQuery and contribute to its overwhelming popularity. However, the scale and usability of jQuery also contribute to its main disadvantage: filesize. All the different functionality in jQuery comes at a price, which is a larger codebase. This filesize is bloated further by the convenience functions.
Fortunately, a lot of the filesize issues have been resolved in jQuery 2.0. jQuery 2.0 provides a modular build process similar to jQuery UI, which allows you to build a project-specific instance of the library which is customized for the APIs you are using. Additionally, jQuery 2.0 drops support for IE 6, 7, and 8, which contributes to a large chunk of the codebase in version 1.9. But don't worry, jQuery 2.0's API is compatible with 1.9, which means that conditional comments can be used to load jQuery 1.9 for any of the browsers that 2.0 doesn't support:
<!--[if lt IE 9]>
<script src="jquery-1.9.x.js"></script>
<![endif]-->
<!--[if gte IE 9]><!-->
<script src="jquery-2.x.x.js"></script>
<!--<![endif]-->
jQuery Community
The popularity of jQuery is also a pronounced advantage. The substantial jQuery community improves the codebase in a variety of ways:
• Several core contributors are constantly writing and rewriting different APIs—improving performance, adding to the range of functionality, and squashing bugs and cross-browser issues.
• An immense number of developers are using the library. These developers push testing to the limits, testing the library in a vast number of use cases and environments, uncovering (and hopefully reporting) any bugs that made their way into a stable build.
• Whenever you encounter a problem or something you don't understand in jQuery, you can also lean on the community. The documentation on api.jquery.com is very complete and should be your first go-to resource. Beyond that, a ton of tutorials throughout the web describe how to tackle common jQuery problems and build larger components you may need in your app. Finally, if you can't find a way to solve a problem, simply ask on stackoverflow.com, and other jQuery developers will surely come to your rescue.
Including jQuery from a Universal CDN
You already found out how jQuery's popularity benefits the codebase and documentation. But did you know that it can also improve the way it's included on your site? With so many sites using jQuery, it doesn't make much sense for each of them to include it individually. Why should users have to download the same jQuery core on every site using the popular library that they visit? Fortunately, Google hosts jQuery on a Content Delivery Network (CDN), which you can leverage to improve download times for your users. CDNs are highly optimized servers designed to serve static files like JavaScript quickly. But being a CDN isn't what's important: it's the fact that this code is universal.
Although most sites still serve their own jQuery, enough sites are using Google's CDN to make it worthwhile. If your users have visited just one of these sites recently, the script is cached in their browser, meaning they won't have to download jQuery at all, even on the first visit to your site. The performance gains from this approach are substantial, and you can be proud of yourself for being part of the network of sites that leverage this CDN—the more sites that do so, the more beneficial this approach will be.
It's important to bear in mind that using the CDN improves only download time. Instantiation time is still an issue, which is not negligible.
Using Google's CDN is a piece of cake; simply point the script source to Google's server:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1/
jquery.min.js"></script>
This script requests the latest stable build of jQuery and includes it on your site. However, requesting the latest version of jQuery isn't recommended. APIs in jQuery become deprecated, and eventually unsupported, which is especially true in the transition from version 1.9 to 2.0. Thus it is a much better practice to specify the version of jQuery you want to use in your call to the CDN:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/
jquery.min.js"></script>
This script pulls jQuery version 1.9.1, since it's specified in the path.
Omitting the http protocol ensures that your browser uses whatever protocol your page is currently using. This stops your browser from complaining about serving assets with mismatched protocols. It just won't work if you're trying to open HTML files locally using the file:/// protocol.
Zepto
Zepto is a lightweight alternative to jQuery that was initially developed as a mobile library. But with its jQuery-like API and small filesize, it's a great choice for any project.
The majority of this book uses jQuery, but it's worth noting Zepto as a lighter weight alternative.
Advantages of Zepto
The main advantage of Zepto is filesize; weighing in at just over 8K, it's one of the smallest fully featured libraries out there. Despite its small size, Zepto is able to provide a substantial toolkit you can use for app development. Most of the common APIs and methods available in jQuery are also supported by Zepto, and those that aren't are usually easy to work around with a bit of custom JavaScript. To learn more about what is offered by Zepto, visit its documentation website at www.zeptojs.com.
Furthermore, since Zepto has a largely jQuery compatible API, it's incredibly easy to use, especially if you're already familiar with jQuery. You can reuse many of the methods from jQuery in exactly the same way, and conveniently chain together methods for cleaner code. This means that you can pretty much start using Zepto today, without even opening up its docs.
Finally, if you're building your app for mobile, Zepto also includes a few basic touch events you can leverage for better touch screen interaction:
• Tap events: tap, singleTap, doubleTap, longTap
• Swipe events: swipe, swipeLeft, swipeRight, swipeUp, swipeDown
If you're building a mobile app, there are some additional libraries you can use. You find more about these and other mobile techniques in Chapter 10.
No IE Support
But before you get too excited about Zepto, it's important to remember that it does not support Internet Explorer. This problem wasn't a cross-browser mistake by the library developer, Thomas Fuchs. Rather, it was a conscious decision to reduce filesize, much like the jQuery team's decision to drop old IEs from version 2.0.
Historically, to the pain of countless developers, IE has suffered from a slew of compatibility issues. It just doesn't adhere to standards with each major version having its own subtle quirks. Newer versions of IE have made notable efforts to close these compatibility gaps, but the fact remains that IE handles a number of JavaScript and DOM issues in a decidedly nonstandard way and is a distance behind other major browsers when it comes to HTML5 standards and features.
Most JavaScript libraries like jQuery handle these cross-browser issues with extra code so that you never have to see the problem. However, this extra code leads to a substantial amount of bloat. Zepto decided to trim that fat. That's great for mobile apps, which typically don't have to worry about IE. But it can be a deal-breaker when it comes to desktop apps.
Since Zepto uses jQuery syntax, its documentation recommends dropping in jQuery as a fallback for IE. That way your app still works in IE, while other browsers get the filesize advantages of Zepto. However, the two APIs aren't completely compatible, so use this approach with caution and test thoroughly. If you still want to go through with it, you can read up on the technique here: http://zeptojs.com/#download.
Vanilla DOM
Of course, you don't have to use a JavaScript library at all. Libraries can add unnecessary bloat to your app, even smaller ones like Zepto.
Pros and Cons of Vanilla DOM
The main advantage to writing all your own JavaScript is that you only include and write the things you need, and the main disadvantage is added development time. By definition, JavaScript libraries include a wide variety of functionality that is typically used in applications, but it's extremely unlikely that any individual app uses all of it. That extra, unused JavaScript falls under the category of unnecessary bloat. However, you have to weigh the filesize gains against the added development time, and if you've never written a JavaScript application from scratch, you may be underestimating the added time involved.
I'm sure you realize that you'll have to write a variety of scripts to handle all the functionality your app needs. But you may not be thinking about all the cross-browser development you'll have to do for each of these functions.
Cross-browser CSS issues are a walk in the park compared to cross-browser JS. Bizarre holdovers from the early days of browser wars keep rearing their ugly heads, forcing you to build totally different implementations for different browsers, each of which handle things slightly differently.
One familiar example is the cross-browser event handler—for instance, an onclick event. To bind a mouse event, all modern browsers support addEventListener:
var elem = document.getElementByID('my-element'),
elem.addEventListener('click', function(e) {
// whatever you want to do on click
}, false);
This will bind a click event to any element with the ID my-element in Chrome, Firefox, Safari, Opera, and IE9+.However, older versions of IE are notoriously poor at supporting standards. To accommodate these browsers, you'll need to use attachEvent:
var elem = document.getElementByID('my-element'),
elem.attachEvent('onclick', function(e) {
// whatever you want to do on click
});
Notice here how the API for the event handler is slightly different. Not only do you have to use attachEvent, but you also have to change the event type to onclick instead of click. Of course, you'll want to use both of these to make sure your script works for as many users as possible (older IE versions still have a depressingly large market share). To support both, you'll need to do a little feature detection:
var elem = document.getElementByID('my-element'),
if ( document.addEventListener ) {
elem.addEventListener('click', function(e) {
// whatever you want to do on click
}, false);
}
else if ( document.attachEvent ) {
elem.attachEvent('onclick', function(e) {
// whatever you want to do on click
});
}
This basic script is just the beginning. You'll probably want to write a universal handler to take care of all types of events, like this script from NetTuts+ (http://net.tutsplus.com/tutorials/javascript-ajax/javascript-from-null-cross-browser-event-binding):
var addEvent = (function( window, document ) {
if ( document.addEventListener ) {
return function( elem, type, cb ) {
if ( (elem && !elem.length) || elem === window ) {
elem.addEventListener(type, cb, false );
}
else if ( elem && elem.length ) {
var len = elem.length;
for ( var i = 0; i < len; i++ ) {
addEvent( elem[i], type, cb );
}
}
};
}
else if ( document.attachEvent ) {
return function ( elem, type, cb ) {
if ( (elem && !elem.length) || elem === window ) {
elem.attachEvent( 'on' + type, function() { return cb.call(elem, window.event) } );
}
else if ( elem.length ) {
var len = elem.length;
for ( var i = 0; i < len; i++ ) {
addEvent( elem[i], type, cb );
}
}
};
}
})( this, document );
If you're getting scared, that's good. Vanilla DOM is not to be taken lightly, and it gets even more complicated. Event binding is relatively simple compared to other cross-browser implementations, such as Ajax. While I can't deny the benefits of writing vanilla DOM, I also can't pretend that it's easy.
It's worth noting that even if you write vanilla DOM, there's no guarantee that this will be smaller in filesize than a library. Popular JavaScript libraries like jQuery and Zepto have been carefully reviewed by their contributors for a variety of issues, including filesize. If you end up writing a whole lot of utility functions, you may find that they end up larger than a smaller library like Zepto (~8 K).
Adding Third-Party Utilities
That said, you still don't have to write everything yourself. Rather, you can bootstrap together a set of utility functions. One great resource for finding these functions is www.MicroJS.com.
You can pick and choose the scripts you need from MicroJS and build a lightweight library that fits your project perfectly.
The MicroJS website is curated by Thomas Fuchs, who created Zepto.
Using a Framework
Recently, it has become popular to go the extra mile and use a full-on framework for your front-end development. A framework is more than a JavaScript library, because it provides styling and a variety of more in-depth features, such as form controls and other common components. I tend to steer clear of frameworks, preferring to patch together a JavaScript library, a variety of plugins and custom CSS. That way I create a custom build that suits my project's specific needs and that's styled to match design direction. But frameworks can certainly speed up development, and I encourage you to give them a try and figure out which workflow works best for you.
You can make this decision like a sculptor. Would you rather sculpt in clay, lumping together components as you need them? Or would you rather sculpt in marble, taking a complete block and chipping away the pieces you don't want? Either way, you'll end up at a similar point. The question is how you want to get there.
Bootstrap
Bootstrap offers a set of functionality and themes you can use to create your entire app. Bootstrap was first developed at Twitter for its own site and then was later released to the public. Bootstrap provides everything from a responsive grid layout to form controls. It contains a hodge-podge of different components and JavaScript plugins you can leverage to build your site quickly. Bootstrap's plugins include commonly used components such as modal dialogs, dropdowns, tooltips, and image carousels. Everything in Bootstrap is styled using a common theme, with icons, and so on.
Bootstrap is great if you want to launch a site quickly and don't need to follow a specific design direction. Of course, you can style everything in Bootstrap yourself, but its main purpose is to provide its own brand of UI look and feel.
jQuery UI
Another option, jQuery UI, isn't exactly a framework. It's more of a set of utilities you can use to enhance form elements and other aspects of your site. But because it's essentially a group of jQuery plugins that provide styling and functionality to common UI elements, I'm including it in here with other frameworks.
However, it's up to you whether you use jQuery UI as a framework. You can use all of its controls, such as tabs, accordions, and other components to build out your entire site. Or you can use jQuery UI more like a group of plugins. You can cherry-pick the components you like—for instance, using it to add a date picker to forms you're otherwise building with your own custom code. Yes, you can find individual plugins to fit each of these specific needs, but the jQuery UI core is extremely well built, and you can easily create a custom build so you don't have too much bloat from unused components.
Personally, I use jQuery UI as a group of plugins, because I don't like to include too much styling in my JavaScript and prefer to handcode my CSS for fundamental components such as tabs and modal dialogs.
Mobile Frameworks
A number of good mobile frameworks are available, such as jQuery Mobile and Sencha Touch. You find more about these and mobile development in general in Chapter 10.
Miscellaneous Scripts
There are also a number of miscellaneous scripts and utilities you'll probably want to include in your app. Two such scripts that I include in almost every project are Modernizr and HTML5 Shiv.
Modernizr
Modernizr is a small script that can help you build modern applications, while still supporting older browsers. Basically, Modernizr is a set of feature detections you can use to determine which CSS3 and HTML5 features are available in the user's browser.
Modernizr's approach is to attach class names to the <html> element, describing which features are available in CSS. For instance, if background-size is available, it adds the class backgroundsize to the <html> element. You can then use CSS to target both cases:
/* no background-size */
html .my-element {
background-image: url(../path-to/non-sizable-image.png);
background-repeat: repeat;
}
/* supports background-size */
html.backgroundsize .my-element {
background-image: url(../path-to/sizable-image.png);
background-size: cover;
}
You can use this approach to target a variety of features, and use the class name or the Modernizr API to target HTML5 features you want to use with JavaScript. For more information about Modernizr and the types of detection it supports, visit www.modernizr.com.
Modernizr allows you to create a custom build that detects only the features that you care about. I encourage you to do so, because it will reduce the filesize and lessen the script's instantiation time.
HTML5 Shiv
HTML5 Shiv is a very simple script that allows older browsers to recognize HTML5 elements such as <header>, <footer>, <nav>, <section>, and <aside>. Without a script like HTML5 Shiv, you can still use these elements; however, any CSS styling you apply to them will be lost in non-supportive browsers.
Because I like to use these semantic tags, I include this script on every site I build. To use it, first download the script from http://code.google.com/p/html5shiv. Next, include it in your site with an IE conditional, somewhere in the <head>:
<!--[if lt IE 9]>
<script src="dist/html5shiv.js"></script>
<![endif]-->
It's important to use a conditional so that you limit the browser requests for assets that are not needed. Since IE 8 and lower are the only non-supportive browsers with any significant market share, you can safely use a conditional here. Also make sure you don't include this script in the <body>. It has to exist in the <head>, ideally after any stylesheet declarations (for better performance).
Many other scripts and frameworks include HTML5 Shiv, so make sure you aren't including it twice.
HTML5 Boilerplate
HTML5 Boilerplate isn't a library, and it isn't a framework. It's a template you can customize for your individual needs. Boilerplate is a base-state you can use as a foundation on which to build your apps. Noninvasive and lightweight, it's an ideal start to any HTML5 project.
HTML5 Boilerplate combines a lot of the things you've read about in this chapter; for instance, it includes jQuery via the Google CDN (with a local backup) as well as Modernizr and HTML5 Shiv. It also includes Normalize.css, a modern alternative to CSS resets, and a number of a base styles and placeholder icons. But the idea is not to use it like a framework. This base state is intended to be fully customized, and the styles are, for the most part, placeholders that are easy to switch out. Finally, HTML5 Boilerplate includes some server configurations to improve performance in Apache, Node, and other builds.
HTML5 Boilerplate is the best of both worlds. It has all the advantages of a framework in that it provides a high-water baseline you can use to jumpstart your app. But it doesn't go too far; it encourages you to replace its (very limited) styling and to bootstrap in the additional components you need.
Finding jQuery Plugins
After you have your core functionality covered by a library, framework, or boilerplate, you will most likely still need other functionality in your app. You could build each of these components yourself, but if you want a faster development process, it's better to try to find plugins. That way, you can cover most of the remaining ground for your app, all without coding a single line yourself.
This section focuses on jQuery plugins, since they are very popular. But most of the recommendations apply for any JavaScript plugins you may want to use.
Where (and Where Not) to Look
The best place to look for jQuery plugins is the official plugin registry at http://plugins.jquery.com. On this site, you can search, browse, and find plugins that are rated by members of the jQuery community. But jQuery's repository of plugins is hardly an exhaustive list, and you'll ultimately have to rely on a search engine to find what you're looking for. In general, the higher a plugin's quality, the higher its search ranking (although this is by no means foolproof).
When you formulate your search, be as specific as possible. I'd recommend steering clear of the countless blog posts in the format of “25,000+ jQuery plugins.” These are generally spammy lists designed to drum up traffic for sites, and the plugins they contain are rarely (if ever) well researched.
It may not be what you want to hear, but finding good quality jQuery plugins can be a struggle. That's because a significant number of them are fairly lousy.
What to Look for—A Ten-Point Inspection
The low barrier of entry into jQuery has led to its popularity both in site builds and in third-party plugins. This popularity is both a blessing and a curse. On the one hand, you can find a free plugin for just about any functionality you can think of. On the other hand, a good percentage of these plugins are poorly engineered or lacking in flexibility for your project's needs.
That said, you can analyze a number of factors in a plugin you're considering. Here is a checklist to consider when assessing a plugin's quality:
• Would it be better to write it yourself? If the functionality is very simple, it's probably best to just buckle down and write it yourself. After all, if you can write it in less than the time it takes you to read the rest of this list, why would you bother? Additionally, if the plugin is similar to something else you're using, it probably doesn't make sense to add another plugin and bloat your codebase. Rather, you should spend a little time extending the other plugin to accommodate both needs.
• Is it well documented? The plugin's documentation is almost as important as the plugin itself. The docs will be the first place you go when learning how to use the plugin, or when you run into a problem. Furthermore, spending the time to write good documentation is a sign that the developer cares about releasing a quality plugin, rather than just spinning off something they wrote for another project in an effort to get traffic on their blog.
• Does it have a good support history? Be sure to check how recently the plugin was updated. If it is consistently maintained, that's a good sign that the developer cares about a quality release, and also that he or she will help you if any problem you can't solve arises. If the plugin is released as a blog post, check and see the last comment the author responded to. Also check the last time the developer fixed a bug or added a feature. Of course, the plugin may be so completely developed that there's nothing more to add, but good support is a very good sign.
• Does it use a standard argument signature pattern? When looking at the documentation, you'll see how the plugin accepts arguments. And after using a number of plugins, you'll see some common trends to how plugin options are passed.
There's no one right way to handle options, but any plugin that has a bizarre argument signature pattern is a big red flag. It's a sign that the developer is not overly familiar with plugin development or that the developer hasn't bothered to think about the plugin's architecture.
• Does it have simple markup requirements? If the plugin relies on any markup in the source, the format of this markup is important.
This issue is two-fold. First, strange or rigid markup requirements make plugins harder to use, because you will have to adjust your markup to suit the plugin's specific needs. Second, markup that is semantically poor or requires seemingly unnecessary elements indicates a lack of skill in the plugin developer.
• Does it use quality CSS? If the plugin uses CSS, that CSS matters as well. Good CSS is an indication that the plugin developer is good with front-end work. Poor or excessive CSS is not necessarily a deal breaker, but it is certainly a red flag.
• Is there a list of supported browsers? If the developer has tested the plugin across different browsers, the developer will probably say which browsers those are. It's a really good sign if the developer lists exactly which browsers were tested, along with the version numbers. But at the very least, the developer should mention that it “works in all modern browsers” or something to indicate concern about cross-browser development.
• Does it have a minified version? This point is a bit nitpicky, but you should check whether the plugin's web page provides a minified version. A minified version is a sign that the developer cares about performance and filesize. It's not absolutely essential, because the developer may be assuming you will include it in your site JS and minify that. But it's certainly a good sign if it includes a minified version, or the developer talks about filesize, gzipping, and so on.
• Do other people use it? One of the last things to check is how many other people use it. If it's on a site with user ratings, a high rating is certainly a good sign. Otherwise, do a Google search and see how many people are talking about the plugin, and how many “8000 jQuery Plugins” lists it has been included on. Of course, if the plugin is really new, you'll have to cut it some slack here.
• Does it work? Finally, the best way to check a plugin is to plug it into your code and see for yourself. This is the most time-consuming step, so do this only when you're confident that it deals sufficiently with the other issues discussed in this list. Once it's in your code, make sure that it accomplishes what you want and has decent performance. Finally, be sure to test the plugin in all the browsers you support before integrating it too deeply into your code. Alternatively, if the plugin author provides unit tests, you can simply run those in the environments you want to support. Unit tests are also an excellent indicator of quality, since it means the developer has taken time to test the plugin thoroughly.
Summary
In this chapter, you found out how to use a foundation of other scripts to jumpstart your app.
You read about the JavaScript libraries jQuery and Zepto, and the advantages of avoiding libraries altogether to write your own vanilla JavaScript. Then you learned about larger frameworks such as Bootstrap and jQuery UI, and the pros and cons of using a framework.
Next, you read about smaller utility scripts: Modernizr and HTML5 Shiv. You then were exposed to HTML5 Boilerplate, which combines libraries, utility scripts, and base styling to create a template. This template is less heavy-handed than some frameworks but still provides many of the same advantages.
Finally, you discovered jQuery plugins: where to find them and how to determine whether a given plugin is worth using. Now, you're ready to roll up your sleeves, and start coding in the next chapter.
Additional Resources
For a list of JavaScript Libraries go to http://en.wikipedia.org/wiki/List_of_JavaScript_libraries.
Library Documentation
jQuery: http://api.jquery.com/
Zepto: http://zeptojs.com/
MooTools: http://mootools.net/docs/core
Library Feature Comparison: http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks
Other Library Resources
jQuery Fundamentals: http://jqfundamentals.com/http://jqfundamentals.com/
jQuery Tutorials: http://docs.jquery.com/Tutorials
The Essentials of Zepto.js: http://net.tutsplus.com/tutorials/javascript-ajax/the-essentials-of-zepto-js/
Framework Documentation
Bootstrap: http://twitter.github.com/bootstrap/
jQueryUI: http://api.jqueryui.com/
jQuery Mobile: http://view.jquerymobile.com/
Sencha Touch: http://docs.sencha.com/touch/http://docs.sencha.com/touch/
Miscellaneous Scripts
Modernizr: http://modernizr.com/docs/
html5shiv: https://code.google.com/p/html5shiv/
HTML5 Boilerplate: http://html5boilerplate.com/
jQuery Plugins
jQuery Plugins Registry: http://plugins.jquery.com/
Signs of a Poorly Written jQuery Plugin: http://remysharp.com/2010/06/03/signs-of-a-poorly-written-jquery-plugin
Building Your Own jQuery Plugins: http://docs.jquery.com/
Essential jQuery Plugin Patterns: http://coding.smashingmagazine.com/2011/10/11/essential-jquery-plugin-patterns/
Books
Learning jQuery, Third Edition by Jonathon Cather and Karl Swedberg; Packt Publishing (September 2011): ISBN 978-1849516549 http://amzn.to/XHo8Ebhttp://amzn.to/XHo8Eb
jQuery Cookbook by Cody Lindley; O'Reilly Media (November 2009): ISBN 978-0-596-15977-1 http://shop.oreilly.com/product/9780596159788.do
Bootstrap by Jake Spearlock; O'Reilly Media (April 2013): ISBN 978-1-4493-4391-0 http://shop.oreilly.com/product/0636920027867.do
jQuery UI by Eric Sarrion O'Reilly Media (March 2012): ISBN 978-1-4493-1698-3 http://shop.oreilly.com/product/0636920023159.do