Picking the right JavaScript framework

Key considerations and overview of popular options

Henri Heiskanen Senior Software Engineer @ Gofore

Agenda

Some example cases...

• Kela.fi
• Fonecta.fi
• Opintopolku.fi

</pitch>

"How should I architect my web application? What things factor into that decision?"

Key questions

Thick server architecture

All necessary UI state is stored in server memory. Most of the logic and rendering is performed on the server, while the client's role is simply to display static HTML coming down the wire.

• Traditional, old-school way of doing things
• Still a solid choice for websites with mostly static content
• Can also work for simple CRUD applications

Thick server architecture: pros & cons

• + SEO
• + Bookmarkability
• + Accessibility
• - Tight coupling between data and presentation
• - Large memory footprint
• - Poor scalability
• - Both data and markup are transferred down the wire
• Slow page loads
• Poor user experience (UX)

Thin server architecture

All UI state is retained on the client. The bulk of the rendering is done on the client, converting the server into a data endpoint. While a great deal of business logic can be moved to the client, some of it may have to be duplicated between client and server (think validation, for instance).

• A typical implementation is a single-page application (SPA)
• Usually built on top of some JavaScript MV* framework
• Good for interactive web apps with dynamic functionality
• Easy to create new clients that consume the same server API

Thin server architecture: pros

• + Loose coupling between data and presentation
• Easy to create new clients
• Promotes API-driven development
• Allows for concurrent development of the front-end and the back-end
• + Easy on server-side hardware
• + Scalability
• + Can also work offline
• + Only necessary data is transferred down the wire
• Faster page loads (minus the initial bootstrapping page load)
• Better UX

Thin server architecture: cons

• - SEO
• - Bookmarkability
• - Accessibility

Bonus: A brief aside on REST

REST (REpresentational State Transfer) is an architectural style for designing networked applications. Although protocol-agnostic, it is virtually always implemented on top of HTTP.

• Provides a mapping for CRUD operations
• POST -> Create
• GET -> Read
• PUT/PATCH -> Update
• DELETE -> Delete
• Lightweight compared to alternatives (SOAP & co.)
• When building single-page applications, RESTful server API design is strongly encouraged
• In the real world, not everything fits the CRUD mold (e.g. multi-resource search), but you should still follow RESTful API design principles as much as you can.

Hybrid approach

Combines the benefits of single-page applications and traditional server-powered applications. The initial (expensive) page render is done on the server, followed by a takeover by the client. Ideally, the entire view layer should be renderable by both the client and the server, but a simpler template sharing approach also qualifies.

• Also known as isomorphic JavaScript applications or client-server MVC
• Improved SEO and stetefulness
• Fast page loads across the board
• Can be implemented progressively, from template sharing to a view layer and business logic compatible with both client and server
• The way of the future

"Ok, I want a modern JavaScript application. Now show me the magic framework that gets me everything!"

Framework choice paralysis

There are numerous JavaScript frameworks, MV* or otherwise, vying for your attention. Picking the right one comes down to your application domain, requirements, and personal preference.

