AngularJS made me stop hiding from JavaScript

Like most Java developers I used to have a serious aversion to JavaScript.
I was quite happy to delegate any ‘scripting’ stuff to fellow developers.

At my current project, we initially decided to use the Vaadin web framework.
It seemed the perfect choice for creating Rich Internet Application (RIA) user-interfaces without writing a single line of JavaScript.

However what originally seemed to be a sensible choice, turned out to be a dead-end:

  • Vaadin is highly dependent on http sessions and as it turns out doesn’t play well when being clustered.
  • No default support for server push; also the ‘most stable’ Vaadin add-on turned out to be quite unstable and incompatible with clustering.
  • No wrapper existed for v3 of Google Maps; as an alternative we used the OpenLayers Add-on instead. However this add-on turned out to be not so stable either and lacked the user experience of Google Maps to which users are accustomed to (like dragging the ‘pegman’ on the map in order to show street view).

In order to integrate Google Maps v3 into our application (and fixing our OpenLayers issues) we initially considered creating a so-called client-side Vaadin component.
Such a non-standard Vaadin component would have required us to write (at least some) JavaScript and would have been a burden on the complexity of our application.

Instead of writing the Google Maps wrapper we decided to dump Vaadin and rewrite whole user interface using JavaScript and HTML. This allowed us to move to a completely stateless architecture (without http sessions) and implementing server-push using a (stable version of the) Atmosphere framework.

During a 2 week sprint a co-developer and I migrated the google maps related functionality to HTML5 / JavaScript technologies. Along the way we had to gain knowledge about the JavaScript framework of our choice.

Based on prior research we came up with the following short-list of Javascript frameworks being either BackboneJS, AngularJS or EmberJS.
We both already had some prior knowledge of BackboneJS and were both interested by AngularJS and thus decided to give it a go.

Although AngularJS was actually quite new it stood out from the rest with its extensive documentation, built-in support for unit testing, its 2 way binding and clean MVC implementation. Additionally it requires you to only write a minimal amount of JavaScript to get things done.

At the end of the 2 week sprint we decided to investigate EmberJS as well.
Although this framework should be just (or even more) flexible and clean as AngularJS it turned out its documentation was limited, out-of-date and its API was still in flux.
And (even more important) we where simply unable to even create simple test application using the latest stable version at that time

With EmberJS removed from the short-list, only BackboneJS and AngularJS were left.We decided to go for AngularJS as it simply looked the most promising… and we never felt the need to switch afterwards.

So what made AngularJS the perfect framework for us:

  • The two way binding, it’s just perfect; instead of fiddling around with jQuery expressions you simply attach a model value using a “ng-model” attribute on your HTML element. Any change made to the model value (i.e. as part of the logic of a controller) will instantly be reflected on your HTML element; and any change made by the user for this element will also be instantly updated to the model
  • Unit testing is a first-class citizen. Not only does AngularJS allows easy testing RESTfull services by providing mocking for it, it also offers the $document, $window and $log features as mockable replacement of its global variables document, window and console.
  • HTML and MVC controller logic can be get quite clean; a lot of display logic like disabling buttons and setting CSS classes can simply be implemented using expressions in HTML. Alternately widgets like the jQuery Datepicker can cleanly be integrated by creating a new HTML attribute for it (that triggers the set-up on an existing text input element) using a so-called “directive”.
  • No need to ‘extend’ from fuzzy base-classes in order to implement a controller;  instead a standard JavaScript (constructor) function will suffice and all dependencies like the view model (its “scope”) will be automatically be injected by Angular based on the existance of function parameters and its names.
  • Last but not least… it’s really fun to work with

So… Java developers is about time to stop hiding from JavaScript.
Let’s be honest HTML5 is the way of the future and, unless you exclusive work as a back-end developer, there is simply no hiding anymore.

11 thoughts on “AngularJS made me stop hiding from JavaScript

  1. Nice article. Completely agree that we should stay away from using http sessions and switch to stateless frameworks. Did you consider the playframework by the way?

    Say hi to Hubert from me ;-)


    • No, we actually didn’t consider the playframework.
      Does it allow you to write presentation and routing logic in Javascript and use it in combination with a (pre-existing) Spring (MVC) back-end?

      • Play supports Java and Scala and it should be interoperable with other java libraries. I don’t understand the requirements clear enough to answer your question. Not even sure i understand why you would want to do routing in javascript. But play also promotes stateless architecture and it has support for websockets. I am still reading the book but i will be posting new articles on my blog in upcoming months about playframework.

        • Routing and two way binding is the reason why i enjoyed learning Angular, as to why one will route in JS, its very clean to just call backend using GET/Post and route using ng-route.

  2. Hi Emil

    I like your article. Just a question. would you consider using SpringMVC as a back end system or would you just use AngularJS all the way ? I have a a decision to be made, and I am currently leaning towards using Restfull services at the back for back end service stuff. Although my colleagues don’t seem to agree since we are all java or ex-java guys. Thanks

    • Adriaan,

      I would suggest to jusr use SpringMVC for your RESTful Services. There is no need to go JavaScript all the way on the back-end as well.

      We are successfully using SpringMVC on my project (still working on the same project).
      Be sure to use the Hibernate4 module of Jackson2 to prevent lazy-loading during JSON serialization (causing errors since the hibernate sessies is no longer active).

      Kind Regards,


  3. Emil, great article. My company has been using Spring MVC for both front- and back-end for web apps. We provide a SaaS solution that is used by extremely large companies in the US, so application performance is a high priority. We are designing a new user interface, which is obviously the right time to evaluate newer technologies. We are considering AngularJS for the front-end. Now that you have had over a year of experience with this framework, are you still a fan? What is your opinion about using Spring MVC for the back-end services to feed information to AngularJS? Thank you for your insightful article.

    • Thank you for your reply. Always good to know that a blog post is being appreciated.

      As for your question… I’m still a (huge) fan of AngularJS.

      On my project we are successfully using SpringMVC for the RESTful services of our back-end.
      Although SpringMVC is great it could be even better if it would help you to write RESTful services according to REST conventions.
      Instead you will have to decide yourself which HTTP response codes are suitable, how your urls will look like and how to return errors to the client.
      Luckily nowadays that are some very nice REST conventions like:

      BTW. In case you will be returning JPA entities as (part of your) JSON responses make sure to use the Hibernate4 module of Jackson2 to prevent lazy-loading during JSON serialization (causing errors since the hibernate sessies is no longer active).

  4. I must say the Vaadin and AngularJS story resembles my experience as well. It was tough to leave Vaadin but it was too damn slow.

    Even Angular is no piece of cake but its HTML 5 technology so prefer that way.

  5. Tim W,

    What framework did you finally ended up selecting ? Have you evaluated the latest Vaddin 7 yet? Seems like it has gone a long way on performance improvement, native GWT support and server push all using server side technologies


    • Steve,

      Sorry for my very, very late reply… I haven’t been too active lately maintaining the blog and… responding on questions.

      To be honest I don’t know that much about the Vaadin 7 and all the new developments.
      We deliberately choosen to now longer use frameworks that abstract you away from the HTML5 technology.
      Furthermore we had a feeling at the time (don’t know about it’s current state) that GWT was at a dead-end and might not be so future proof.

      AngularJS allows us to directly benefit (no wrappers needed) from all the good HTML stuff around without the complexities when developing only with JQuery.
      Integrating components like Google Maps is easy and since you are directly using their API you have no upgrading issues whenever a new API version is released.

      Hope this answers yours question… let me now if you have some additional questions…
      …this time a will try actually answer quickly.


Leave a Reply

Your email address will not be published. Required fields are marked *