Five years ago, if you asked any client-side developer which library or framework to use the most likely answer would have been jQuery. Since then, client-side development has become far more complex. A friendly wrapper for DOM programming and a browser compatibility layer isn't enough to help us write modern applications.
Starting a project today involves selecting a package manager, module system, build system, templating language, data binding library, a sync layer, a widget library, and a test framework. And it doesn't end there: many of us also regularly use a dynamic CSS language, and mobile SDKs.
I wouldn't say this is a negative trend, but with large companies backing or offering solutions to these problems, making an informed decision on each of these technologies is difficult. And soon the major players will offer a complete set of tools and libraries to satisfy each requirement: we'll be back to something that looks like the original monolithic frameworks.
Until recently, starting a client-side web application might have looked like this:
There are other popular choices for each of these bullets, of course: Zurb Foundation is a popular front-end framework, and I've used Mocha instead of QUnit since Mocha appeared. I also like Knockout for data binding, because the two-way declarative bindings are easy to get the hang of.
These libraries are not interchangeable once a project has been started -- Bootstrap uses different CSS classes to jQuery UI, for example. The major difficulty is keeping libraries up to date, particularly if they have a lot of dependencies.
And that's when you need a package manager. Using a package manager can make the choices even more fine grained, because managing each library and its dependencies is easier. Switching to something like Component is one option, which can lead to a totally new stack:
Bootstrap and Zurb Foundation can be provided as components, there are projects on GitHub to do this. I've tried to design projects 100% around components without these larger libraries, and it was a huge amount of work. It may get easier with time, or once the right balance of functionality is found. I've noticed there are some "meta packages" that exist to group commonly used dependencies together.
You'll notice I haven't mentioned AngularJS yet. The reason for that is AngularJS is now compatible with Closure Library, which makes it possible to use an almost 100% Google-powered development stack:
Package manager: None (to my knowledge)
Module system: Closure Library modules
Build system: ClosureBuilder
Data binding: AngularJS
Sync: AngularJS services
Widgets: Closure Library
Test framework: Closure Library testing
While Closure Library is more like the "last generation" monolithic frameworks, each module can be loaded separately, so you don't need to use the whole thing. You could make a project with Closure Library, ClosureBuilder, Backbone.js, and Boostrap if you wanted. You could also go the other way: deploy a Go/Python/Java app to App Engine that's built on Closure Library and AngularJS. Google effectively provides the entire stack, including server-side development, data storage, user authentication, billing, and client-side development.
Recently we've also seen a huge amount of open source projects coming out of Twitter. A pure Twitter stack looks like this:
Package manager: Bower
Module system: Flight/AMD
Data binding: Flight
Using components through Flight could satisfy the other dependencies as well. It wouldn't be difficult to use Flight as a test runner with a suitable assertion library, although the authors use Jasmine and PhantomJS at the moment.
Let's not forget, however, the incredible features provided by Dojo. Compare Google and Twitter's client-side stacks to this:
Package manager: Dojo Packages, CPM
Module system: AMD
Build system: dojoBuild
Templates: Dijit templates
Data binding: dojo.store.Observable
Sync: Dojo Object Store
Test framework: D.O.H.
Dojo has the entire client-side stack covered, and also includes many more features that I haven't mentioned here. YUI is comparable:
On the surface, it seems like Twitter's developers aim to create something more like Component, where each piece of the client-side puzzle can be picked à la carte. Closure Library is more like the older, monolithic model used by YUI, where a custom module system is used, and modules are harder to reuse without the base framework.
The question is, can these larger companies support modern, "componentised" client-side development, or is it easier to offer a consolidated monolithic framework? Projects like AngularJS and Flight suggest to me that developers within Twitter and Google want to promote that approach, while how that fits into the wider organisation remains to be seen. Will we see AngularJS alongside Closure Library in the Python, Java, and Go App Engine documentation, or will it remain a useful library that exists outside of Google's core developer offering?
An interesting third option is Yeoman. This is another project from Google that provides a selection of smaller libraries to kick-start development:
Package manager: yeoman
Module system: RequireJS, AMD
Build system: Grunt
Yeoman generates application templates by helping you select various options, and then gives you a build system so you can easily generate something deployable. It doesn't enforce decisions like template language or CoffeeScript, but provides a harness for installing packages, and building and testing your application.
Client-side development is changing. It's no-longer enough to learn a small amount of jQuery -- an entire client-side stack is becoming the norm. The libraries that plugged the gaps in jQuery and its clones now have serious competition from tech giants.
What's the most sensible thing to do when there's an established project called Component that aims to make client-side development more modular through reusable components? Invent something else that yet again overloads this increasingly overused term! If you weren't already confused about components, then get ready to unlearn everything you've learned.
I was expecting this, however. After seeing Bower, I felt like it really needed another project to further abstract client-side development, and that appears to have been satisfied by the release of Flight.
Flight (GitHub: twitter / flight, License: MIT, bower: flight) from Twitter is a new framework that maps "behaviour" to DOM nodes. To do this it brings together a few things you're probably already familiar with: multiple inheritance (mixins), the AMD pattern, and the observer pattern. The supplied Flight Mail example app is built using RequireJS, so you can see why AMD is relevant here.
Flight apps look a bit like Backbone/RequireJS apps. They both use AMD and rely on events for communication. However, Flight is deceptively different. Which isn't necessarily a bad thing, because we've argued about MVC/MVVC/MV* for a long time at this point.
The authors define a component in Flight as a constructor with properties mixed in. Each component has event handling, and is eventually attached to a DOM node. They can't refer to each other directly -- communication is purely through events.
That last point is potentially important, because it demonstrates the authors have a good sense of one of the major issues with client-side development: writing reusable, decoupled code. Given that Angus Croll and Dan Webb are contributors to this project, it's not surprising that there's a focus on composition.
However, the project has some great ideas and has serious pedigree behind it. It's different enough to Backbone, AngularJS, and Knockout, so I've welcomed it to my rapidly growing client-side development toy box.
ComponentJS (GitHub: rse / componentjs, License: MPL) by Ralf S. Engelschall is a totally unrelated project that just happens to involve the term "component". This library is aimed at creating dialog-based hierarchical interfaces for single page apps. It has an OO library, a graphical debugger, UI toolkit, state transitions, and communication using events.
According to the author, this project has been developed since 2009 (although the domain name was created a year ago), so the naming clash is purely coincidental from what I can tell. It has extremely detailed API documentation, and a demo with browsable source code.
Welcome to the jQuery Roundup 30. You can send your plugins and articles
in for review through our contact form or @dailyjs.
I go through a lot of jQuery plugins every week. Most plugins are thrown
onto a dodgy WordPress blog as a zip file (and sometimes even rar). If
you're distributing plugins, please consider the following:
Using source control on a public site like
GitHub to distribute your plugin and allow
people to track updates
Giving the plugin a license (most people use GPL or MIT)
Hosting a demo (GitHub Pages can also be
used to host demo pages for free)
And then I won't get grumpy and think your plugin looks unprofessional.
license) by Thomas Billenstein is a nice little Twitter library for
displaying real-time updates. It can read a user's tweets, lists, or a
There's a demo
page that links to
several different examples.
The project uses lots of other interesting things, like Less.js,
Require.js, and Socket.IO.
daemon.node is a Node module
for creating daemons. The author also wrote a blog post, Writing
which is informative if you haven't done that sort of thing before. The
process is similar to most languages, and in this instance the module is
implemented in C++.
node-video by Peteris Krumins
is a module for encoding Theora/Ogg videos from RGB buffers. The author
said the following on his blog, catonmat.net:
I wrote this module for my StackVM startup so that anyone could record
virtual machine video screencasts. See StackVM demo video #1 at
around 1min 23secs, where I demo this module in action.
by the same author with the same licensing, can animated colour
properties. It can animate a lot of different properties, and works more
reliably than Color Animations by John Resig: