Day Two changes things up from the Day One and Day Three single-track format. There are breakout sessions focused on a specific topic as well as chances to sit down and ask questions of others who have expertise in Angular, including members of the Angular team themselves. It’s a good chance to listen to how others are approaching their development challenges and opportunity to discuss lots of interesting details in depth.
The first session of the day had a few large organizations talk about the things they are doing within their organization to manage Angular projects, how they approach analyzing the performance of these applications, and what kinds of things might help them improve these operations.
In terms of analysis, there was a great emphasis on metrics (“plan and measure”). This included low level tracking of “time to first paint”, “time to meaningful content”, and “time to interactive”. But it also included higher-level tracking of things like “perceived performance” (obtaining feedback about how the user perceives the performance of the application).
Tools were mentioned that help in this analysis. The primary tool, of course, is the Developer Tools within the browser (there was a lot of praise for the capabilities of Chrome Developer tools particularly). Other tools mentioned were:
Lighthouse – a chrome extension / command-line tool that audits for performance, accessibility, and other interesting metrics. This can be used in a continuous integration environment as well.
Source Map Explorer – a tool that helps analyze code bundles to avoid bringing in additional code that is not used, improving the size of bundles.
Bazel – an open-source version of Google’s own build tool. It represents work that they’ve done internally for fast, optimized builds on an extremely large scale.
Generally, the presenters seemed satisfied with what they could do with Angular within their own organizations. They were also continuing to research and investigate additional optimizations, such as better performance by using web workers or service workers.
In the “Ask the Experts” room, several of us surrounded Rob Wormald. My thanks to him for his patience while we peppered him with our questions.
It was a very useful discussion for me. I am currently in the middle of a big React-based project. At the beginning of the project we had in-depth discussions about what platform that we should build on. Obviously React is very popular and perfectly acceptable for building big web applications. But even after diving into deep into React, there are still some things that I prefer in Angular when on large projects with distributed teams.
AngularJS (version 1) of the framework and its shortcomings are well known, but Angular (the name used for all later versions) has addressed these concerns. However, since it is a full framework, rather than having a narrower focus on just the view (as React does), it is definitely more complex. It requires a build system and is best used with TypeScript. There are additional requirements for optimizing production builds. It requires registration of components, directives, and services within an NgModule. Decorators are used to describe how a component is to be used. And Observables are used throughout the framework to deal with asynchronous operations.
But this additional complexity is not haphazard and comes from trying to build a great framework for building applications in the browser, for mobile devices, and for the desktop. The Angular team also wants to be supportive of the community overall and so they don’t spend a lot of time trying to explain to folks why Angular is better. It just leads to toxic, unhelpful discussions so many times.
Rob emphasized that they want the documentation to be better overall, which should include more “philosophical” information about the framework, i.e. why a particular tact was taken for some feature.
Ultimately, your team will make the decisions about what platforms they will use to build an application. I look forward to seeing more information about the technical distinctions of Angular to help teams make better informed decisions when choosing from the wide breadth of options.
One thing that was evident is that “reactive
where Angular has a strong focus. This is certainly one of the reasons
that RxJS is such a key component of the
Angular framework. Reactive programming views information as an
asynchronous stream of data. The application can orchestrate these
streams in interesting ways. Even for simple HTTP requests, observable
versions of these requests can easily be enhanced by adding automatic
retries upon failure, caching and expiration of resources, combinations
with other requests (in series or in parallel), and data refreshes upon
change using simple
There are several libraries that also provide additional functionality built on top of observables. For example, the store component provides an implementation inspired by the Redux pattern but using observables to communicate application state changes.
Sean Larkin is a member of the WebPack team and a primary advocate for the tool as well. He did a talk to a large audience going into some of the inner workings of WebPack. Interest is high in this tool and many projects have adopted it, including Angular. The talk emphasized that “everything is a plugin”. A plugin just expresses the events that it is interested in and responds accordingly. The result is a tool that is extremely flexible and configurable.
Sean stepped us through a project that he had set up to demonstrate writing a plugin yourself (a brave move for such a large audience all trying to work through the examples at the same time!) But it was a successful and very helpful talk. Definitely worth watching.