React Is a Terrible Idea
pandastrike.com
pandastrike.com
> 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.
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.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.
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.
https://facebook.github.io/react/docs/webcomponents.html
> 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.
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.
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.
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.
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.
But.. from what I've read their argument is that the view and viewmodel are coupled by nature, and that it makes sense to do it this way.
Do you have a different viewpoint? Sounds like you do.
- 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.
https://facebook.github.io/react/docs/webcomponents.html
> 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.
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.
Facebook is a member of w3c, as is every other big company, and their rivals. https://www.w3.org/Consortium/Member/List
That said, this article doesn't accomplish that. Uninformed/incomplete criticism is not a reason to avoid all criticism.
Now an ecosystem of reusable web components? Not even the link he gives for that is relevant anymore.
And who ends up winning? Web developers everywhere. I don't see why this is a bad thing.
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.