And that's literally all the justification the author is going to give you. "I _could_ tell you why React is designed poorly, but I won't. Instead, I'll complain about the fact that it's made by a COMPANY. A company that MAKES MONEY. And that's BAD for everyone".
Yeesh. React makes web development way more enjoyable and maintainable to me. Don't tell me THAT web components are better, tell me WHY. Tell me HOW React, which is functional in nature and makes composition and reasoning about view code incredibly easy, is making my app an "unmaintainable hair ball of unreadable code". The author conveniently leaves out actual argumentation.. for the entire article.
I agree with you, I would've loved to see some more arguments, but to play the devil's advocate, he did offer some reasons against react:
JSX wants you to couple your view with the model and controller
I could give you a lot of specifics—separation of concerns, coupling views with models, the focus on needless optimizations, the importance of supporting open standards—but I'm going to tell you a story, instead.
Ok, I agree, he didn't give any reason aside from separation of concerns and company bad, web components good.
This seems untrue in my experience. How is the view in any way coupled to the model since the "model" is simply a plain object passed down from a parent component? How could it be any more decoupled? I'm not even sure what a "controller" is in the context of react, but nothing about react or JSX forces you to couple your logic to the render function, in fact, a react "stateless" component is literally a pure function without any knowledge of state or the wider application.
React breaks away from the traditional MVC model. MVC may work great on the server, but I just don't think MVC fits with modern UIs. Component-based architecture is far more powerful and scalable
If you use react/redux that's a totally incorrect assertion. Views are all dumb and ideally stateless, the model (store) and controller (actions) are completely pluggable at a high level.
While I agree that it would have been nice had he given examples of why React is bad and/or Web Components are better, I don't see anywhere in the post where he suggests React is bad simply because its developed by a for-profit corporation. His argument in that respect is that Facebook has a financial incentive to strengthen their walled garden and, to that end, they promote a custom implementation over web standards. And that is bad for everyone.
There is a more recent post (https://www.pandastrike.com/posts/20160331-facebook-react-pa... - thanks to @suyash for pointing that out!) that clarifies this point and even offers some counter-points to the argument. It doesn't touch on the technical merits of Web Components over React which I would like to see but I have to agree with their overall feeling on the matter.
> React's design is bad. I could give you a lot of specifics—separation of concerns, coupling views with models, the focus on needless optimizations, the importance of supporting open standards—but I'm going to tell you a story, instead.
The "story" is that Flipboard made React Canvas. The author wants me to think that this is bad in some way, but doesn't say how, except that it's tied to React.
But without saying what's bad about React, he hasn't actually conveyed anything bad about React Canvas, either.
In the second half of the article, the author argues that we should prefer Web Components to React, which is like comparing apples to barrels.
> Trying to compare and contrast React with WebComponents inevitably results in specious conclusions, because the two libraries are built to solve different problems. WebComponents provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary; engineers can mix-and-match the technologies. As a developer, you are free to use React in your WebComponents, or to use WebComponents in React, or both.
> The "story" is that Flipboard made React Canvas. The author wants me to think that this is bad in some way, but doesn't say how, except that it's tied to React.
He says Flipboard could've contributed to the core of the browser to add the smooth scrolling feature instead of writing a framework.
> Instead of contributing to various efforts to speed DOM rendering, Flipboard decided to write their own canvas-based rendering engine.
This is a pretty silly article. The author makes no real points. He just seems to dislike React because it's not an open standard, and questions Facebook's motivations in creating it. He alludes to the existence of actual architectural criticisms and then never states them.
The meat of his criticism, to the extent that there is one, is that somehow React's not being a web standard is going to be bad for the open web. Which, if true, would indeed be an important and negative thing. But the author makes literally zero attempt to prove that point, and instead simply says that FB benefits from walled gardens (true, but irrelevant).
As far as I can tell, React is detrimental to FB's direct business interests. It's true that FB is a walled garden, but it's also true that React makes it much easier to create nice web experiences in your own garden, on the open web. So perhaps they have shot themselves in the foot there a bit, but that's alright with me.
I once tried to learn Angular, but failed miserably. The documentation is so awful and the framework is so bloated.
So I gave a chance to React and I liked it first, easier to learn, object-oriented, etc.
But now I found [VueJS](https://vuejs.org/), which is even simpler. You don't need to deal with the painful tooling of React (webpack and a huge number of files in a node_modules folder), it works out-of-the-box. Include the script tag and start coding, this is how things should work! The simpler, the better.
You arrive to vue searching for simplicity and, when you start with Vuejs, you don't even need to download vue, you can use it from a CDN.
Then you want to make a component, so you start typing the html in your javascript (because less is more!). Soon enough, you realize what a mess that is, so you decide to separate your component in the vue.js way.
Then you realize that in order to 'compile' your component you need a preprocessor (webpack for instance). So you want to install webpack, and the sane way for that is npm. So you have to install node in order to install webpack in order to write .vue component files (that, by the way, your IDE doesn't know how to show)
Then you start to think in going back to Angular. Naa, just joking, vue-cli is a good invention (when it works).
Despite everything I said, I think I'm going to stay with Vue.js for a while.
I really would like that Elm was in a more mature state.
Yes, most web apps would be better off using something simpler (like, say, my baby, http://intercoolerjs.org). Yes, facebook has an ambiguous relationship with the web (OTOH, google doesn't and yet they turned out Angular, so...) Yes facebook fanboys and trend followers are piling in and over-applying it.
But there are still jobs for which React (or similar) is the right tool. False dillemas make for good clickbait headlines, but they are no way to think about life.
Author has no idea what he is talking about, gives virtually no real criticisms of React besides just saying "it's bad".
React does not tightly couple model controller and views, in fact, most of the documentation on react is all about de-coupling the view from everything else, and all the model frameworks that sprung up around React are examples of this. Flux, Redux, etc.
The author does not even try to make arguments about what makes React bad and Web components good.
I expected some strong opinions about this backed by performance benchmarks but all the author cares about is saying that React is bad because it is not a web standard and it was made to fight with google for best engineers!
Really, i failed to see it.
We, at AdPushup, chose React for Visual Editor and i can give many reasons as its justification.
- One way data binding flow (Much easier to learn, implement and debug as compared to more traditional two-way data binding, not to mention Cascading MVC updates that decreases your productivity by a fair margin)
- View render is independent of component state
- render() encapsulates component's every possible UI state
- True reusable components, we have been using many of them in our Visual Editor
- ViewModel is nothing but just an object literal that lives in every component, only if needed. So, no View can be more 'decoupled' with its model.
Further, React docs themselves talk about how React can be mix-and-match with Web Components and both of them are built to solve different problems.
An excerpt from this comment section:
In the second half of the article, the author argues that we should prefer Web Components to React, which is like comparing apples to barrels.
> Trying to compare and contrast React with WebComponents inevitably results in specious conclusions, because the two libraries are built to solve different problems. WebComponents provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary; engineers can mix-and-match the technologies. As a developer, you are free to use React in your WebComponents, or to use WebComponents in React, or both.
If you step passed the obvious X is bad mentality, the article makes a great point about React, and that it is only one thing: the React Component. This component is model (state), controller (lifecycle and callback methods), and view (render). This makes proper separation of concerns very hard. React says it's only view, but actual implementations are a full app. There are solutions like Providers and High Order Components, but these are just built on top of the React Component.
Facebook/React's counterargument is that you can't effectively decouple those things, and maybe it doesn't make sense to. Instead of having confusing, leaky abstractions, just let things be coupled when it makes logical sense.
Waiting for web standards, let alone advocating them while you wait is a HORRIBLE business plan, and is a disservice to your users who could be getting a better experience NOW. The history of web standardization alone provides ample proof that nothing is predictable, nothing is as expected, and you shouldn't wait. The fact that React Canvas could be built is a testament to where web standards are now, and that's the end of it.
In fact, it's precisely because developers push the limits of current platforms that standardization bodies get a clue of what is important and what developers want.
Two years ago I would have agreed with the author. However, now I just disagree flat out. I think React actually has it correct. Web Components while useful and a step forward, is not better than React at what it does. Web Components bundles Javascript, CSS and HTML together just like React does. I guess being closer to the "metal" is better in theory. The truth is you are still writing Javascript. I think it's easier for me to read and reason about a .jsx file than it is a Web Components file. Additionally, I don't have to wait for current browsers to support React. Web Components is still a ways off before it is ready for use in production and it doesn't offer up as much or more than React already does. For me that's a problem...
I can't stand this (x is awful) attitude. That's the great thing about choice, use whatever you want. What's the point about being negative? React is not going anywhere and I enjoy using it.
The way to learn and grow is to see people criticize X, often as a way to explain that Y is better. I personally grew a lot by reading criticism of OOP in favor of FP. I don't think just saying "FP is good" would be possible without also explaining why the way I was currently doing things -- OOP -- was causing avoidable problems.
That said, this article doesn't accomplish that. Uninformed/incomplete criticism is not a reason to avoid all criticism.
The author is obviously mislead :-) The reason why React is great is that it allows you to specify a big part of your DOM like a functional programmer would, making much of your code cleaner and more understandable. Especially if you don't program it in Javascript, but for example in Scala.
Now an ecosystem of reusable web components? Not even the link he gives for that is relevant anymore.
> Because Facebook is battling Google for engineers. So you've got a big fight between two companies over which company is the coolest place to work, and both of them are companies that your grandparents love. How are you going to win this fight? One way is to have the hippest Web framework.
And who ends up winning? Web developers everywhere. I don't see why this is a bad thing.
Yes, web developers end up winning. But be honest: web developers already are winning. We're freakin wizards. What we need is to cooperate upon and use standards that can be used by generations after us. React is a patch for profit, not an earnest attempt to make a piece of the web that will be used in more than a few years.
I really liked this line -
"Angular is Google's baseball cap. React is Facebook's."
Most people I meet, who want to learn Angular or React, just want to learn them so that they can say they know these things. They don't even want to know how to make a simple Ajax call in pure javascript. The only time they want to learn pure javascript is when they want to go for interviews! I find it really saddening.
I actually found the tone of the text much more agreeable than a typical 'x is harmful' post. The points it presents about the ideas of Web Components and Shadow DOM being the real meat behind React are fair.
But in truth, React is a ready-made lib that combines a few good ideas into a framework, backed by a large company unlikely to disappear tomorrow. Especially in ecosystems like npm, it hit a sweet spot between productivity, thoughtful design, understandability, and promise of longevity.
Jesus, could I read one evaluation of a JS library without it immediately veering into "oh here the cool kids go again!!" territory? People have different ideas on how to avoid the jQuery jello slime-pile disasters we've built in the past and those ideas are competing. Heaven forbid.
Not being happy with React or Angular, I wrote a very clear and concise solution in Dart (with components as the main idea), I hope someone finds it useful: http://nestui.romansnitko.com/
Based on your condescending tone I'll assume you're a confident expert who can easily point to a true "shining example of web technology" for the benefit of the newbs and the brainwashed.
> React, Bad; Web Components, Good
And that's literally all the justification the author is going to give you. "I _could_ tell you why React is designed poorly, but I won't. Instead, I'll complain about the fact that it's made by a COMPANY. A company that MAKES MONEY. And that's BAD for everyone".
Yeesh. React makes web development way more enjoyable and maintainable to me. Don't tell me THAT web components are better, tell me WHY. Tell me HOW React, which is functional in nature and makes composition and reasoning about view code incredibly easy, is making my app an "unmaintainable hair ball of unreadable code". The author conveniently leaves out actual argumentation.. for the entire article.