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.
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
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.
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.
_Introduction While researching which flux implementation to use for our team's final project at Hack Reactor, my friend…_www.youhavetolearncomputers.com
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…
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.
Comparing the Performance between Native iOS (Swift) and React-Native
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
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.
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 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:
Technology Radar | Emerging Technology Trends for 2017 | ThoughtWorks
_What's happening in the Languages And Frameworks quadrant of the ThoughtWorks Technology Radar? Discover what's new or…_www.thoughtworks.com
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 Native: 5,521
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.
And they use SPF for YouTube:
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
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.