Angular Conf Melbourne 2018: Conference Recap

“Reactive Programming” by Tracy Lee

“Who suffers from JS fatigue?” asked Tracy Lee (AKA @ladyleet) in her opening keynote presentation. Fewer people than I expected put their hands up. Perhaps those suffering from JS fatigue had chosen to stay at home for the day to recover?

Then again, with things like the Ivy render engine and the Bazel build tool (or as Tracy asked: “…a new Webpack?” –  her words, not mine) coming, maybe it’s not so surprising that people are still excited about Angular.

An enthusiastic extrovert, Tracy quickly dived onto the topic of her talk – what ‘reactive programming’ is, and how it is being introduced to more and more languages and frameworks.

She started by demonstrating how, by using promises, we are already using reactive programming techniques without even knowing it. She then moved onto the proposal to introduce an Observable type to ECMAScript. This type could be used to model push-based data sources such as DOM events, timer intervals, and sockets.

Drilling in further, she introduced two more important properties of Observables:

• They are compositional, ie they can be composed with higher-order combinators.
• They are lazy, ie they do not start emitting data until an observer has subscribed.

Examining both Angular and React, Tracy made it clear that the names may be different, but they both boil down to similar reactive concepts.  Indeed, she recommended that we stop thinking about the word “set” as primarily being a verb (in the sense of setting a value), and instead take a more noun-centric approach (ie, “a set of values”).

Demonstrating  RxJS in a drag-and-drop “Grumpy Cat Game”, Tracy showed how easy it is to use observables. She concluded her talk by reminding us that Reactive programming techniques are available in other languages too, via libraries like RxJava, RxPhp, Rxruby and Rx.net.

At this point we took a break to replenish our energy levels with a variety of fruits, baked goods, and hot and cold drinks. I ate a banana and a brownie, soaked up some UVB radiation from the beautiful morning sun, and discussed impressions of the first speaker with other attendees before heading into the next talk.

“Faster Angular Applications” by Minko Gechev

Who doesn’t like their apps to be faster? JavaScript engines have become so much more powerful in the last ten years. However, the size and complexity of our apps has grown as well, meaning performance is still a big issue.

In this talk, Minko Gechev looked at two important facets of web application performance: initial startup time, and ongoing runtime performance.

Initial Load

Minko started by demonstrating just how quickly people become annoyed when waiting for content to load, especially when average loading times go into the double digits.

He went on to make the important point that not all files are treated equally by the browser. For example, a 170k JavaScript file takes 25x longer for a browser to process than a JPEG of the same size.

With JavaScript still being such a bottleneck, the best way to work around it is to code-split your application and lazy-load chunks of JS on demand, using either route-based or component-based triggers.

However, in doing so it’s worth acknowledging the tradeoff: the user’s experience of lazy-loaded functionality will be slightly worse as they wait for JS code to be downloaded and parsed by the browser.

There are a range of bundling strategies that can help with this, but each one has its own pros and cons. Preloading is probably the most promising, although choosing what to fetch in advance can be highly subjective.

Angular has a preloading strategy built-in, with a custom preloader module that lets you do route-based preloading. However, if your module sizes change and your performance deteriorates, you’ll have to figure out yourself what adjustments to make. This is particularly difficult if you use cascaded routing, with Minko’s only real advice being to cluster small bundles if possible.

The major disadvantages of this tooling is it does not allow for prioritising certain bundles, and nor does it work with content. A possible solution for these problems is the machine learning approach of GuessJs, which can be required as a Webpack Plugin. If desired, you can even use the Google Analytics API to do data-driven bundling based on user behaviour.

Runtime Performance

Minko mentioned here Angular’s OnPush change detection strategy and using pipes instead of methods to dramatically improve runtime performance.

The separation between pure and impure pipes distinguishes when the change event triggers. While pure pipes have no internal state and can be shared, impure pipes trigger on all changes and have an internal state.

However, all pipes needs to be re-evaluated on every digest because an input object can be mutated without changing the object reference (ie, the pipe parameter stays the same). This is why both JsonPipe and SlicePipe pipes are not considered pure, despite having no internal state.

A full overview of the content he covered in his presentation can be found in his series of Fast Angular Applications blog posts.

At this point, Tracy Lee got back on the stage (in a banana costume, no less) as MC for a game of JavaScript Jeopardy. Mixing puns and actual JavaScript knowledge certainly got the audience engaged, although I suspect that the giveaways helped with participation levels too!

“Angular CLI – Go Beyond Ng New” by Ciro Nunes

In this talk, Ciro started by spending 15 minutes talking about how Angular CLI can make our lives easier, and new things that have been added to it recently.

For example, ng new now includes the following options:

• --routing: Includes routing module
• --prefix: Prefixes all component names
• --dry-run:  Run through without making changes

Furthermore, ng add now includes support for the @angular/material and @angular/pwa libraries.

For updating packages, ng update now supports:

• --all: Updates all packages
• --next: Updates to latest versions, including betas and release candidates
• --dry-run:Run through without making changes

Next, our beloved ng generate can now:

• Scaffold server-side Angular usage with universal
• Create a new library

Finally, he introduced:

• ng xi18n, which extracts text marked with the xi18n pipe into a translation file
• ng eject, which generates a Webpack config file based on what the CLI uses for further customization. However, I think it’s worth noting that because it exports all Webpack configuration into a webpack.config.js file and updates package.json to reflect the new dependencies, this action disables ng build and ng serveand cannot be easily undone.