• The rise of single-page applications has resulted in a proliferation of JavaScript frameworks in a relatively short space of time
• A common problem among developers is yet-another-framework syndrome (YAFS), leading to difficulty evaluating all the relevant alternatives and settling on the right one
• There is no one-size-fits-all way to do things
• Sorry :(
• Frameworks don't solve all your problems!
• Sorry :(
• However, some frameworks have gained significant traction in the web-development community...

"I want to keep my front-end code loosely coupled with my server implementation by means of an API. What are my best options?"

Backbone.js

The first major, widely-adopted MV* JavaScript framework. Minimal by design, it only provides the barebones of an MV (Model-View) Javascript application, leaving the rest up to you.

• Fast to learn and easy to get into for JavaScript developers
• Very small -- only 7kb minified and gzipped
• Huge community, plenty of plugins and extensions, and lots of answered questions on Stack Overflow
• Used by many big names -- USA Today, Foursquare, Hulu, Pandora and many others
• Of all the big frameworks, Backbone has the least magic and everything can be easily customized
• The lack of magic means you need to write it yourself or use plugins/extensions
• Building large applications leads to boilerplate code and quickly gets repetitive

AngularJS

Immensely popular MV* framework by Google. Unlike Backbone, Angular is fairly opinionated and makes many choices for you. This usually leads to increased developer productivity.

• Provides declarative two-way data binding out of the box
• Extends HTML vocabulary with a DSL known as directives, patterned after the emerging Web Components standard
• Built from the ground up with testability in mind
• Solid performance in most cases, but you may have to do some optimizations when rendering large data sets
• Lots of new, proprietary concepts to learn, which can steepen the learning curve for some

Ember.js

Huge MVC framework for building "ambitious" web applications. Very opinionated and relies heavily on conventions for its magic to work

• Offers some of the killer features also found in Angular, such as two-way data binding
• Sophisticated persistence-layer adapter known as Ember Data (still in beta)
• Massive in terms of both size (250kb minified) and API surface area
• Controls your whole front-end application, not suitable for small "islands of richness"

"I don't want to bother with a RESTful API and separate server framework. I want an application that runs everywhere and is 100% JavaScript."

Meteor

Hybrid JavaScript framework to run on both client and server. Besides being fully reactive, Meteor is also real-time, making it a good choice for collaborative real-time apps.

• Allows for very rapid development and high productivity
• A replicated copy of the database running on the client makes development easier
• Still pre-1.0, and some things are still in flux
• As of now, the only supported database in MongoDB (support for others is on the roadmap, though)
• Currently doesn't support server-side rendering, but according to the docs, it will in the future
• Proprietary, undocumented package format that will change before Meteor hits 1.0
• Limited deployment options, no out-of-the-box way to deploy Meteor apps as standard Node.js apps

"Okay, lots of nice options, but how do I pick the right one?"

How to make the right choice?

• A good starting point for comparing different MV* frameworks is TodoMVC -- a project showcasing the implementations of a simple todo app with a variety of different frameworks
• Carefully review the features of your candidate frameworks and think how well they fit with your requirements
• Don't be overly swayed by the buzz factor of some new hot framework

How to make the right choice?

• Compare your candidates on:
• Maturity -- is the framework still pre-1.0, and are there likely to be breaking changes? Who's using the framework in production?
• Documentation -- how much of it is there and is it any good?
• Community -- what's available in the way of extensions, plugins, tutorials, screencasts etc.?
• Size -- after factoring in dependencies, minification and gzipping, are you dealing with a colossal or slim framework?
• Flexibility -- is the framework opinionated or flexible? Do you prefer conventions and opinions over configurability?
• Productivity -- do you need to write loads of boilerplate code or do things just work automagically?
• Esthetics -- do you like how the code looks? Do you agree with the design decisions of the framework?

How to make the right choice? (cont.)

• Are you sure you actually need a framework?
• If you're targeting mobile users, large script files may come with a heavy performance penalty

Hard data from Google Trends...

Some practical tips

• Use Backbone if you want to fully control your architecture, update your views imperatively and choose your own templating engine
• As complexity grows, you might want to consider extensions like Marionette.js (a good fit for complex view hierarchies) or Thorax (if you're a fan of putting your rendering logic in your templates)
• Use Angular if you want high productivity, declarative views and built-in testability
• Use Ember if you're building a large application and prefer opinionated frameworks
• Use Meteor if you're building a real-time application and would like to try something different (and want maximum hipster points :))

Server-side integration

• If you want to go for an all-JS approach, your best bet is node.js coupled with its de-facto-standard web framework Express
• The MEAN (MongoDB - Express - AngularJS - node.js) stack is probably the most common one for building modern SPA's
• Isomorphic frameworks (such as Meteor) also run on the server and make some (or all) of the choices for you
• However, as long as you have a RESTful API between your client and server, the way you decide to architect your back-end should not make much of a difference to your front-end implementation
• Many prominent server-side web frameworks have solid support for REST (Play, JAX-RS, Spring MVC, Django, Grails, Ruby on Rails etc.)