April 14, 2015

A round-up of Angular’s ng-Conf 2015

Written by

Odecee Lead Software Engineer Brett Uglow recently attended ng-Conf 2015 – the world’s original AngularJS conference – in Salt Lake City. Here, he shares some of his thoughts on the event.

Wow – so much to process from ng-Conf 2015! Here are the key themes I took away from the conference.

Angular 2 is looking pretty good

The performance of Angular 2 over previous versions – and even over React – is (and I’m not one to exaggerate) great! Dave Smith ran a demonstration comparing a weekly scheduling component running in 1.3, 1.3 + React, then in Angular 2. Check it out.

I have a number of misgivings about TypeScript (which I’ll go into later), so the fact that the developers repeatedly said you don’t need it to write Angular 2 applications makes me much more keen to try Angular 2 sooner, rather than later.

Making change detection unidirectional (from Model > Component > View) is a good thing for understandability of Angular and for performance. I’m not completely sure if it is related to the Flux architecture’s notion of unidirectional data flow, but I believe it is.

Component Architecture

The component-architecture (and the declarative animation syntax coming to ngAnimate) remind me a lot of Adobe Flex. For the uninitiated, Adobe Flex used ActionScript (almost identical to JavaScript, but with optional types), which had a component architecture and a declarative view syntax (like HTML), including the ability to declare animations like this:

<Parallel>   <Fade target=”componentA” fromAlpha=”0″ toAlpha=”1″ duration=”200″/>   <Sequence>     <Rotate target=”componentB” fromAngle …>     <Resize …>   </Sequence> </Parallel>

Of course, Flex didn’t really have this capability in CSS, so this syntax was the main way of doing animations (though you could also do it in ActionScript). But my point is this – component architectures are starting to adopt the patterns used in previous component architectures, which I feel is a sign of maturity.

Lastly, there was a demo (the Material Design one, actually) that showed how using and configuring an Angular 2 component was the same as configuring a “standard” Web Component – in this case, a Polymer component. Plus, they announced that Angular 2 components will run even in browsers without a Shadow DOM. This is fantastic! One less reason to delay using Angular 2.

Angular 1.4+ will offer a migration path to v2

The fact that ngNewRouter, ngTranslate, and ngAnimate are all based on a single codebase and support 1.4+ and 2.x is a great sign. It means:

  • It is possible to write your module once and have it work in both versions of Angular (good news for component developers).
  • The Angular team is committed to bringing good ideas back to today’s version of Angular.

Building for large applications

Jen Bourney’s presentation on building platforms with Angular was salient to my current work at Odecee. There were a few things suggested by Jen that I can apply to my current project:

  • Optimising the lazy-load process to load modules with temporary routes initially, until such time as the actual module is loaded and loads its own routes (and then cleans up the temporary route. This is much better than the main routing module having to know up-front all the routes of the lazily loaded modules.
  • Allowing components to look-up their configuration at run-time (we’re kind of doing that already, but it’s affirming).
  • Using pre-commit hooks to run tests and ensure code has been linted before it gets into the repository.

Angular and React

I felt compelled to update my original draft of this post with a brief discussion of Angular and React. The Angular + React video by Dave Smith now has an additional two minutes of Dave explaining how the demo at the conference wasn’t entirely fair to React. He then creates a fairer comparison between Angular 2 and React with the result being that they are almost as fast as each other in this instance.

This got me thinking – what do I really care about as a developer? I’m not an Angular ‘fanboy’. I have used many libraries (like JQuery, jqMobile) and custom frameworks before to create web applications and sites. But I currently use AngularJS because:

  • It is easily testable, which is very important to the financial companies Odecee does work for.
  • It allows the application to be layered (models, views, view-models, services, commands, data access objects).
  • It allows me to write HTML in HTML files.
  • The above three points mean that Angular code is maintainable, which is also very important to our clients.
  • Our clients are quite happy with Angular’s current performance for the use-cases they have.
  • There is a lot of support for it in terms of people, tools and components.
  • It offers a path to ES6/HTMLnext today.
  • The community is supportive and helpful.
  • It keeps getting better (faster, more features, simpler to use).
  • It does not prevent me from using other technologies if I want to, such as React or jQuery.

I don’t use Angular because:

  • It produces the fastest code in every situation.
  • It is the ‘hottest’, shiniest thing on the market.
  • It looks good on my resumé.

I would use another technology (such as React) if:

  • The global market decides that React is a better platform for web development, and clients start demanding we build systems using that technology.
  • It has a good ecosystem of tools and components that allow me to write maintainable code.
  • I can still write my view separate from my code (JSX, I’m looking at you).

Dave’s talk was actually about how you can use Angular and React together, and the times when you would and wouldn’t do that. So, in that spirit, I would say this: when I come across a business problem that requires a solution involving a lot of DOM manipulation, and an Angular implementation is not fast enough, I would explore using React.

FireBase, BackAnd, Wakenda, Falcor

All of these companies are offering ways to make it easier to talk to data stores and setup applications faster, which is great! My only concern is that the demos we see keep doing things like this:

function MyController($firebaseService/* or other db IMPLEMENTATION */) {   this.users = $firebaseService.get(‘/users’);   this.edit = function (user) {     user.$save();   }; }

This violates an architectural principle (which John Papa also subscribes too) in which controllers should not know about how data is fetched or stored. This is an implementation detail and does not belong next to view logic; rather it belongs in a data-access layer (implemented as a service, in Angular).

So, I’m hoping these demos we’ve seen are understood by the community to be demos, not ‘how-to’s’ for using these data services. If not, every new version of Firebase/Wakenda/BackAnd that is released will force you to touch your view-logic code instead of your data-access code.

TypeScript is wonderful (if you sell tools or don’t want to RTFM…)

…which I guess is fair chunk of the programming community, now I think about it. But that doesn’t make it right!

I guess the thing that still bothers me about TypeScript is the extra work that I, as a programmer, have to do to make my IDE work properly:

  • I need to find or generate TypeScript definition files for each JavaScript library I’m about to use. There goes five minutes.
  • I need to include references to those libraries inside my source code (urrggh!).

“Two steps – that isn’t so bad!” I hear you say. Well, then there are compiling and deployment steps:

  • I need an IDE that compiles the code automatically, or a build task to do this (which increases my debug loop).
  • I need to separate the source code from the compiled code (WebStorm by default generates your JS code beside the TypeScript file, but you can configure that).
  • I need to make sure that the generated code runs on browsers that the app must support. And depending on the ES6 features I’ve used, I need to include a shim.

In summary, using TypeScript requires more work than my current development process and increases my debug loop. It reminds me of the step you could perform for Java projects, whereby you tell the IDE where the source code for a JAR file is so it can help you debug the JAR. It was extra configuration I feel I shouldn’t need to do.

To summarise, as long as TypeScript increases my development effort, I don’t intend to use it. If that changes, I’ll reconsider.

Google Material Design

I have mixed feelings about this.


The Material design components that Google have built look pretty good. They appear to make it easy to get a material-looking application working quickly. The 10-minute demo we saw on day two was quite good (despite some editing-tricks).


If I use Google Material Design, won’t my app be just like every other Material Design app? I guess it just feels too prescriptive, like Microsoft’s UI Guidelines were for Windows programs. Now don’t get me wrong – I’m all for UI conventions that make it easy for people to use new apps. But as a user, do I want all my apps to look and feel the same (besides some theme colours)?


When you contrast this with what Twitter’s BootStrap framework (which is kind of a component library as well as a CSS framework) offers, I feel designers have waaaay more freedom to customise the look and feel of their app with BootStrap than with Material Design. And they can do this without affecting usability or breaking common UI conventions.

Prototyping with Angular

This was a pretty cool presentation showing how the UX guys use their own Angular components to quickly change and configure working prototypes of components and applications. I especially liked the demo in which they hooked up the Google Voice API to Angular, and could command the component to change its style by saying things like ‘make the header blue’ and ‘change the background picture to the car image’, and the app changed!

Other noteworthy things

  • Ionic would be my starting point for building mobile-centric apps. It has lots of neat features like view-state caching (remembering which page on a tab you are viewing, so you can change tabs and come back to the one you were looking at). Again, reminiscent of Adobe Flex.
  • Falcor by Netflix, when it is open sourced, could be better than FireBase. Maybe. It batches service requests to enable views to be served with only the data they will render/use, rather than the complete object containing all the data-fields/properties.
  • Benchpress tool for Protractor looks cool and helpful.
  • John Papa’s talk on the need for code readability was excellent, with glimpse of a new tool that can validate a style guide.
  • Protractor plugins for automatically finding accessibility issues look cool. In fact, I’d like to contribute to Protractor to fix the horrible syntax for getting and setting an input element’s value: get uses setText(), set uses inputElem.getAttribute(‘value’).
  • Running the $digest() cycle in a Web Worker was interesting, and may be useful in certain edge cases where you need to perform a long running client-side calculation (like a prime number calculator).

Final plug

I had the opportunity to attend the Advanced Angular Workshops on the day before the conference. The workshops covered Protractor testing, Advanced Directives, ngAnimate and angular-formly which is a data-based form rendering component by Kent C Dodds.

This last workshop especially interested me as it offered a different approach to supporting many of the same use-cases I considered when building angular-form-lib. The main differences I see between the two libraries (at the moment) are:

  • angular-form-lib still uses directive-elements to define the form elements, whereas formly uses model data.
  • angular-form-lib offers the ability to create form-policies that allow you to define how you want all form across your site to behave. For example, you can define a policy that says, “When the form is submitted and there is an error, set the focus to the first field with an error”, which is super-useful and accessible.
  • angular-form-lib links error-messages (regardless of how they are formatted or displayed) to the form-control, so that when the form control has the focus, screen-readers can read out the error(s) associated with that field.


Tags: , , , , ,

Categorised in: Digital, Technology

This post was written by Brett Uglow