Sunday, October 14, 2012

Looking at new front-end tech stack: bootstrap + backbone

Recently, I have been developing using a new front-end technology stack that includes bootstrap from Twitter and backbone.js (a subcomponent of

Here is a partial list

Bootstrap has had a lot of adoption in the last few months. It offers a great out of the box set of styles and behaviors that make sense, allowing the quick development of 'responsive web design' web designs that know the limits of the device at hand and respond by tailoring the layout appropriately. It requires jquery (of course) and builds on by providing layout and default styles and a few basic components with great default behavior. Its CSS is managed nicely using less.js to provide your CSS with variables, mixins, functions etc.

Backbone is a javascript library supporting an MVC like framework to develop single page web apps (rendering a complete UI in one html page) where the only time to go to the server is to interact with REST resources for data. It organizes code into models, views and collections. It's 'controller' is implemented as a router that allows linking to behavior and routing as bookmark-able URLs for browser history. Views typically use client side template resolution implemented by underscore js and not implemented on the server. Models structure information passed to and from the server. Collections are collections of model objects that are associated with a REST resource on the server and support CRUD operations.  

What is obvious by analyzing technology innovation on the front end is how much we rely on good javascript skills to make it all happen. However javascript allows as much clumsy programming as it offers in elegance (read JavaScript The Good Parts by the Great Crockford). Larger scale javascript code can be quite strange to read when trying to leverage the good parts and organizing js into classes and modules to scale. So pre-compilers like CoffeeScript and Closure offer amazing lexical simplification and cleaner code organization and optimization. Neither of which we are using currently, but we possibly may. The elegance and readability of coffee-script for instance or the compression and performance enhancements with Closure are very impressive.

Further, writing large scale javascript application requires more than just MVC, it requires modular development. Wrapping the javascript into good modular design is accomplished following the AMD pattern (as explained well in this blog). Using require.js helps solve the problem of dependencies when javascript itself has no 'import' or 'module' commands, as well as allowing asynchronous loading and plugin architecture for the loading of different kinds of resources (like text)..

And what about testing? Our team is big on developer testing before tossing our project off to QA, and we like practicing TDD (or now BDD). There is QUnit from JQuery. But we are beginning to use jasmine. Jasmine, like QUnit runs tests and renders results on a nifty html page showing passes and fails. Integrating this will a build system for continuous integration (CI) is more of a challenge. That brings us to automated building, packaging, deploying, and continuous integration testing and analysis.

Our back end is traditional J2EE. We expose REST resources via Jersey and interact with business services and information via EJB3 and JPA (and also the great SOA Suite layer from Oracle with BPEL, a Service Bus and traditional SOAP based service integration.  We build using maven, continuously integrate with Hudson, run JUnit tests and generate reports on code coverage via JaCoCo or Coberatura. On the back end, we are used to automating this build and deploy cycle and assuring no breakage after each check in. But these tools and techniques are new to us on the front end side..

We need solutions for automated and scripted builds, running and analyzing tests, code coverage and other static analysis using continuous integration techniques. At least that is what we are used to and expect. This process must/should integrate with our existing continuous integration and code analysis tools if possible. Tools offered as part of Node.js are possible solutions. Also maven has a javascript plugin. Many others exist as well. Further analysis is required on this. I will update progress on this blog.

No comments: