AngularJS – The good parts

As promised in the „bad parts“ article I now want to speak about some of the things AngularJS shines in my eyes. I promise to keep it shorter this time :)

Without further ado:

Forced to structure your app  in a decent way

Especially when you’re new to the Single-Page-Application world, this is a good thing. Angular is opinionated, but so chances are good, your app will be maintainable months later.


Rather subjective. I enjoyed working with Angular very much. APIs seem clean, and because of the gradual learning success, we didn’t get stuck anywhere.

Productivity and turnaround

You get to see results very quickly. I could showcase real results „live“ while discussing with our requirements guy. Not always, but more often than I expected.

Quick first successes

Getting started with Angular went quite fast for me, thanks to good documentation and tooling.

Testing is first class citizen

Looking at the documentation, the community and tooling, testing (and especially unit testing) is really taken seriously. More seriously than in most Java projects, I’ve seen. Feels great!


The documentation by Angular itself is very good. But there exist tons of third party docs as well (for example this). Many books, video tutorials and usergroups are available.

Large community

Many devs are discovering SPAs and Angular in particular. Stackoverflow, Twitter and the blogosphere are rich on content.

Many good third party components, less need for homegrowing

There exist tons of third party components for AngularJS. Some are well tested and good, some not. Compared to Eclipse RCP, there are only rare cases that you need to homegrow your extension.

Loads of best practices accessible

A mix of the three aforementioned aspects: Beyond the structure given by Angular and the availability of third-party components, you get a lot of content that tells you how to manage your app if it gets bigger. Best-practices, design/architectural blueprints, or simple opinion. For example this.

Until now no hard roadblocks

Being in production mode now, we have yet to find a hard blocker, that stops us developing a longer time than, say, a day. I’m surprised.

Asynchronicity applied well

I wrote about the asynchronicity in the bad parts bit. Especially promises are a bit quirky at first. But you get the idea fast and asynchronicity felt natural fast. Very powerful bit with Angular, that I miss in my Java environment at times.

Two way data binding just works

This is a feature that is discussed a lot. Some people argue, that you don’t need it after all. I think it comes quite handy. I have worked  with JFace Databinding within Eclipse RCP. Angular databinding seems nicer to me. But I can apply the same set of patterns that I applied in the Eclipse RCP context. Good thing.
Minor drawback: There maybe some negative perfomance implications, if you have more than 2000 bindings on your page. But most of the time, you can use things like one-time-bindings to leverage this. One-time-bindings are available in AngularJS 1.3 (use this if you use Angular < 1.3).

 Integration of Non-Angular-Libraries

Besides some minor glitches with some JQueryUI widgets, we did not have any mentionable problems integrating Non-Angular-Libs. For example we used D3.js, which could be nicely packaged as a directive.

„Backendless development“ – REST backend with express suffices

As Angular more or less forces the usage of a REST backend, you have the complete freedom how this REST backend is fleshed out. Having node.js on our desks already, we found it extremely handy to just start with some simple express endpoints. You can even mock your endpoints completely from within Angular.

That’s all for now. Thanks for reading!

Hinterlasse eine Antwort