BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Common Challenges Facing Angular Enterprises - Stephen Fluin at Ngconf

Common Challenges Facing Angular Enterprises - Stephen Fluin at Ngconf

This item in japanese

Stephen Fluin, developer advocate for Angular, discussed at ngconf the common challenges facing Angular teams that are building applications at scale.

Fluin first recalled the challenges faced by Angular developers in the Enterprise segment that he mentioned in a similar talk the previous year. At that time, Angular developers shared interrogations around shipping mobile applications, sharing components across teams, building hybrid applications, testing, A/B experiments, and PWAs. They also mentioned staying up-to-date with Angular versions and optimizing build time as ongoing concerns.

Fluin then mentioned a shift in the pain points this year driven by new industry and technology trends:

If you look at the coronavirus current situation […] the way that businesses interact with their customers fundamentally changed; and now that’s changing the way that we build these applications and the types of experiences that we’re trying to deliver.
[…] The other thing happening is that there are new technology trends. As the technologies that we’re using end up changing and getting better, the way that we use them ends up changing.

The top emerging concerns emerging from the conversations that Fluin had in the first trimester of this year are linked to user experience, micro front-ends, server-side rendering, monorepositories and code sharing, managing applications that are only partly Angular-based, and presenting a business case for the upgrade of Angular versions.

A good user experience means fast initial load and seamless transitions. Fluin strongly recommended using the source-map-explorer npm package to monitor and analyze the composition of an Angular bundle:

In enterprise conversations, this was actually identified as one of the most valuable things they had learned.

Fluin also mentioned that simply by keeping up-to-date with the latest Angular versions, Angular developers will naturally benefit from smaller bundle sizes or an improved command-line interface implementing configurable optimization strategies (e.g., better bundling, server-side rendering). Fluin posited that seamless transitions between routes in Angular applications already was one of Angular’s strengths.

Fluin then explained that the independent deployability characteristic of micro front-end may come into tension with the recommended use of monorepositories to address other issues such as testing, code sharing, or dependency management. Fluin acknowledged the ongoing effort to achieve independent deployability:

If you look at independent deployability, we don’t actually have a fantastic answer. The answer today is to use libraries [to independently package] application functionality. […] Independent teams get a level of autonomy but there’s still a central level of coordination that has to happen — the application author still has to be the one redeploying everything.
[…] In the future, Ivy and dynamic imports are going to be a huge part of the solution.

Fluin then advanced that monorepositories solve integration and collaboration issues at the expense of specificity and distribution issues. Fluin defended his preference for monorepositories vs. polyrepositories in the following terms:

I’ll say is that it’s definitely my perspective that tools and culture are easier to fix in the mono repository.

Some downsides of monorepositories may be fixed with tooling. Fluin mentioned Google’s bazel, which tracks internal dependencies by using directed acyclic graphs, and rebuilds only the necessary parts of the monorepo. GitHub and pullapprove may also help manage who controls which parts of the monorepository.

For companies in which there is no directive to use monorepositories, Fluin introduced in the talk a pattern that he called viral monorepository. The pattern consists of building up a monorepository iteratively, as opportunities arise.

Fluin further asserted that Angular is good out-of-the-box at orchestrating the miscellaneous parts of an application. In contexts that require Angular and non-Angular codebases to coexist, developers can resort to Angular Elements and ngx-build-plus. Fluin detailed:

You can ship either a bunch of web components that share a version of Angular or independent web components that kind of self-bootstrap.
[Conversely,] if you are starting to get into [non-Angular] teams that are building their own custom elements and you want to start consuming those, that can work really well for leaf nodes. […] Angular has really great support for web components.

The custom elements specification is actively developed and may offer fewer functionalities than Angular elements (which can be customized through directives). The Constructable Stylesheets specification may allow in the future further customization of the styling of custom elements. Current techniques, such as CSS custom properties, still lack complete browser support (IE 11 is unsupported), and polyfilling the feature may lead to performance issues.

Fluin concluded with business reasons that support the necessity to stay up-to-date with Angular versions.

The full video of the talk contains many additional technical details and valuable comments. ng-conf is a three-day Angular conference that strives to deliver the highest quality training in the Angular JavaScript framework. ng-conf took place in Salt Lake City and gathered more than 1,500 developers.

Rate this Article

Adoption
Style

BT