Web application frameworks have been developing fast in the past few years, and as the technologies that they're built on top of get more advanced, each of these frameworks is able to provide newer features to help developers build more complex applications. This year, we've seen the release of a new class of application frameworks that takes advantage of JavaScript's ability to be both on the client and the server. What this allows these frameworks to do is provide both a new level of abstraction by sharing code between client and server, as well as embrace the benefits of both client-side rendering and server-side rendering.
For the end user, they get smooth, desktop-like responsiveness from client-side rendering, while still being able to maintain the SEO and accessbility benefits of server-side rendering. For developers, that means writing less boilerplate code, and being able to focus more on writing the application logic.
Today, there are three main frameworks that provide these features, all three of which were open-sourced this year:
Each of these frameworks are currently under heavy development, with an extremely talented group of developers backing each one. They each provide different features and different levels of abstraction, giving developers a variety of choices when choosing the best framework for developing their application. We'll start by taking a look at some of the features that are most important for developers, and seeing how they compare amongst the three:
Having a single language between client and server may be the main feature that sets these frameworks apart, but what the developers of each team have since focused on has changed as each framework has matured.
Derby and Meteor share a closer design philosophy to each other: that all future applications will be real-time and collaborative. Their approaches rely on using the newest technologies and techniques (WebSocket emulation, data binding) to provide this real-time functionality, while maintaining an easy-to-use API to make these techniques available to many developers. The difference between the two, though, can be seen in where their development priorities are:
Meteor, in the words of Geoff Schmidt, one of their developers, wants to be "a 'mass-market' app platform that could be used for 90% of the sites on the web, and for that 90%, make web development faster and within reach of more people". This philosophy is reflected in their well-abstracted and simple API, with many functions used similarly on both the client and the server. The Collections API, in particular, is used exactly the same way in both the client and server, making it simple for any developer to quickly switch from getting data on the server to getting data on the client.
Derby, in their words, focuses on "making sure [Derby] can support advanced features like conflict detection, offline clients, and extremely fast rendering". As applications become more collaborative, with many concurrent users, being able to maintain proper application state will become much more difficult. The Derby developers use advanced operational transformation techniques with their data synchronization engine, Racer, that makes sure data is propagated properly, even with clients that switch from online to offline at will.
Mojito's philosophy, on the other hand, focuses on making an application available to as many users as possible, regardless of what platform or environment they might be on. Mojito specializes in making applications extremely quick to develop, allowing developers to rapidly create applications that are available for many different devices, localize and internationalize for different languages, and progressively enhance for older clients and those who may have disabled JavaScript. For Mojito, the technology used in developing your application isn't as important as making sure that every end user is able to use it.
Mojito is fairly strict with its MVC separation, splitting up the individual components that make up an application into separate modules known as mojits. For developers coming from other server-side MVC frameworks, mojits have a similar functionality to Rails plugins and Django apps. Each mojit has its own models, views, and controller, with all code able to be specified as either client-specific, server-specific, or shared. Mojits generally represent an individual MVC element on a page, and it can be common to have multiple mojits per page, or have more complex mojits be composed of several child mojits. The code is integrated together in a way similar to using YUI modules, which Mojito is based upon.
Mojits are bound together to become a unified application through JSON-based configuration files that specify how routes should be handled, depending on the user's platform or environment. To simplify the creation of Mojito applications and mojits, the mojito command-line tool provides utilities to quickly generate scaffolding.
Derby also has a full MVC structure, though it doesn't have as strict of a component separation that Mojito does. The derby command-line tool generates a Derby project, which can contain one or more Derby apps, which are the stand-alone usable components of the project. Apps contain the controller logic (which can be used client-side or server-side) of a Derby project, which is then linked to a specific Derby server, which handles the server-side routing and data synchronization for the project. A Derby project has a very similar structure to an Express application, and uses familiar Node.js conventions to integrate different modules together. Markup templates and styles are separated from the controller code, and are generally written as partials that will be discussed in more detail later on.
Meteor provides a unique take on structuring an application, by trying to abstract out how client-side code normally accesses data. Meteor provides the exact same methods to access data, whether on the client or on the server, based on the MongoDB API. Instead of having a typical MVC separation, Meteor treats client-side code as if it were able to access the database directly. Clients "subscribe" to a number of collections in the database, with data being broadcasted out as it changes. Though Meteor does not provide MVC separation by default, it is possible to use a bundled version of Backbone alongside Meteor to provide that structure for more complex applications.
Nice, might want to consider https://github.com/socketstream/socketstream too, if you haven't already?