Why Angular 2/4 Is Too Little, Too Late
TL;DR — AngularJS was a decent idea in 2012 but in 2017, the JS ecosystem has surged past Angular in maturity, flexibility, and productivity. Thanks to webpack, NPM on the front-end, and a mature ecosystem of tooling and libraries, it is quite easy to maintain a large, flexible, well-engineered SPA with React, Vue, or other lightweight JS libraries, even at enterprise companies with large teams.
In addition, Angular 2/4’s troubled 3-year development cycle and debatable architecture decisions should give any company pause before considering the adoption of this brand new framework.
—
It’s 2017. You’re looking to build or rewrite your front-end architecture. You’ve heard a lot about React vs. Angular and how they contrast and compare. The debates have raged on over the years. A lot of people will tell you that this is a Coke vs. Pepsi debate, framework vs. library, tradeoffs, pros/cons, etc, etc. but in 2017, it’s easy to see that Angular 2/4 will never reach the top-tier status of its popular AngularJS predecessor.
2012: Why AngularJS Got Popular
AngularJS became very popular due to its easy two-way data binding, MVC architecture, built-in module system, dependency injection, and routing package. Initially built as a hobby project by Misko Hevery in 2009, the framework started to take off shortly after its 2012 1.0 release. It quickly became the most popular SPA framework for front-end development.
In 2012, the JavaScript ecosystem was a very different place. Knockout, Backbone, Ember, Angular, and perhaps a few others were all vying for JS framework market share. ES6 wasn’t a thing yet. NPM wasn’t used for front end code. Libraries and frameworks weren’t mature. Steve Sanderson, of KnockoutJS fame, gave a great assessment of the front-end landscape at the time following the “Throne of JS” conference.
AngularJS solved a lot of problems for web developers out of the box. For simple SPAs, it hit a sweet spot of productivity. Tooling started to grow, custom directive libraries were released, and the platform grew extremely quickly.
However, as developers started to build professional, rich, full-grade applications on the framework with large teams over long periods of time, its limitations began to show. Two-way data binding, watchers, $scope variables, state management, confusing and repetitive abstractions like factory/service, and many other issues inhibited AngularJS in production.
At the peak of Angular’s popularity, in 2014, the team behind Angular announced that they would be creating a completely new incompatible framework. They would confusingly, perhaps even deceivingly, label this new framework Angular 2.
This controversial announcement was met with a lot of skepticism and criticism in the developer community. Since no upgrade path would be provided, every application built with AngularJS would need to be rewritten from scratch. The community splintered, and while some would stick around to see if Angular 2 would live up to its promises, others decided to look elsewhere for front-end development.
2013: How React Revolutionized Front End Development
At the peak of JavaScript fatigue in 2013, Facebook open-sourced React after having used it in production for more than two years. React pitched itself as the V in MVC (Model-View-Controller). It completely shook up the JS front-end community with its one-way data flow and its dead-simple functional component model.
In 2013, Angular and every other JS framework was pitching two-way data binding as a feature. React came along and told us that was a bad idea. Two-way data binding is great for simple applications but in production, at scale, with large amounts of state, it can easily become spaghetti. Lots of unpredictable side-effects can be triggered. Two way data-binding was a feature in 2013 and Facebook said it was a bug. It turns out they were right. Ember, Angular, Vue, and others would later adopt the one-way model.
Facebook was unopinionated about state management, however. Instead, it offered “Flux” as a solution, which was more of a pattern than an actual library or framework. Shortly after React’s announcement in 2013…dozens of Flux implementations arrived on the scene including Flummox, Alt, Fluxxor, MartyJS, McFly, etc, etc, etc.
We hit peak “Flux fatigue” when, on June 2, 2015, Dan Abramov released Redux. Inspired by Elm language, Redux brought predictable, functional, maintainable state management to JavaScript. Redux introduced actions and reducers that follow a pattern that shares similarities with Event Sourcing, which is a common software architecture pattern in back-end server technologies. Redux’s explicit, declarative data management model allowed for state to be managed easily and scales well with the application.
This allowed for super-powered front-end features like time-travel debugging, hot module reloading, and simple and easy undo/redo capabilities. It also encouraged a functional design pattern, which allows for your code to be easily testable and easily reasoned about.
Redux took the React community by storm. Two years into the Redux hype cycle, we are still seeing enthusiasm. It’s being used in many enterprise-scale software companies like PayPal, Mozilla, and AirBnB and it forms the foundation for the popular GraphQL client-library Apollo. It’s even being adopted as a state management solution in other frameworks. Today, it’s the de facto state management solution to be paired with React.
Meanwhile, other innovations in the React landscape continued to transform front-end…
Server-side rendering
Because of React’s functional UI abstraction, it can run in any environment. Many began to realize this in the early days of React and started pairing it with Node.js to provide server-side rendering. React is already extremely fast, but paired with server-side rendering, all the data is loaded into the view and rendered on Node itself before a webpage gets loaded. This allowed for single page applications to be search engine friendly.
March 2015: React Native launches
In March of 2015, Facebook announced React Native for iOS. A landmark announcement, it proved that React’s functional UI component abstraction could be leveraged to write native mobile applications for the first time.
Rather than promising, “Write once, run anywhere”, which is often derided as “Write once, debug everywhere”, Facebook pitched “Learn once, write everywhere” as a philosophy. Inherent in that philosophy is that while it is possible to share a large portion of code between platforms, there are often many nuances between platforms that must be uniquely addressed. React Native provides an interface for addressing those platform differences.
Within 6 months, they would go on to launch Android support. The productivity gains were astonishing, allowing developers to share 90% or more of the code across mobile platforms with truly native rendering performance.
Microsoft would later release React Native libraries for building Windows applications: https://github.com/Microsoft/react-native-windows.
Today, React Native powers Instagram, Facebook, Wal-Mart, Baidu, Skype, Discord, and a slew of other professional grade applications.
We can be almost certain that React & React Native are a competitive advantage. We can see evidence in how Facebook simultaneously launched Snapchat-like “Stories” across four applications (WhatsApp, Messenger, Facebook, and Instagram) in its product suite.
Effectively blocking Snapchat’s growth:
Unifying its code base around React clearly contributes to Facebook's velocity as an organization.
NPM, ES2015, Babel, & Webpack
While Facebook was rapidly innovating on the implications of React, a few key developments were occurring in parallel in front-end JavaScript.
JavaScript had long suffered due to the lack of certain key language features. In particular, classes, modules, and lambdas were all missing. ES2015 introduced a plethora of new language features including these three and many, many, more. One of the long-standing problems with JS is cross-browser support for new language features. Babel gave us the chance to use all of these new language features before IE, Chrome, Firefox, iOS and others could roll-out support by compiling ES2015 down into ES5-compatible JS.
With Webpack we got a fantastic tool for easily bundling CSS, JS, HTML, and other project assets. Webpack is loaded with powerful features that were not possible just a few years ago. Minification, lazy-loading, tree-shaking and a whole slew of optimization features are now at any web developer’s disposal.
Webpack’s bundling system enabled another powerful feature: NPM for the front-end. As the default package manager for Node.js and as the world’s largest software registry, NPM is host to virtually every public JS library in existence. It’s basically the app store for JavaScript.
In 2013, it was difficult to assemble JS libraries and dependencies and build front-end code in a maintainable way. In 2017, it’s quite easy thanks to the power of these tools.
September 2016: Angular 2 Finally Arrives…
March 2017: Angular 4 Version Bump
After a much-delayed and troubled development cycle including the departure of two architects Evan You and Rob Eisenberg from Google, who went on to create their own frameworks Vue and Aurelia, respectively…Angular 2 finally arrived on the scene.
In the interim between September and March, Angular fixed its broken CLI and introduced a few more breaking changes. The team launched Angular 4 as simply Angular and have now committed to new releases every 6 months.
Angular 2/4 & up are completely different, as the team first mentioned in 2014. It is built on TypeScript and RxJS, which are two 3rd party tools for types, decorators, and reactive, observable state management.
Angular 2/4 brings a totally new component system that leans heavily on TypeScript decorators, SystemJS modules, RxJS observables, and Angular’s custom HTML-like syntax.
A component system is the core of modern UI development. React solved components so well that the Web Component W3C standard never really took off.
Angular’s component syntax is demonstrably more verbose than React. It can take 10x as much code in Angular and more wiring and ceremony to describe the same output. Instead of embracing a JS-first philosophy, Angular components instead place logic inside HTML, which makes components harder to test, harder to reason about, and limits you to the functionality of Angular’s custom DSL instead of React’s Turing-complete JavaScript XML (JSX). Angular 4’s release notes even went as far to tout “else” with *ngIf as a new feature.
Angular 4 arrives on the scene in 2017 in a very different world than AngularJS saw in 2012. It brings a more verbose syntax than React, a heavy weight toolchain that many are having issues with in production, and no discernible gains in performance or maintainability over React.
React’s first-mover advantage on a slew of technologies, from native apps to VR to server-side rendering to hot module reloading to CSS Modules to Sketch integration means that Angular 4 is struggling to catch up. It has not leap frogged React in any way. In 2017, it’s quite far behind React’s ecosystem in capability and maturity.
React Is Much Simpler
Angular 2/4 introduces over 500 top level API concepts which are ripe for ongoing breaking changes in future versions of Angular.
Angular 2/4 produces heavy code with bloated file sizes. Utilizing Angular’s Ahead-of-Time compiler generates files that are 3–5x larger than source even after Closure compilation.
React Has Better Performance
Benchmarks for React consistently show its superior performance over Angular 2/4: https://auth0.com/blog/more-benchmarks-virtual-dom-vs-angular-12-vs-mithril-js-vs-the-rest/.
Dubious Claim: “Angular is Better For Large Teams”
It is often claimed that Angular is better for the enterprise and this is this framework’s alleged sweet spot. However, this claim is not backed up by actual production results or history itself. There are few enterprise Angular 2/4 results in production today. Seeing as it is less than 9 months out of beta, this should come as no surprise.
There are no examples of some company moving a large codebase from React/Redux to Angular 2/4 and seeing productivity, maintainability or performance gains.
Even after 3 years in development with constant, painful, breaking changes…early reviews are mixed:
I would posit that at this point, the onus is on Angular 2/4 to prove that it achieves superior results and user experiences in production at enterprise scale. This has yet to be seen despite years of promises and tons of hype.
What should an enterprise optimize for? It should aim for building maintainable, performant software built with battle-tested, mature tooling.
A good framework should have: stability, activity, ecosystem, community, learning-curve, skills within the job market, and ease-of-migration should things change.
React has 6 years of maturity and proven maintainability at Facebook scale and it is powering some of the world’s most complex enterprise systems at companies like Twitter, Slack, Atlassian, Netflix, Salesforce, Microsoft, Apple, Quip, Wal-Mart, WordPress, NYTimes, and many others. People are seeing very real, very clear production advantages in the enterprise. And the user experiences produced by these systems should more than speak for themselves about the results that are achievable with React.
React has been much more stable than Angular. When it does change, Facebook releases code mods that automatically update your code base.
Angular’s Splintered Ecosystem
It’s important to note that since Angular 2/4 & Ionic 2/3 were completely rewritten in an incompatible fashion, all directives and modules that were written for AngularJS are completely invalid for these new frameworks. This means when you begin with Angular 4 & Ionic 3 in 2017, AngularJS’s rich ecosystem of custom directives are not available to you.
The JS community has moved onto lightweight frameworks like Vue & React by an order of magnitude over Angular 2/4:
NPM Package Count
React: 31,654
React Native: 5,521
Vue: 4,657
Angular 2: 4,510
Angular 4: 527
Ionic 2: 207
Ionic 3: 31
When you begin an application in 2017, how much custom work do you want to do? Do you want to roll your own everything and hope the ecosystem grows with you or take advantage of a rich, mature ecosystem of components that have been open sourced by world-class front end talent from the likes of AirBNB, Facebook, PayPal, Microsoft, Apple, Yahoo, Lyft, and more?
Facebook Heavily Dogfoods React In Production; Google Not So Much
A lot of people choose Angular because they hear it’s a tool created by Google. They assume that because it’s Google, it must therefore be the framework that is predominantly used at Google for front-end applications. Therefore, it must be battle-tested and proven at Google-scale in production. They would be wrong in that assumption. In truth, Google trusts Closure for most of the applications you know and love including Search, News, Gmail, etc.
Closure Library | Google Developers
_Create powerful and efficient JavaScript._developers.google.com
And they use SPF for YouTube:
SPF
_A lightweight JS framework for fast navigation and page updates from YouTube_youtube.github.io
Angular is used minimally in production at Google. We can surmise that with its troubled development cycle, large bundle size, and heavy-weight nature, it’s not hard to see why: Google’s web properties depend on quick download and execution and that is something Angular does not shine in.
The Battle Is Over: React Won
The Angular team blinked and the entire JavaScript ecosystem surged past them. It is now quite easy to pick from a buffet of options to build an enterprise-grade web application using battle tested libraries that are used in production at large-scale companies.
In 2017, React has become the dominant choice of front-end development. It is currently the 4th most starred repository on GitHub, making it the most popular JavaScript framework repository of all time.
With 4.4 million downloads per month on NPM, React has more than triple the use of Angular’s present 1.4 million downloads per month and it is growing at triple the rate.
A survey of 9,000 JS developers was done in 2016 and found React had a 92% developer retention rate compared to Angular 2’s 64% retention rate. With React being 3x more popular, growing at 3x the rate and Angular only managing to retain just under 2/3 of its developer base…it’s easy to see that React has already won.
React and its ecosystem have created a powerhouse, productive front-end stack that lends itself to lightning fast, maintainable development that is not built on hype, but solid production results.
The future of UI development belongs to React and other lightweight JS frameworks like Vue. Angular 2/4 is too little (perhaps too much), too late.
Thank you for writing this long post! I guess, AngularJS is still more popular, because many developers are used to the older version and stick to it not paying attention to the newest ones, even though there are lots of privileges and improvements. Another thing is it was quite complicated to migrate from AngularJS to Angular 2, so developers are afraid they have to keep switching from one version to another. Learn more in our blog about AngularJS developers: https://mobilunity.com/blog/how-much-does-it-cost-to-hire-an-angularjs-developer-in-ukraine/
This article is clearly biased. Angular 2 and Angular 4 are performing better or comparable than React on many benchmarks I’ve seen, and with less JavaScript fatigue. I feel like anyone reading this post should read this post as a counterpoint: http://www.stefankrause.net/wp/?p=431
I agree that it’s biased. It is an opinion piece after all…
As for benchmarks of rendering rows…the problem is that’s not where the user experience begins or ends. That’s just one part of the overall performance of an application. What ultimately matters is time to paint to the screen for a typical web application.
Angular produces huge code, and you’ve got to use some awkward combination of tree-shaking/lazy-loading/rollup/closure-compilation voo doo just to get it down to something that is probably still 3-5x the size of an equivalent application in Vue or React. My team discovered the other day that we couldn’t even use default language features like ‘export default class…’ with AOT compilation. https://github.com/angular/angular/issues/11402
Lots of neat gotchas like above there. This isn’t even a problem in any other modern framework (Ember, Vue, Aurelia, React)…so we have to ask ourselves why we should tolerate it as web developers?
The bundle size impacts download speed…especially where it counts on the mobile web.
These sort of things also impact Ionic (a derivative of Angular) as well…where simple apps are in the tens of megabytes: https://stackoverflow.com/questions/44222202/ionic-3-app-size-is-more-than-30-mb
Great article. I went through all of that Angular churn. Bummer. I ended up with Ember as the winning solution though. I can’t understand why anyone would use anything else. Have you ever built something with it?
I have not built anything with Ember. From what I’ve read it is a solid framework…and unlike Angular…has never forced developers to completely rewrite their apps from scratch. So I feel like it’s probably a great option!