[leeoniya]

> number of engineers

can't this be said about any popular framework? "it scales because everyone knows it"

> app size

what specifically makes React scale better with app size than any other properly componentized architecture?

[a13n]

It doesn't scale because everyone knows it. It scales because React by nature isolates business logic into components so that for the most part 100 engineers can simultaneously work on the same product and be confident they aren't breaking stuff. (Or realize they are through merge conflicts)

> "properly componentized"

With React, 100 engineers don't have to know how to "properly componentize" things because it's already baked into the framework. You can't really write React code without proper componentization.

[leeoniya]

> React by nature isolates business logic into components

The essence is simply this:

    function MyView(model) {
      return template;
    }

...which can work with any view layer and the same 100 engineers. Especially if the model is an API with business logic around some immutable stream/state. The concept is simple enough to be described in one sentance :)

> don't have to know how to "properly componentize" things

I think you're overstating how difficult this problem is or forgetting that React's API must still be learned from documentation and examples.

[a13n]

What about state within a component? How do you encapsulate that state so that other components can't muck with it? What about passing data to that component? What about type checking that data passed in in debug mode? What about a formal API for components to talk to one another? What about knowing the explicit amount of the view tree that needs to be re-rendered based on what data changed?

React has answers to all these questions and so much more. Answers that very smart people have spent years coming up with.

Sure you could reinvent the wheel and build all that into your custom component framework, but then you may as well just use React.

[leeoniya]

I will address these with respect to domvm [1]

> What about state within a component? How do you encapsulate that state so that other components can't muck with it?

Solved.

> What about passing data to that component?

Solved.

> What about type checking that data passed in in debug mode?

Could be solved if i rewrote in TypeScript. But this has never been a problematic issue in 10k+ LOC apps.

> What about a formal API for components to talk to one another?

Yep.

> What about knowing the explicit amount of the view tree that needs to be re-rendered based on what data changed?

Obviously, that's what virtual dom is.

In addition to all of this and much more, materialized views are independently refreshable, can be composed between disjoint components. There are async lifecycle hooks, a router, mutation observers, ajax sugar.

All of it is 17k min, requires no special tooling or IDE to write, is isomorphic and is 2-3x faster than React.

I have no doubt that React brings a lot to the table, but I hesitate to treat it as the final word in frontend frameworks for all the above reasons.

[1] https://github.com/leeoniya/domvm