[Kequc]

It gives you components. If your webpage is loaded and significantly complex with a need for different things all over the place then it's for you. It was built for Facebook, which has stuff everywhere on every page.

If all you want is a normal webpage, like a blog, like all of the websites out there I'd say you do not need components. Just build your own object. That is a lot of stuff just to do something that has been done for decades without it, battle tested so to say. Another one of the problems with the JavaScript community currently is the number of people who treat their favourite tool like a religious experience.

React is a large hammer being used quite often to close a twist tie. The ecosystem of tools which have sprung up around it is far worse than React itself. Each one a larger amount of overkill than the last.

[Ambroos]

I'm sorry, but once you feel comfortable using React there are very few things that React would not be a good fit for, however small the task.

I started coding in JavaScript two years ago, right at the point React was gaining popularity. I made a gamble going for it 100%, and since then both the company I was working at back then and the one I started working at recently have fully switched to React for all new front-end development after seeing how much easier it is than anything they'd ever used before (jQuery, self-rolled prototype-based things, Backbone, Angular 1, Ember).

Yes, sure, you have to get the basics set up every time, and yes, sure you have to package React on every page. But as a gigantic win, you get a uniform way of dealing with the DOM every single time. React has well-defined best practices by now. When every Javascript coder in your workplace is familiar with React, it's usually best for you and for them to simply continue coding in React.

[Kequc]

I feel that you are marginalising the amount of complexity you are adding to projects which might not need it. There are multiple routes toward completing the same task in development. My concerns surrounding additional complexity I feel are well founded, there are costs associated with such a thing.

If all you are doing is DOM manipulation, without doing a huge amount of it, that isn't such a complex task that it should require an entire framework. If you're doing more than that it outscopes what React can do.

[Ambroos]

That's just it. If all your developers are familiar with at least the basics of React and Webpack, you aren't adding any complexity. Once you know how things work, a simple Webpack configuration with Babel and 2 presets isn't complex anymore.

What would be complex, however, is introducing DOM logic in yet another way. We're all used how you just define the desired state in React and letting it figure out the transitions. When you suddenly ask your developers to write code that manually manipulates the DOM and has to take care of all the transitions between states, you end up with complex, unclear code that takes everyone a long time to understand.

[Kequc]

Webpack alone requires hundreds of dependencies. You are populating your node_modules directory with megabytes of code, any of which could stop working. If you plan to maintain your code for years into infinity then it's no problem. Otherwise the shop down the street doing the same thing without it will be much better off.

[FrancoDiaz]

React in itself is simple, but familiar with and comfortable with the complexity of Webpack is another story ;)

Ok, I guess Webpack isn't too complex, but its weird syntax (the whole right to left chaining) and poor documentation can be a barrier.

[callumlocke]

> the amount of complexity you are adding to projects which might not need it

If 80% of your projects are written in X, it's probably simpler to just use X for everything, even things that don't need it