Brad Green spent some time discussing how Google as a company is fully embracing Angular as an application development framework. In fact, the goal is to have all web application development within Google to be using Angular by the end of 2017. He also explained that it makes sense for them to invest so many resources into Angular as an open-source project because of the additional benefits to Google itself. The primary benefit is the large ecosystem that has grown around Angular. Libraries and tools would probably not exist if Angular was simply an internal Google project. In addition, Google has built several tools internally that have been reproduced in other open-source projects. It makes sense that there is benefit to sharing these efforts with the community. It also helps with hiring within Google, where proprietary in-house tools require additional training and ramp-up for new hires. And, of course, the overall quality of the source code is improved by the great feedback received from the community through PRs, documentation, and training.
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).… Read more
I’m glad to be back again at ng-conf in Salt Lake City. I’ve used Angular since the very beginning and it continues to get better. Here are some of the highlights that stood out to me from the first day of the conference.
During the keynote, there was discussion about gauging the success of Angular. They estimated that the community is around 1.3 million users of AngularJS (version 1 of the framework) and 810 thousand users of Angular (versions 2 and 4 of the framework, they skipped version 3). Of all the applications out there, about 90% of them are internal applications (ones we can’t see because they are behind the corporate firewall). 17% of the public Angular applications are already on version 4 of the framework.
There are over 200 applications internal to Google that are using the framework. These applications serve as an initial test bed for all updates of the framework, helping to ensure smooth updates to new versions.
Version 4, released a short time ago, has some great improvements in performance and the size of payloads. The team worked hard to ensure that upgrades went smoothly and there were no breaking changes in the framework APIs.… Read more
The last day of ng-conf 2016 continued with lots of great information. Some highlights:
ng-transcludedirective now supports a name property and directives can specify multiple transclusion slots that correspond to these names. This allows Angular1 to come closer to how
ng-contenttags work in Angular2.
Some highlights of day two of ng-conf 2016:
angular2/coreis now referenced as
@angular/core. This change allows for better use of the ES2015 modules and better optimization when using the offline compiler.
I just finished up the first day of ng-conf 2016 and as usual, it has been a great informative conference. Thanks to the organizers, sponsors, and Angular team members for all your efforts.
Here are some highlights from today:
In this post, I want to focus on managing application state. In the example application, I tried to create an application that had a reasonably complex user interface (“complex” is relative here, of course). The user interface needed to show where changes in one area of the page had immediate impact on other areas.
If we look at the “edit view” of the application, there are three panels: the list of images grouped by tags, a details table of image information, and the image edit panel. User actions performed in one of these panels have an immediate effect on the other panels.
“The horror! Revoke his Angular2 license now!!”
I’m in no way saying this is a best practice or even a good practice. Including jQuery is not required or even desirable for most Angular2 applications. Angular1 had a dependency on jQuery or its own jQuery-lite version, but for Angular2 this is no longer the case.
jQuery will also cause problems for other scenarios, like pre-rendering the Angular2 application on the server or in a web worker, because jQuery components are expecting to work with the physical DOM. Plus it weights your application down with additional dependencies that will cause the application to load more slowly for a user.
But using jQuery was practical for this situation and gives me the chance to demonstrate how Angular2 can interoperate with existing web technologies. Let’s take a step back and look why jQuery might be worth considering in certain scenarios.
There’s been much discussion about creating general purpose user interface components (commonly called “widgets”). Think of widgets as resuable pieces of user interface that can help you to build your application, for example, a progress bar, a dynamic and sortable table view, menu bars, charts and graphs, etc.… Read more
Angular2 has a strong emphasis on components. An application is made up of a tree of components, starting from the root component and working down to child components. This helps to organize your application into logical and manageable pieces. Complex user interface can be broken down into smaller components, assembling them together, to better organize your application’s functionality and how it is presented to the user.
Components can be further categorized. Some components are just simple user interface components, for example like a date-picker widget or a simple user information card. These components are used throughout your application, but they don’t exercise your application logic. That work is delegated to other parts of the application. These components might be called “Presentation” (or “Dumb”) components.
Other components serve to organize and orchestrate the activities of child components and application services. These components know about the application logic. They might push application data down to child components and respond to events emitted by them. They might transform an event into a transition to a new application state. These components might be called “Container” (or “Smart”) components.