I do agree with you about ReactJS - I think it's effectively a tax Facebook imposes on startup web development - but the same cannot really be said about ReactNative which is a relatively okay cross-platform UI toolkit that happens to have the same API as ReactJS.
After being initially excited about the idea of React, I have been working on several teams doing React-based web development. My eventual conclusion is very simple: the overall amount work that goes into developing web apps has increased compared to vanilla HTML/CSS/JS. Performance is abysmal, and as is the case with many frameworks, you're soon reaching a point where your people spend more time (and in the end: computing resources) tricking the framework into doing what they want it to do. I would say the component philosophy of React does offer some organizational benefits, especially for working in a team, but it's nothing that couldn't be replicated by simply introducing coding conventions.
In the end, I do believe Facebook - as a company that can't really move fast anymore (and doesn't have to) - knows this imposes the same restriction on smaller companies by taking away their agility and maxing out developer resources for work on what used to be trivial stuff. Rationally, from Facebook's perspective, React has to serve two functions: priming and funnelling programmers into their enterprise, and suppressing development efficiency elsewhere. It's positioned very well to achieve both.
This has to be one of the strangest conspiracy theories I've ever heard. If other shops felt the same way you did about React - that it was an evil master plot by Facebook to sap all of our productivity and competitiveness - they just wouldn't use it. There's plenty of other options.
The fact that it continues to enjoy high popularity despite being designed, as you seem to think, as a tech debt Trojan horse.... maybe you have to consider all those other companies out there know something about the folly of developing apps with "vanilla HTML/CSS/JS" that you don't.
That's not really what I was trying to say. I think it's perfectly well designed to suit Facebook's internal needs. And it's also guaranteed to drain resources from startup developers. Intent is not necessary, it's just what happened.
> If other shops felt the same way you did about React [...] about the folly of developing apps with "vanilla HTML/CSS/JS" that you don't
I'm fairly confident that almost nobody shares this opinion, so personal attacks on my competency are expected, yes. The problem with all tech fads is that support for them is absolutely ardent, until the pendulum swings in the other direction.
It was unwise to post an unpopular opinion and I accept people's judgement that it was a net detriment to the discussion. But I posted it and now it's out there. If it's any consolation, I wouldn't do it again.
It's amazing how much productivity is draining out of my team when we are waiting fractions of a second for a component to hot reload. I want to go back to vanilla full page re-renders immediately /s
The idea that big companies keep throwing out new technologies to keep little companies churning, even if it didn't exist when Joel wrote about it, could have been adopted after. Of course, some of his calls were wrong in that article, but that's a different discussion.
That's weird considering I've heard a lot praise for React in how quickly it makes developers iterate and ship. Granted React is easy to mess up in a larger scale, but most of the time I feel like it's the engineer's faults for not researching the implications of their dependencies and code or knowing how to profile/debug well.
I know that sounds like a copout, but it's just my personal experience. We just rewrote a slow React app some person that didn't know what he was doing did at work and it's fast and fine now.
> My eventual conclusion is very simple: the overall amount work that goes into developing web apps has increased compared to vanilla HTML/CSS/JS
Not true. Application complexity has increased over time for the web, that is the effect you are perceiving. React actually helps cut through that complexity like a hot knife through butter.
> Performance is abysmal,
The above response applies here as well. What performance are you talking about specifically? There are a ton of large scale, production applications that are running React ...
> and as is the case with many frameworks, you're soon reaching a point where your people spend more time (and in the end: computing resources) tricking the framework into doing what they want it to do.
React is not a framework, it is a very basic view library. There are literally only seven public API endpoints that developers use:
* componentWillMount
* componentDidMount
* componentWillReceiveProps
* shouldComponentUpdate
* componentWillUpdate
* componentDidUpdate
* componentWillUnmount
That's it, that's all you have to learn, the rest is generating markup and learning about setting properties and state within a component. The only exception that I will admit is that integrating react with d3 is awkward.
Having built large web applications before React came along, there is a very good reason why it is so popular and that is because it moves the focus from dealing with transitions between states and simply dealing with the state as if we were building the app from scratch.
Amount of work going in a webapp has increased because they are doing more. A new tech becomes very popular when it solves some pain points felt by most developers, after usage its own pain points may emerge or tech may advance to allow more complex/diff solution.
People facing problems with regular JS/HTML are looking for React or other solutions. Just a hip factor can't justify its popularity.
if you are getting poor performance, you are almost certainly doing something incorrectly. I'm sure someone here will have suggestions if you share more details.
