[danabramov]

We maintain more than 50,000 components at Facebook, and I don’t believe your assessment that “APIs undergoes drastic changes every few months” is accurate. The component API has barely changed since the initial release five years ago.

When we need to make changes, it’s the team of 8 people that need to port all those dozens of thousands of components to new APIs. It would be infeasible for us to break APIs every few months, or to do so in a manual way. This is why we embrace automatic codemod scripts.

There have been some breaking changes between major releases (which have a roughly yearly—not monthly—cadence) but we always provided automatic scripts that convert your code as much of your code as possible automatically: https://github.com/reactjs/react-codemod.

We also call attention to the automated migration scripts in all major release blog posts (for example: https://reactjs.org/blog/2017/09/26/react-v16.0.html#upgradi...).

That’s the only way we could maintain dozens of thousands of components while still moving the library forward.

I hope this information is helpful. You can read more about our commitment to stability without stagnation here: https://reactjs.org/docs/design-principles.html#stability

[hardwaresofton]

I apologize -- I should have written "API internals". I did not mean to state that the component API changed a lot, just seemingly that the internals did, with fiber and the like.

I understand the team is hard at work making React better, and there is absolutely no doubt that you are succeeding and react is getting better. However, the amount of large internal changes indicates that as you improve and (most likely) shed unneeded complexity, that there must have been complexity to shed. Obviously no one is perfect, and hindsight is 20/20, but for such a "small" (yes, interacting with the dom is actually super duper hard, and edgecases abound) scope, I've seen more large-ish overhauls than I am comfortable with.

Many internal changes makes me feel like react is more Mongo than RethinkDB (the latter being a document store that actually got most things right and was well engineered but no one ever heard of while mongo started with a badly engineered product, good marketing, and pivoted to relative reliability and good engineering).

I want to also note that I'm not in the target audience for a post like this. There are tons of people who lovingly and productively use React -- I'm not one of them. I am just dumbfounded when people bill react as simple but have never heard of something like Mithril that actually is simple (almost "stupidly" so), and another post at the top of HN means there's that many more people I have to convince to pick something at least slightly simpler when they start doing web development for the first time.

[brianvaughn]

> However, the amount of large internal changes indicates that as you improve and (most likely) shed unneeded complexity, that there must have been complexity to shed.

The v16 rewrite (dubbed "fiber") wasn't just about cleaning up internals- it was about supporting a fundamentally different type of behavior- asynchronous rendering [1]

> Obviously no one is perfect, and hindsight is 20/20, but for such a "small" (yes, interacting with the dom is actually super duper hard, and edgecases abound) scope, I've seen more large-ish overhauls than I am comfortable with.

To be fair, React supports many more targets than just the DOM. In addition to the DOM- there's react-native, react-art, react-music, react-hardware, etc.

Don't mean to sound argumentative, just wanted to add some info in case there were potential misconceptions. :)

1: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...

[hardwaresofton]

This is a huge point that I do often miss when I think about react when used for react development...

You're absolutely not being argumentative -- while I still don't think react is the simplest thing to start with, the explanations that have been given so far seem very very reasonable, feel like an asshole for essentially ranting

[danabramov]

>just seemingly that the internals did, with fiber and the like.

We‘ve lived with the same codebase for four years and frankly, it was slowing us down. Not all original abstractions aged well because when React was written, we didn’t really have a lot of experience with React :-)

I don’t think it’s because the original code was bad (I’m not familiar with Mongo so I don't know if that’s what you were implying), but because it’s not very easy to come up with an architecture that is both efficient and targets multiple view output targets (e.g. React Native) from the first attempt. Especially considering support for Native was retrofitted into an existing design at some point. It was also pretty much impossible to foresee the kind of features we’d be working on in a few years before anybody used React.

Some fundamental assumptions in the old codebase were actively preventing us from implementing new features. For example, there was an assumption all over the codebase that a custom component always renders one root, but this prevented us from letting people return arrays from render. There were many small things like this, and at some point it was clear we needed to redesign the internals from scratch.

The Fiber rewrite was about unlocking our larger vision (we recently shared its details: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...) but it was just as essential for smaller incremental improvements.

Long-requested features that shipped in React 16 like fragments (returning multiple components from render), error boundaries (gracefully recovering from runtime errors), portals (declaratively rendering the child React tree to a different DOM subtree), and an official context API (finally shipped today) would not be possible without rewriting the internals to an architecture that incorporates our learnings about how React should work that we’ve accumulated over the years.

I’d also argue those features (and then ones we’re working towards—please do watch my demo at the previous link!) are a bit more ambitious than “interacting with the DOM”.

> am just dumbfounded when people bill react as simple but have never heard of something like Mithril that actually is simple

I agree React is not simple internally, but that was never the goal. The goal is to make it simple to build products with React, and so far I believe its success speaks to product developers finding it helpful.

I don’t push for React being used everywhere (and I heard people who used Mithril are happy with it) but I hope this gives some insight into our decision and development process.

We didn’t rewrite React because we wanted to clean a few things up, or because we didn’t know what we were doing. We’re pursuing very specific goals, and a new architecture is essential to enabling them. And there were no multiple rewrites; just one: https://code.facebook.com/posts/1716776591680069/react-16-a-....

[hardwaresofton]

Thanks for explaining so much about the process -- I didn't mean that the code was bad, just that there was an unexpected amount of growth.

But hearing what was being dealt with (those blog posts) definitely clears things up for me -- Also as the other commenter mentioned, react is aiming for so much more than the DOM (react native was a visionary/revolutionary achievement IMO, not even trying to blow smoke, I think at this point that's pretty much a fact) it makes sense why and how react has grown the way it has.

Thanks for taking time to clear up my misunderstanding/where I was wrong