And yes, React is as much a technique for building UI as it is a particular implementation. Learning and using React has also improved the iOS code I write.
I use it at work on a page-by-page basis-- it drastically reduces the mental overhead of class naming, JQuery spaghetti, maintaining the DOM etc. Sometimes I even surprise myself when something "just works" because of React's well-controlled model.
This is Reacts greatest strength and a huge design constraint they had from day one. On the other hand it's a tradeoff and as everyone mentioned not having the whole stack under "one roof" brings a lot of tedious crap.
If you need something to incrementally rewrite parts of your frontend React would probably the best choice. If you need something to start your project on I'd consider other options, Angular 2 and Aurelia for example.
Back in the day, jQuery was amazing because it made selecting and manipulating DOM elements easy. But now, plain JS has mostly caught up to that functionality, to the point that it rarely makes sense to use jQuery over plain JS. I wonder if in a few years the same will be true of much of the functionality in react.
Before with libraries like jQuery every potential action had to perform it's own UI modifications.
As the projects grows you have the same UI element being controlled from many different sections of code. States and state transitions not clearly defined.
With React you set the state and the UI will always match, no matter how the current state was achieved.
The purpose was to get rid of ad-hoc DOM manipulations.
The Flux architecture just takes this a bit further by formally defining who holds onto the state/how it's accessed (stores) and the availible possible state changes (actions).
jQuery was all about selecting a node or node list and then applying manipulations to it.
Never ever have I seen active encouragement of poor programming discipline. You are correct in that's what jQuery was about, but it had no opinion on how to go about that task.
By having the central unit of work start with a query selector is one such influence which I feel implicitly encouraged DOM manipulations.
Taking a look at the original jQuery website on web.archive, this is the introduction to the $() function:
"The functionality of jQuery centers around one central function: $(). Everything in jQuery is based upon this, or uses this in some way. The most basic use of this function is to pass in an expression (usually consisting of CSS or XPath), which then finds all matching elements and remembers them for later use. For example:"
And then goes to show a DOM selection followed by a chained mutation.
That's jQuery's primary job. It isn't DOM manipulation that causes code/architectural issues.
"All" (I'm simplifying) jQuery does is provide mechanisms to select and manipulate DOM. How to organize its usage is an exercise left to the reader, and most readers did it poorly.
It's not jQuery's fault that people wrote shitty code with it. And, in fairness, when Prototype/jQuery/etc. came out, sites were simpler. When people started doing more, if they didn't take control of how they were using jQ/etc., it blew up and made them hate their lives.
At the same time people were doing that, other people were using various organizing principles to tame their jQ/etc. soup, writing tests, and keeping a handle on the sprawl.
You can write shitty code in React, too. It imposes a certain set of conventions that make it harder to want to. Layer on Redux/etc. and it's even harder to want to. Layer on other various conventions and frameworks and you want to even less. But it doesn't stop you--just like jQ didn't stop you from using self-discipline before people smarter than me evolved client-side frameworks to where we are now.
While I wrote my share of jQ soup, I also worked on projects that were flexible, extensible, testable, and clean. The choice is always ours to make.
Of course you can architect those flexible, extensible, testable and clean projects. But straight out of the box you do not get that with jQuery. It requires planning and architecture engineering.
Whereas every React project starts off with those principals.
In other words, the ways people can use jQuery wrong is worse than the ways people can use React wrong.
None of this is related to what I said originally, which is that jQuery doesn't encourage shitty code. jQ's original purpose wasn't to organize developer activity, it was to simplify one tiny portion of it.
> [Good code in jQ] requires planning and architecture engineering.
Precisely what I said.
(That said, if you don't do that with React, you'll still end up with a mess.)
My point about planning and architecture was to contrast it against what I believe React is better at.
Personally I think React is easier to understand. Honestly the vDom is an implementation detail people get stuck on. Pure functions, well defined state owneeship and transition, and so on are the real benefits.
The other main criticism is JSX which is totally optional and mixing implementing with presentation; the "correct" which I believe to be a outdated but still accepted belief that went out of style around Web 2.0. This separation is not required either, you can rewrite render() to pull from any templating engine or whatever. Or use HOF/HOC via the presentation/containener design pattern.
I realize I went off topic but I've been wanting to compiler my thoughts on this.
I like JSX quite a bit as well; IMO creating an artificial separation between presentation and behavior is not a useful way to think about web apps.
Separating data from presentation and behavior is fine, and is a long-standing GUI tradition.
I would say JSX and the separation of presentation / behavior is orthogonal.
JSX is just a Javascript powered embedded SGML-like document.
The combining of presentation and behavior is caused by render() being defined inline with implementation.
You can not use JSX by using ReactDOM directly or a templating library while still keeping render() inlined.
Or you can move render() to another class (or subclassed, or HOC, whatever) and separate the presentation and behavior with or without JSX.
We're moving closer to having real GUIs in the browser (e.g., Java Swing) but that's not a function of the language, but the plumbing around the language. Swing isn't Java, Swing is written in Java.
But again, JS is just a language, that happens to have an interface into a DOM (in some environments). It's not a framework that guides you in how to organize and architect an app.
It's possible to write maintainable, high-performance, complex apps using plain JS. Adding a few simple layers makes it a lot easier, though, and I'd argue that the current crop of client-side frameworks make it easier still. Simple apps == simple code. Complex apps == complex code, regardless of the tools used to create it. Underneath everything, after all, is still just plain JS.
For an app of any reasonable complexity you'll have "architectural overhead" whether or not you're using your architecture or someone else's. That's just a given. (And if you don't, you have more overhead trying to figure out what you were doing.)
More complex build process? Yep, if you're not writing all the code yourself, and you want to distribute a single file, and ES2015 (or other) transpilation, and minification, sure. But you can use all the libraries in question without much of a build process at all, just load 'em all up and use ES5.
Complex build processes are a result of wanting to distribute and write code in a certain way. They're not a requirement.
Redux is very core concept. You'll have to rewrite half of an application, unless you use it from the start. Routing is essential for any serious web site, so you have to implement it one way or another, and not using working libraries looks strange. Same about babel — either use it from the start or rewrite half of code later (or have a mess). Also I think that babel currently the way to process JSX, so unless you avoiding JSX (which would be very strange), you have to use it anyway.
I don't agree, that you can avoid all this stuff, unless you are just learning on throwaway pet projects or willing to reimplement a lot of things which are already have good enough implementation.
A full frontend stack is total overkill for the vast majority of projects that fall under the "open, check, close" use case. So many of the perks of those frontend stacks, such as keeping data in the browser and only reloading certain parts are based on the slow load times of a full frontend stack if you don't do all of those things.
Being able to use pure React both client and server side without anything else is a fairly significant perk.
Redux is something you can implement yourself easily, I never understood the need for a library there.
The good idea of redux is to have a serialisable state which is changed through events. This gives you unidirectional data-flow and the ability to pause/restore your application.
Complete immutability and funneling everything through functions on the other hand often just obscures readability, and, in case you are using immutablejs, gives you terrible performance.
If I want to have purely functional programs I don't use Javascript, but Haskell or something. If I need time-travelling debugging, which I never found very useful when dealing with complex states, I'll implement it by copying my state using serialization.
I also just don't understand statements like these. React is used by very smart engineers at Netflix, Uber, Lyft, Airbnb, etc and a ton of startups. It's well documented by these people that using React has been a productivity boost and they love it.
I know "argument by authority" but come on, you can't just say "React is bad for real apps!!!" when this list[1] exists.
[1] https://github.com/facebook/react/wiki/Sites-Using-React
I think most developers (at least seasoned ones), come to appreciate tools as a solution to the problems that they solve.
There's always going to be a vocal minority that is strongly against whatever has the most hype at any given moment. Their reasoning is probably as varied as the people themselves, and a some of the criticism may be valid, but this is the nature of developer culture.
Having both groups is probably a net positive.
That patent license they have in their project basically means you can only use React as dev in a company if your company does not have patents or noteworthy IP.
Here is the relevant section from the PATENTS file:
if Facebook or any of its subsidiaries or corporate affiliates files a lawsuit alleging patent infringement against you in the first instance, and you respond by filing a patent infringement counterclaim in that lawsuit against that party that is unrelated to the Software, the license granted hereunder will not terminated under section (i) of this paragraph due to such counterclaim.
It is an opinion held by many (many here) that Software Patents bring no value to the community and need to be abolished. I agree with them, and hence I disagree with you. I did not down vote you.
https://mobile.twitter.com/paul_irish/status/754864479460929...
> React becomes counterproductive when developing apps that aren't mere demos.
I have developed big apps in Backbone, moving very the same apps to React and the productivity went up madly. Facebook does develop apps which certainly cannot be considered "mere demos" and you can see them in action, for example Ad Manager for Facebook on iOS (written in React Native). Facebook invests a lot in React development and there is a reason for that - they use it internally intensively.
> It's marketed to developers by billion dollar Facebook, a company historically intent on squashing startups.
This is not an argument at all. I would be really surprised that's the reason for React to exist. Also React is more a way of thinking, the library itself can be replaced if Facebook should enforce it on a successful startup.
> The utility gained by using React's ecosystem is significantly outweighed by its overhead.
This is certainly not my experience. React has very little overhead and from my experience it's pretty easy to grasp the concept for new developers.
I have no idea where does hate for React come from, it's >> just << an open source library and I wonder how people are willing to start flamewars about a few lines of code. If you don't like React, don't use it. There are a few alternatives like Ember, Angular or even Backbone (although I would say Backbone deserves much more hate than React).