In the second part of the talk Ciro went into more detail on using the Angular Schematics workflow tool to apply transformations to a project. Schematics introduces the concept of ‘trees’ and ‘rules’. Trees represent the existing files and staging area, whilst rules take a tree and transform it into another tree. Using trees instead of the filesystem directly allows us to execute dry runs, and to reuse and extend our transformation code.

A valuable piece of information that went nearly unnoticed was that Angular Schematics actually runs in dry-run mode by default. You need to set dry-run to false to actually have it do something. For example:

schematics .:mycomponent –name=test –dry-run=false

Last of all he mentioned that Angular CLI now includes ‘laziness’ support –  instead of entering the whole command, you can try the first letter only. Furthermore, it looks like Angular CLI’s ng doc support going to be a quite useful feature. This will search the API docs by default, although if you include the –sflag it will search all of angular.io.

Slides to the talk can be found here.

At this point, the sound of my stomach, not much different to the song of a blue whale during mating season, was a clear signal that it was lunch time. Coming out of the dark conference room, I instantly regretted not having my sunglasses with me. Once my eyes adapted to the light, the buffet of pasta, wraps and sliders provided me with sufficient nourishment to move onto the next talk.

“Angular, the Event Loop and You” by Erin Zimmer

Event Loops? Micro-tasks? Zones? In this talk Erin demystified these terms with wonderful explanatory animations.

In summary, event loops are a collection of task queues. While each individual queue follows the FIFO principle (first in, first out), different type of queues run at different times in the render pipeline. For example. the animation queue runs before each repaint.

Micro tasks are processed after callbacks (as long as no other JavaScript is mid-execution), and at the end of each task. During the execution of a particular microtask, additional microtasks can be added to the end of the queue to be processed. It’s worth noting that this exposes them to risk of infinite recursion, either accidentally or deliberately as part of an exploit.

Angular is able to transparently run its change detection after every task by using Zone.js. A zone is an execution context that persists across async tasks. You can think of it as thread-local storage for JavaScript VMs.

Overall, this was an illuminating talk with only one drawback – it was a quite complex topic to focus on right after lunch!

“Angular Components: Decoupled, Shared, Reusable and Opensource” by Wilson Mendes

Wilson started this talk by listing the advantages of using components. However, other than perhaps those without much experience with Angular, I don’t think there were many in the room needing to be convinced about how awesome components are.

Things got more interesting towards the end of the talk when Wilson started demonstrating the use of components with a feature toggle service. That could be quite useful for A/B testing or even just new feature development.

As a final word, Wilson recommended greenkeeper.io for automated dependency management and ng-packagr to transpile libraries to the Angular package format.

“Service Workers – Beyond The Cache” by Phil Nash

My colleague Jim Kim recently wrote about what he learnt at an Angular Conf Australia workshop about service workers, and how, as the Progressive Web Application feature most widely support across browsers, they can be used to cache an app for offline usage.

However, they can be used for other things too – if your browser supports it. In this talk, Phil Nash delved into this.

Push Notifications

With the exceptions of Safari and IE11, support for push notifications is pretty good across browsers. Phil started by pointing out the difference between good and bad push notifications, and then provided a simple formula for making them effective.

Essentially, this comes down to the fact that information without context is of little use to the user. Consequently, according to Phil, push notifications should be:

• Timely: Delivery should be treated time sensitive matter
• Actionable: You should be able to initialise an action by receiving of notification, e.g. confirming a doctor’s appointment
• Personal: Directed personally to the receiver of the notification, e.g. “YOU have a doctor appointment today at 2pm”

Before starting a demonstration of how push notifications in Angular work, Phil remarked that websites usually have to ask for push notification permission the first time they are visited by a particular user. But without any context as to why and how push notifications would benefit them, many users (understandably) opt-out of this, missing out on what could (eventually) be a useful feature for them.

After demonstrating a whole bunch of websites that did this, Phil asked the audience for help to improve the current push notification browser standards, so that users can get the most out of this mechanism. Possible extensions would include:

• Being able to waiting until a time when it will be obvious what the notifications will be for
• Providing the option to opt out within the application

Background sync

Despite officially counting as a developed country, internet connectivity is not always guaranteed in Australia. Try updating an app on the way from Adelaide to Darwin and you’ll know what I mean.

Furthermore, while caching is great for GET requests, it doesn’t help with POST requests. Yet these are exactly what we need when when sending messages, posting comments or shopping online, meaning that lost or intermittent connectivity can be an annoying user experience. That’s where background sync comes into play.

With background sync, if the user loses reception, the request data gets stored in IndexedDB. As soon the user is back online, a sync event replays the request. Unfortunately, background sync is currently only supported by Chrome, which limits its usefulness.

With his final words, Phil encouraged the audience to checkout Workbox (similar to ng-service worker) in this regard.

“Building Native Mobile Applications with Angular and NativeScript” by John Bristowe

NativeScript is an open source framework for building native iOS and Android app using JavaScript and CSS. It renders UIs with the native platform’s rendering engine (so no WebViews), meaning you get native performance and UX.

My colleague Ben Atkins recently wrote about our experiences using it on a client project. In this talk, John gave an introduction for beginners.

He started by building a “Hello NativeScript!” app, demonstrating how it easy was to get started. Then, after a brief overview over the history of the project, John introduced the audience to a few supporting tools:

• NativeScript CLI
• NativeScript Sidekick
• NativeScript Playground
• VS code extension
• Templates, samples, etc.

Next, John list some of the reasons to use NativeScript, including:

• Rich and animated native UI
• Ease of doing native-y things
• Supported by a major software company
• Maximum code and skill reusability
• Vibrant and growing community

In conclusion John encouraged the audience to have a go for themselves here at the NativeScript playground.

Conclusion