3 ms·

Just because you can do something doesn't mean that it makes sense to, or that it's idiomatic to do it. The use case of bringing in a single 3rd party React com

by lhorie 6y ago

Just because you can do something doesn't mean that it makes sense to, or that it's idiomatic to do it. The use case of bringing in a single 3rd party React component into an Angular app is far into edge case territory. Realistically, you would never consider doing it unless there was absolutely no Angular-only alternative in any way, shape or form. FWIW, it _is_ also possible to render Angular code inside of React [1] (but again, this falls well into non-idiomatic territory for both Angular and React) Idiomatically, React is the only thing dealing w/ DOM in an app, and the way it's used is rather frameworky ("don't call us, we'll call you"). And when it's used that way - which is the vast majority of the time - the used idioms do vary heavily depending on when the code was written. Tying this back to what I mentioned about postgres: _within_ a React codebase, you need to be aware of the _semantics_ of the system: performance is achieved through reasoning about the semantics of things like shouldComponentUpdate/memo and even object identity, one needs to understand the semantics of stale closures and useCallback, etc. This is similar to having to understand the semantics of how various ORM idioms translate to underlying SQL queries. By comparison, the cost of any given jQuery idiom tends to correlate more directly with the underlying semantics, just as the cost of a raw SQL query does - i.e. it's pretty obvious without context how expensive `$('html').html(html)` is, just as it's more obvious what is the performance profile of a CTE vs a subquery, in comparison to whatever the high-level ORM idiom is (assuming, of course, that you know SQL) [1] https://medium.com/@balramchavan/integrate-import-angular-v6-component-s-inside-react-js-applications-da5cc03107b4 https://medium.com/@balramchavan/integrate-import-angular-v6...

strogonoff 6y ago
> "don't call us, we'll call you" I don't think with React as distributed (and per tutorial) you can avoid writing that first render() call, so no, “you call us” in this case. The existence of third-party skeletons and templates that impose some structure or another and pre-write the initial render() call isn't making React a framework. It's a feature, of course: being mostly on the library end of the spectrum opens up innovative uses of the efficient rendering. A framework by definition is narrow about what one can achieve without fighting it, otherwise (as I have to agree with TFA) its developers would drown in features and complexity. As to running Angular in React, I stand corrected, last time I built on Angular when it was at version 5. I stand by the rest of my argument, though.
qeternity 6y ago
The same holds true for Postgres: idiomatically, it’s the data store and thus comes with its own set of instructions. I’m not really sure what you’re arguing here. Redis gets even worse: here are a few datasets we support, now go architect your use cases around them. Of course, none of these reasons make them bad tools. Quote the contrary. We are about to ship a react + postgres + redis product. They all work great together for the very fact that like good libraries, we can borrow from each where they are needed. Just because idiomatically React is the only thing interacting with the DOM isn’t an indictment...it just means React is really good at that and most people would rather use it exclusively for DOM manipulation. The same way that Postgres is often the only data store, not because it forces it upon you, but because it’s really really good at it.

by lhorie 6y ago

strogonoff 6y ago

> "don't call us, we'll call you" I don't think with React as distributed (and per tutorial) you can avoid writing that first render() call, so no, “you call us” in this case. The existence of third-party skeletons and templates that impose some structure or another and pre-write the initial render() call isn't making React a framework. It's a feature, of course: being mostly on the library end of the spectrum opens up innovative uses of the efficient rendering. A framework by definition is narrow about what one can achieve without fighting it, otherwise (as I have to agree with TFA) its developers would drown in features and complexity. As to running Angular in React, I stand corrected, last time I built on Angular when it was at version 5. I stand by the rest of my argument, though.

qeternity 6y ago

The same holds true for Postgres: idiomatically, it’s the data store and thus comes with its own set of instructions. I’m not really sure what you’re arguing here. Redis gets even worse: here are a few datasets we support, now go architect your use cases around them. Of course, none of these reasons make them bad tools. Quote the contrary. We are about to ship a react + postgres + redis product. They all work great together for the very fact that like good libraries, we can borrow from each where they are needed. Just because idiomatically React is the only thing interacting with the DOM isn’t an indictment...it just means React is really good at that and most people would rather use it exclusively for DOM manipulation. The same way that Postgres is often the only data store, not because it forces it upon you, but because it’s really really good at it.