As of March 2016 (Angular 2 beta.11) the answer is yes… or rather, yes*.
Google offers an existence proof. The Angular project leaders at Google have stated publicly (I most recently heard it on a podcast) that Angular 2 is already in production on significant projects inside Google. They mention a project with size information: around 100 developers, hundreds of components, thousands of users. It is a CRM system – they did not describe its features, but we can safely assume that it has the sorts of things you typically see in a CRM system.
(They also mention that a new version of the Adwords advertiser interface is in development in Angular 2, with a much larger team team, intended for a vast user-base, right at the heart of how Google earns money – but this project is not yet in production.)
Now for some caveats:
- The Angular team was talking about internal applications – which usually implies loading over a fast network, so payload size is not very important. As of March 2016 the payload size of Angular 2 is still quite large.
- Google’s large Angular 2 projects, at least the ones mentioned, are coded in Dart, not TypeScript, so they benefit from the more straightforward tooling for Dart. In fact, this makes me wonder if we should consider Dart. So far we have not, as it appears the development community is far more interested in TypeScript.
Oasis Digital’s Experiences So Far
Here at Oasis Digital we are building software for customer production deployment in the coming months, in Angular 2. We also have a large swath of Angular 2 training materials for Angular Boot Camp (already teaching Angular 2 classes). To further get our feet wet, we have even built some of our recent public-facing web properties with Angular 2 – but temporarily accepting the large payload size, assuming the size will come down before becomes a priority for us. We’ve also met teams at other companies building at scale in Angular 2.
From this experience, here are more caveats about heavy development or production use:
- We work primarily on business applications where deployment payload size is not such a big deal… but extensive functionality is vital.
- There has been quite a bit of churn over the last few month. Keeping up with the churn in a stack of alpha and beta tools, can use up quite a bit of time. Here at Oasis Digital we can justify it because we invest this time building up our expertise, to teach classes. It could be harder to justify an organization only building applications, looking for a stable and finished platform.
- The developer experience has some critical rough edges. Unlike the competition over at React, Angular 2 offers no compile-time help with either the types or the names of any data that passes through templates. For now we recommend limiting exposure to this by moving data almost entirely outside of the template system, using it only for tableting and not for binding our components to each other more than necessary. There are other great options (Elm/Redux-like architecture, injection, Observables) for data flow. (WebStorm now offers a degree of development tool support for Angular 2 templates, though that doesn’t remove the need for Angular 2 to support it natively.)
- Browser supports isn’t very complete yet – some built-in Angular 2 features (like most of the Pipes) are broken in some common browsers, though the problem can be patched with a polyfill.
- The build/package story is rather rough:
- Webpack is mature, but using it in development on a sizable angular 2 project is quite frustratingly slow, on Windows especially.
- JSPM offers an alternate future-oriented approach, with the frustration of installing most packages twice: once via NPM so that TypeScript can see them, once via JSPM. so that the bundler can see them. This irritation may go away, if TypeScript becomes more configurable, or becomes aware of JSPM out-of-the-box.
- A third approach, which seems most practical for today, is to use SystemJS but not JSPM, then use the pre-bundled Angular 2 and related packages, and perform TypeScript compilation with the –outFile option. This means minimal moving parts during development, and faster recompilation. It also makes it possible to perform TypeScript compilation in your IDE for error checking, and use that same output (rather that throw it away and compile it again via a bundler plugin) to execute in the browser.
Angular 2 is ready enough to use today, to build applications at scale for production deployment – but be aware of the need to allocate ongoing technical effort to keep up with things.