Why is React is taking over front-end development?
medium.freecodecamp.com
medium.freecodecamp.com
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.
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.
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.
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.
[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.
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.
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.
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.
I was hoping for a more indepth analysis of industry trends around different JS UI frameworks.
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.
That's like saying Windows is just C/C# – it's technically somewhat true but over-simplified to the point of being useless.