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.
Structure and setup
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.