Yesterday evening I attended the first session of a two-part workshop about AngularJS. The session was organized by InfoSupport as part of the so-called University Sessions for members of the Dutch Java user group NLJUG.

The evening was very well organized starting of with catered Indonesian food. Next, Teun Hakvoort gave a quick introduction of AngularJS. This overview was followed by a QA session hosted by Peter Hendriks with Brad Green (@bradlygreen), the AngularJS lead from Google, live from California. After the break it was time for some hands-on exercises, which proved a little bit too much time consuming. So I’ll have to finish the remainder at home 😉

So, what is AngularJS?

AngularJS is an open-source Javascript framework developed at and maintained by Google. AngularJS is aimed at running single-page applications. One of its goals is to bring the MVC design pattern, which is widely used at the server side, to the browser in an effort to make development and testing of Javascript applications easier. It also features concepts like dependency injection (DI), two-way data binding, modularity, templating, reusable components, and directives (custom HTML elements). Again all of them making life as a client-side Javascript developer much, much easier.


From this first introduction, to me AngularJS looks like a very useful framework for building single-page browser applications. It also appears to provide (just) a bit more than its main rivals, Ember.js and Backbone.js. However, there are two major drawbacks not specific for AngularJS but more common for all similar Javascript frameworks.

First, there is the point of security; authentication and authorization but also concerns like data-integrity. The complete application runs in Javascript in the browser. So by definition it isn’t very secure. From a (RESTful) service provider point-of-view, for instance, you cannot trust the client. So you have to find some way to secure your services.

Secondly, there is the aspect of accessibility. What if you have to support clients that have disabled Javascript and/or are using screen or braille readers? In that case you just cannot depend solely on a AngularJS. There is no fallback mechanism like there is in some serverside frameworks, e.g. the AjaxDefaultFallBack features in Apache Wicket.

My (preliminary) conclusion

If the drawbacks mentioned above are not an issue, and you don’t mind or can overcome possible performance issues on especially older mobile devices, then AngularJS could be a nice framework to look into. It could in particular be a nice fit if you want to offload costly CPU processing from your cloud platform to your client’s CPU.

On April 16th the University session will be continued at InfoSupport. With topics like (unit) testing, continuous integration, AngularJS in an Enterprise Setting, I can’t wait till then.