Point of Vue: Angular is doomed, React is OK — We deserve better
Angular (2) created a bloated, hard-to-master, prematurely-abstracted, many-faces creature that suffers from many issues. (Here is my following article focused on Angular pains)
React is an idealistic limited UI library, that focuses only on a small subset of challenges while building modern web apps.
Vue.js is the right tool for your any-scale project, use it today and live long and prosper.
Back in 2010, we had Angular.js (1), it was a great framework that helped us build and maintain huge apps (and small ones) but NG1 had an (so called) incurable disease: as the page becomes larger (displaying more information) it quickly becomes slower and slower.
Then, in 2014 NG1 announced that they are going for a full rewrite of a new framework called Angular2, they promised a lot back then, much has changed, and the framework is still in the making.
Mean while, a former developer from the NG1 team discovered that ES5 has a feature (getter-setters) that enables solving the main challenge of complex UI — change-detection, in a different and effortless way (dependency tracking) and still keeping all the good ideas from NG1. He named it Vue.js.
So, this is a story about dancing with frameworks like Angular and React but choosing to spend the night with the lovely VueJS.
Who are you to say?
I come from a long (+20Y) and deep technological background, varied from C and C++, Main frames, Java and for the past 10 years — focused on the web platform.
I’m leading a consulting company — misterBIT — true web experts and been spending much of the past 10 years mentoring dev teams, teaching and consulting around web technologies and architectures.
Why am I writing this?
As a consultant, I’m tired of being asked about which framework to choose, recommending VueJS and ending up mentoring their React / Angular projects and fighting tight schedule to help them get it on time, many times compromising qualities that are the reasons to use those frameworks in the first place.
So, why React and Angular are a more popular choice than Vue.js?
No one gets fired for choosing Google or Facebook
A claim that I hear a lot is:
facebook is behind React, google is behind Angular, Vue is a one man show — so it’s the safer bet.
This claim is false:
- The truth is that companies throw technologies out of the window when they are moving forward (Flash ,GWT, Silverlight, AngularJS), while community driven projects live longer.
- There is no real bet when choosing to use a rather small open source library — if hell breaks and “there is no support”, you can always go into this fine piece of documented code and fix it yourself.
- Vue.js has several full-time developers and is backed by a large enthusiastic community.
React/Angular is the easier choice for high level managers (no one gets fired for selecting Facebook/Google technology).
For the rest of us — folks that wanna build great products fast and go have a beer, I will elaborate the reasons why we have selected Vue for all current projects.
Oh well, we still teach it from time to time, but seems that demand and traction are going down instead of up, I believe that there are several reasons for that:
- Much boilerplate — meant for large projects with many developers and many pages, so that’s just a small subset of the apps we ought to setup. And the verbosity — OMG — Large footprint and much ceremony
- Platform wanna-be — While Vue.js is cutting out Ajax support as its better done by a specialized library like Axios, Angular want to cover it all.
- Poor, scattered, bothersome documentation and an ocean of broken advices, old courses, misleads to angular.js (1) and broken release candidates stuff (they really managed to kill the web with the decision to name a completely different framework with the same name)
- Premature abstraction — In practice, using the same codebase for native apps is hardly possible and requires much effort — using the unstable renderer2. Most teams pay the price here but gain no honey.
- Observables over Promises — even a simple AJAX call gets an you an observable.
I see many developers ignore the extra price they just paid, swallow their pride and call toPromise() immediately.
RxJS Observable are anywhere in Angular and learning how to play with them, prevent multi subscriptions, making them hot, cleaning up and learning to use the operators become another stiff learning curve.
- Poor change detection approach: For each async event (user slicked something, some data just arrived, etc), compare each of the bindings (Model-Dom binding) to its old value to decide if to re-render.
- In AngularJS (NG1) It was too slow to carry on >2500 watchers in a page
- In Angular (NG2+) the same problem remains but you have a long tiring workaround: Switch to immutables and spread ChangeDetectionStrategy.onPush all over your app to turn off the default problematic strategy
- Angular core is still dramatically changing (!) in NG4 (to make the fat bundle lighter) the template compilation was completely changed from outputting much generated isomorphic code to a sole data structure used by a super polymorphic code, and it seems that its about to change again soon.
- Typescript only (Its practically impossible to use pure JS) — Typescript is useful if you are developing a library, but it sometimes a bloat for small / medium apps.
I’m a big fan of the team, really, but unfortunately Angular is a sad story.
React is a simple solution for component-based views, nothing more.
There are many ways to do one thing, different APIs, different libs, whenever I’m walking into a react project, I don’t know what to expect and where to go, a mix of UI components and higher-order-components, different ideas and libraries, of wiring, binding and boiler-plating.
Nowadays — many teams are using the black box called create-react-app (even the basic Webpack config is hidden and untouchable), hoping for the best, but finding themselves EJECTING out of the CLI and then starting to make their own way.
Many are using Redux wrong or for the wrong reasons.
People say: React native is a big plus, when I looked into it I was surprised to discover that its not about reusing code of your web app in a clever way by compiling stuff to native, and understood that — names aside, it has nothing to do with React and nothing to do with web-mobile (progressive) applications which is what we are after, now don’t we?
- When coding React-Native you don’t use HTML to render the app, but need to learn and work with alternative components
- React-Native is not made from web elements and can’t be styled in the same way, so go ahead and learn another proprietary styling language
- Goodbye CSS animations, With React-Native, you’ll have to learn a completely new way to animate
React API vs Vue API
Vue.js — on the other hand, is a balanced, handpicked collection of compromises.
- React Higher Order Components is a way to add shared functionality to components, it is cumbersome and a tightly-coupled mechanism;
With Vue, you have Directives, Mixins and Filters at your side.
- For embedding (i.e. transcluding) content inside a component, React developers use props.children
Vue.js has that, but offer its powerful slots: default, named and scoped, which makes building/using Ui components libraries much easier.
- React developers need to contemplate about the binding of this.
Vue auto bind this correctly.
- Whenever a React developer faces a control (e.g. an input such as textbox) he needs to roll up his sleeves and code stupid boilerplate that set the state whenever user enters input
Vue has the v-model directive.
- In React you find yourself collecting many additional libraries and dancing the semver disco,
Vue has built in tools for everyday issues such as events modifiers and scoped styles
- Vue.js has life cycle hooks with good names (-:
Vue.js is the best choice; it has proven itself in large scale production projects and is getting more and more traction. Use it today - and go have a beer.