jQuery is no doubt the most popular Javascript library available right now, and for good reason. It is easy-to-learn and make you much more productive. There are a ton of resources to help you learn it; I’ll just say that you should be using it.
This awesome library gets its own section because how useful it is while IE8 is still in the picture. Modernizr will automatically add some CSS classes to the root html element. For example if you want to test Web Sockets support, it will add a websockets class to the html element if the browser supports that feature, otherwise it will add the no-websockets class. It will do the same with JavaScript by adding a global variable Modernizr.websocket with a boolean value.
This article is a great overview, but a bit dated already. http://
This one is newer: http://www.adobe.com/devnet/html5/articles/up-and-running-with-modernizr.html
<!DOCTYPE html> <!-- The "no-js" class is here as a fallback. If Modernizr is not running, you'll know something is wrong and you will be able to act accordingly. In contrast, if everything goes well, Modernizr will remove that special class. --> <html class="no-js"> <head> <meta charset="utf-8"> <title>My Awesome video</title> <script src="modernizr.js"></script> </head> <body> ... </body> </html>
Since the HTML element now has classes applied to it, your selectors need to be prefixed with what you are testing for. For example, if you want to make your HTML5 video visible if the browser can play HTML5 video, then you would do this.
.video #myVideo {
display: block;
}
.no-video #myVideo {
display: none;
}
if (Modernizr.video) {
//the current browser can play HTML5 video
}
This can be bundled into Modernizr. It allows you to dynamically load JavaScript files depending certain conditions. These conditions are typically whether or not an HTML5 feature is supported in your browser, but it can also be for any boolean condition as described by this article.
Typical usage looks like this:
Modernizr.load({
test: Modernizr.indexeddb,
nope: "indexeddb-polyfill.js"
});
Modernizr has a function that can process a Media Query selector: Modernizr.mq() This method inspects the string you pass it, and it’ll return a boolean.
if (Modernizr.mq('screen and (min-width: 769px)')) {
// Falls here when the screen is larger than portrait iPad
}
Probably more useful, however, is to test for native Media Query support. If it is not supported, then you can load in the css3-mediaqueries.js polyfill. To do this, you will need to check the css-mediaqueries option in the Non-core Detects section. The you can do:
Modernizr.load({
test: Modernizr.mediaqueries,
nope: "css3-mediaqueries.js"
});
Keep in mind, you don’t always need to do a Modernizr test if your “logic” is in the CSS.
.semiTransparentBkgd {
background-color:#F00; /* red */
background-color:rgba(255,0,0,.7); /* red with 70% opacity */
}
Because rgba() was used last, it will be used by browsers that understand it, and ignored by other browsers.
These are pre-written functions for making your life easier.
This is the other "big" library (besides jQuery). MooTools is a compact, modular, Object-Oriented JavaScript framework designed for the intermediate to advanced JavaScript developer.
Low-Dash is a low-level utility library delivering consistency, customization, performance, and extra features. It is a fork of Underscore. I definitely need to take a look at it sometime. Read this about Low-Dash.
oCanvas is a neat way to work with the Canvas element. Try this with drag and drop sometime.
Sugar is a Javascript library that extends native objects with helpful methods. It is designed to be intuitive, unobtrusive, and let you do more with less code.
CreateJS is a suite of Javascript libraries & tools for building rich, interactive experiences with HTML5. Other modules do Canvas, Tweening, Sound, and Preloading.
The following paragraph is from the article Dependency Management with RequireJS.
Let's get nostalgic for a moment. A few years back, using JavaScript on the server was just starting to get hot. Server-side libraries and JavaScript engines were being deployed but they didn't have a good, standard API for working with one another and defining dependencies. Getting one library to work with another required finagling and it was obvious that if JavaScript was going to scale it would need some common APIs. In January 2009, Kevin Dangoor wrote a blog post titled What Server Side JavaScript Needs outlining just that—what server-side JavaScript needed. As a means to fulfill these needs, he created a Google group named ServerJS where like-minded folk could collaborate. Soon enough, the group realized that many of its goals weren't necessarily limited to the server and renamed the group to CommonJS.
One of the standards that CommonJS worked toward was the module. A module is a self-contained piece of code (how's that for vague?) that defines that it is a module itself and, optionally, which other modules it depends on in order to function. Module B might call for module G and module M, and module G might call for modules D and W. By having a module standard, dependency management becomes easier. Rather than keeping some sort of implicit master list that must be kept in order, each module just defines its own dependencies. That mapping can be used to determine required resources and the order in which they must be loaded.
The module concept was great for server-side development as it addressed how to load modules based on dependency definitions, but the browser-side JavaScript developers got a bit jealous. Why should such a useful mechanism be confined to the server? Sure, browsers would need to load modules asynchronously rather than synchronously, but that didn't mean the concept of modules and dependency definitions couldn't apply. The Asynchronous Module Definition, or AMD, was born for this purpose. It takes the module and dependency definition API from the server side and applies it to the asynchronous paradigm of the browser.
So what does RequireJS have to do with this? Well, even though you can define your modules and their dependencies with AMD, you need something smart that can take this dependency map, load the modules, and execute the modules in order. That's the role RequireJS plays. Both RequireJS and AMD are open source, popular, and well-curated by James Burke.
A framework is a structure, or paradigm, for building your site. These are only needed for larger or complex sites. Many bake-in the idea of Model-View-Controller and have a good way for interacting with the server.
This library has a lot of momentum and many sites are built using it. I am doing some experimenting with it right now.
Ember is a JavaScript framework for creating ambitious web applications that eliminates boilerplate and provides a standard application architecture.
Handlebars is a separate and independent library, but it is used extensively by Ember. If all you are looking for is an easy way to place variable content in a web page, then this is a great way to go. It is easy to understand and quite flexible. For example, let's say you have a JSON structure like this:
myBooks = {titles:["JavaScript Cookbook", "HTML5", "Search Engine Optimization", "ActionScript 3.0"]};
You can place those titles in an unordered list using:
<script type="text/x-handlebars">
<ul>
{{#each titles}} <li>{{this}}</li> {{/each}}
</ul>
</script>
Considered, by some, to be better than Backbone.
Good for ActionScript programmers. The article, 5 Awesome AngularJS Features, makes a pretty compelling case the use of Angular.