Is it? Google Trends shows about twice the interest for Angular vs React [1], which is not an insignificant difference. Is there strong evidence to indicate that React is 'taking over'?
Isn't it misleading to use 'ReactJs' in google trends ? You won't find 'ReactJs' on React's homepage, but 'React' whereas you'll find 'AngularJs' and 'VueJs' everywhere on their respective home.
Absolutely. The line before 2014 represents the tiny baseline of people using "React" in other contexts. The entirety of the growth since then is the Javascript library.
I'm not sure I wholeheartedly agree with that. The YouTube channel "REACT" could be driving some of these numbers. There's a spike in early 2016 that made me think of it - remember the whole 'REACT' Trademark craze? The Stackoverflow Trends blog post [0] from yesterday is probably more representative.
Try changing the timescale to 3 months or so for react, you get a nearly perfect pulse wave with peaks on weekdays and valleys on the weekends.
The same happens with Javascript, Java and I guess most (popular) programming languages; it might be an imperfect indicator, but one that suggests people are actively searching during their working hours (which I don't think applies to the youtube channel).
It's maybe not perfect, but definitely a lot better than 'Reactjs'. You just have to look at this topic - how many people just say React vs ReactJs. Besides Google seems to know that I'm wanting the JS framework so hopefully its filtering out some of the other unrelated 'React' stuff.
Since your line for "Vue" shows no increase in usage after Vue.js came out, while the line for "React" does, I'm not sure this shows what you think it does.
Vuejs is very good, and I like it a lot more than React. However, it is difficult to see it ever becoming more popular than React, when the latter is evangelized by a large and well-known software company.
I thought the same thing, but later learned that JQuery, built by an independent developer, ended up triumphing over Prototype.js, backed by a larger organization.
How is Vue different from Angular 1? It looks and feels very similar. Granted, I haven't built very large applications but I'm using it in production and I don't really see the benefit while React has a completely different take.
Vue took inspiration from both React and Angular 1. Syntactically, yes, it's quite close to A1, but it makes use of a virtual DOM and components, as React does.
"React is just JavaScript, there is a very small API to learn, just a few functions and how to use them. After that, your JavaScript skills are what make you a better React developer. There are no barriers to entry. A JavaScript developer can become a productive React developer in a few hours."
To me, this is the major driver of React's adoption and thus its success. Angular 1 took me a while to grok because there were so many moving parts. React's API is small and consistent a la JQuery, with the added bonus of being incredibly powerful.
I've never seen someone being productive with react in a few hours, unless we're talking about very basic, static layouts.
Stateful components are still hard to write (but are useful!).
Component lifecycle is not trivial and has many traps.
Newcomers put the craziest things in render(): side effects, etc. JS or even TS has no way to enforce that render should just return a VNode and do nothing else.
Data management is very, very difficult (beginners use props and state interchangeably).
Using higher order components or generally writing reusable components with clean APIs is an art in itself.
Separation of concerns in React is tricky too, as the community like to say "everything is a component" and this again has many traps.
The concept of keys or in general, when a node is reused vs when it's destroyed/recreated is not easily understood by newcomers too. But you HAVE to understand that to do animations, etc.
Also, you're productive if you don't care about performances; Once you do, you will be much slower. shouldComponentUpdate, using immutable updates everywhere, not creating lambdas everywhere on each render (idiomatic react), using virtualized lists, etc.
Let's not pretend React is very easy. It only is fairly easy if you compare it to something extremely bloated like angular.
Thanks for clarifying. Parents comment was a little extreme.
Also you have to include learning the front end ecosystem, webpack, Commons vs the other one, all the transpilation, react architecture which is diff from Js/jquery and even get into the.fluxes.
Productive as in "has produced something." I agree with bulk of what you're saying here, but my point was about barrier to entry, not being good or even great at it.
It's fair to point out, considering that the general attitude towards React is that it's some panacea of simplicity, shining down from atop the mountain upon the unwashed masses. We still need developers in this world. :)
I guess it depends on what you mean by productive. I completed the React official tutorial in less than an hour and started writing a simple app, which then grew to a more complex app. Component lifecycle was trivial to me. There are only five or six lifecycle hooks. I was answering React Stackoverflow questions within a few weeks of starting.
Does React have some gotchas? Yes, but most of the time devs who get caught by those simply haven't read the very short and very good docs.
I've used loads of frameworks in my long programming career and React has been one of the easiest to pick up. Agreed that Angular is a bit of a nightmare. I studied that for months and still feel like a beginner even after building a side project with it.
I argue that React is only difficult because you have to unlearn a lot of bad "tricks". For me the hard part to learn was JS..
I only started JS development because React enables me to build UI software like i always have done, except now in a browser.
React is components 101 for use in browsers.
Flux is business logic 101.
Both (React/Flux) are great for devs that have no prior experience with building normal desktop applications. And ideal for devs that DO have that experience. That is where the (non-early) adoption wave is comming from imho.
Let's not kid ourselves - React is not jquery, by a long stretch. There is a reason why react developers can charge $100hr+ to do things effectively with react.
"Hello world" in react is deceptively easy, that is true.
I cant agree. Angular 1 hooked me right from the start. React had me struggling for weeks. Vuejs on the other hand is a gift from god. I've never been more productive.
One of the big advantages of React is that it's straightforward to unit test your components. Plus there's Jest, which makes a lot of the hard bits of testing much easier.
(I say this as a developer who mostly uses Angular and Vue rather than React. I wish I had the React toolchain in other frameworks.)
Jest uses jsdom. You just need to add it to a project ("npm install --save-dev jest"), write a spec, and then run npm test (maybe update package.json to have 'jest' as the test command). It's really, really easy.
I too spend 90% of my time on the backend (Node.js mostly). But when I do work on the front-end, I feel that I can get the same relative static comfort by using the most hardened API available to me: the DOM.
I get that its pretty verbose and historically has been far from perfect, particularly in the early-to-mid 2000s, but I really have trouble understanding this allergy new devs have to the native web platform. Its not that hard to be productive and you can do so without having a nightmarish preprocessing toolchain. And by bootstrapping yourself to these framework/library ecosystems, you usually don't get a sense of the problems they venture to solve. Everything becomes a magic black box.
As an aside: libraries have never seemed like the true pain point for new FE devs. My anecdotal observation is that the wheels fall of the wagon when it comes to application/API design.
The obvious corollary here of course is that you can easily build a very poorly designed React/Redux app. We're just trading one problem space for another, in my view.
I prefer backend, too, but I found that I had to develop my frontend skills to remain employable. Definitely prefer working on the server side, though.
My perspective is React was always very simple and I use React Native and React so it is easy to transition between them. My focus then becomes on getting actual things done.
> React is just JavaScript, there is a very small API to learn, just a few functions and how to use them. After that, your JavaScript skills are what make you a better React developer. There are no barriers to entry. A JavaScript developer can become a productive React developer in a few hours.
This is a valid point. Maybe not a few hours but it clicks with developers after a few days.
But then there is also the very good documentation and an already big community.
Also Facebook backing it is encouraging for mid-sized companies to use, which don't expect breaking changes any time soon.
> React is a JavaScript library. It’s not a framework.
This is an extension of the UNIX philosophy: do one thing, right. React developers state that "React is the V in the MVP model". React can easily be integrated with any other JS library that is out there. This is very attractive to developers.
Facebook in general seems to be moving in the functional programming direction with tools like GraphQL. React is a functional approach to UI development. It also makes use of the concept of immutable data. The functional programming paradigm has been gaining traction lately and React seems to be riding along with this wave.
As React is functional, simple and makes use of immutable data, it was quickly adopted by the Clojure community. It has two major adaptations, React and Om. I imagine other functional programming groups have gone in a similar direction. This also could be helping propel it along.
Does the unix philosophy require web pack and a complex compiler tool chain to get it to work? Is Compiling one language into another part of the philosophy as well?
>Does the unix philosophy require web pack and a complex compiler tool chain to get it to work? Is Compiling one language into another part of the philosophy as well?
In terms of the GNU system, they usually require autotools, make, gcc and binutils to compile. The code is translated along the way into a binary that matches the local format, such as ELF or Mach-O.
Does Vue allow you to use only javascript like React does? After getting over my initial resistance of using javascript as my "templating language" I am kind of done with frameworks that try to make HTML into a programmable language.
There is rarely a logical reason for why something is taking over front-end development.
Take javascript for example. Let's face it... javascript is a shit language. Why did it take over front end web development? Because of Logic? No. Why did React take over front end web development? Because of Logic? Maybe.
The react + redux ecosystem has major issues that need to be addressed.
Problem #1: complex tool chain.
Problem #2: Forced OOP. Components need to be objects to use this.setState(). Why is this design necessary? See cycle.js.
Problem #3: redux... functional programming / immutable programming is not necessarily the best choice for a Model in any architecture that contains a model (MVC). Try building an app with a complex tree structure for the model then update a node in the middle of that tree and see what immutability does for you... Welcome to the world of Zippers and lenses..
In fact View components should be immutable and the model itself should be mutable... In react + redux it's the other way around!
We can do better. React + redux are not the holy grail.
Just want to mention. Does it make sense for a model in the backend to be immutable? Imagine that... Immuteable mysql... Why does this make sense on the front end? Why? Why? Why?
React came with a nice and small interface that work well with the DOM. It was pretty innovative and solved one of the biggest pain points.
I agree that because it just works on the View, it has been easy for people to adopt it.
The support of Facebook helped to make it shine in the "a new frontend framework a month" reality. Now the great documentation, great articles and great component already built for you make React a very compelling piece of software to use.
At the same time I agree with who says that today if we look only at the simplicity of the interface and performance, there are a few better libraries.
Okay I go ahead and say it: I still like Angular 1.x
I feel like there's a lot of hate towards Angular and much praise for React. Personally I don't get along with the syntax and just the readability of React code or rather the structure. But that may just be my lack of experience with it.
I understand that the DOM diffing in React is superior but.. is it really that important?
For me the two-way data binding of Angular takes away the headaches of doing updates with jQuery. Sure, I get that having to follow the "Angular" way and wrapping foreign libraries is overhead. But it still feels adequately simple to write applications with it.
61 comments
[ 3.4 ms ] story [ 88.9 ms ] thread[1] https://trends.google.com/trends/explore?q=%2Fm%2F0j45p7w,%2...
Granted, by limiting to distributed / remote teams may not be indicative of the whole market.
https://stackoverflow.blog/2017/05/09/introducing-stack-over...
The same happens with Javascript, Java and I guess most (popular) programming languages; it might be an imperfect indicator, but one that suggests people are actively searching during their working hours (which I don't think applies to the youtube channel).
Oh look, `Vue` is contaminated by things like PS Vue, just like `react`.
This company is the exact reason why I want Vue to succeed.
I was hoping for a more indepth analysis of industry trends around different JS UI frameworks.
To me, this is the major driver of React's adoption and thus its success. Angular 1 took me a while to grok because there were so many moving parts. React's API is small and consistent a la JQuery, with the added bonus of being incredibly powerful.
Stateful components are still hard to write (but are useful!).
Component lifecycle is not trivial and has many traps.
Newcomers put the craziest things in render(): side effects, etc. JS or even TS has no way to enforce that render should just return a VNode and do nothing else.
Data management is very, very difficult (beginners use props and state interchangeably).
Using higher order components or generally writing reusable components with clean APIs is an art in itself.
Separation of concerns in React is tricky too, as the community like to say "everything is a component" and this again has many traps.
The concept of keys or in general, when a node is reused vs when it's destroyed/recreated is not easily understood by newcomers too. But you HAVE to understand that to do animations, etc.
Also, you're productive if you don't care about performances; Once you do, you will be much slower. shouldComponentUpdate, using immutable updates everywhere, not creating lambdas everywhere on each render (idiomatic react), using virtualized lists, etc.
Let's not pretend React is very easy. It only is fairly easy if you compare it to something extremely bloated like angular.
Jeff not a few hours.
Just wanted to add some additional infos :p
Does React have some gotchas? Yes, but most of the time devs who get caught by those simply haven't read the very short and very good docs.
I've used loads of frameworks in my long programming career and React has been one of the easiest to pick up. Agreed that Angular is a bit of a nightmare. I studied that for months and still feel like a beginner even after building a side project with it.
I only started JS development because React enables me to build UI software like i always have done, except now in a browser.
React is components 101 for use in browsers. Flux is business logic 101.
Both (React/Flux) are great for devs that have no prior experience with building normal desktop applications. And ideal for devs that DO have that experience. That is where the (non-early) adoption wave is comming from imho.
"Hello world" in react is deceptively easy, that is true.
That's like saying Windows is just C/C# – it's technically somewhat true but over-simplified to the point of being useless.
Things are more static, and more easily automated-testable.
(I say this as a developer who mostly uses Angular and Vue rather than React. I wish I had the React toolchain in other frameworks.)
There's even a repl so you can try it in a browser first - https://facebook.github.io/jest/#use
I get that its pretty verbose and historically has been far from perfect, particularly in the early-to-mid 2000s, but I really have trouble understanding this allergy new devs have to the native web platform. Its not that hard to be productive and you can do so without having a nightmarish preprocessing toolchain. And by bootstrapping yourself to these framework/library ecosystems, you usually don't get a sense of the problems they venture to solve. Everything becomes a magic black box.
As an aside: libraries have never seemed like the true pain point for new FE devs. My anecdotal observation is that the wheels fall of the wagon when it comes to application/API design.
The obvious corollary here of course is that you can easily build a very poorly designed React/Redux app. We're just trading one problem space for another, in my view.
This is a valid point. Maybe not a few hours but it clicks with developers after a few days. But then there is also the very good documentation and an already big community. Also Facebook backing it is encouraging for mid-sized companies to use, which don't expect breaking changes any time soon.
This is an extension of the UNIX philosophy: do one thing, right. React developers state that "React is the V in the MVP model". React can easily be integrated with any other JS library that is out there. This is very attractive to developers.
Facebook in general seems to be moving in the functional programming direction with tools like GraphQL. React is a functional approach to UI development. It also makes use of the concept of immutable data. The functional programming paradigm has been gaining traction lately and React seems to be riding along with this wave.
As React is functional, simple and makes use of immutable data, it was quickly adopted by the Clojure community. It has two major adaptations, React and Om. I imagine other functional programming groups have gone in a similar direction. This also could be helping propel it along.
React is not functional.
In terms of the GNU system, they usually require autotools, make, gcc and binutils to compile. The code is translated along the way into a binary that matches the local format, such as ELF or Mach-O.
Take javascript for example. Let's face it... javascript is a shit language. Why did it take over front end web development? Because of Logic? No. Why did React take over front end web development? Because of Logic? Maybe.
The react + redux ecosystem has major issues that need to be addressed.
Problem #1: complex tool chain.
Problem #2: Forced OOP. Components need to be objects to use this.setState(). Why is this design necessary? See cycle.js.
Problem #3: redux... functional programming / immutable programming is not necessarily the best choice for a Model in any architecture that contains a model (MVC). Try building an app with a complex tree structure for the model then update a node in the middle of that tree and see what immutability does for you... Welcome to the world of Zippers and lenses..
In fact View components should be immutable and the model itself should be mutable... In react + redux it's the other way around!
We can do better. React + redux are not the holy grail.
I agree that because it just works on the View, it has been easy for people to adopt it.
The support of Facebook helped to make it shine in the "a new frontend framework a month" reality. Now the great documentation, great articles and great component already built for you make React a very compelling piece of software to use.
At the same time I agree with who says that today if we look only at the simplicity of the interface and performance, there are a few better libraries.
MarkoJs and Vue for example.
I feel like there's a lot of hate towards Angular and much praise for React. Personally I don't get along with the syntax and just the readability of React code or rather the structure. But that may just be my lack of experience with it.
I understand that the DOM diffing in React is superior but.. is it really that important? For me the two-way data binding of Angular takes away the headaches of doing updates with jQuery. Sure, I get that having to follow the "Angular" way and wrapping foreign libraries is overhead. But it still feels adequately simple to write applications with it.