[sbergot]

Because you sometimes want to filter, sort or project your data. Then you have to handle this in viewmodels or invent more and more features for the templating language. Then you want to refactor into components. So you need facilities for invoking subcomponents. Maybe you want something recursive to display tree-like data.

So you end up with a secondary full featured language usually with worse IDE support, worse error messages, more surprising issues, etc. You need to understand the scoping mecanisms and if things go wrong hope there is a debug tool available.

And in the end those templating languages do not prevent you from mixing UI responsibilities from the rest of your code.

If you want a reactive model you can have one. I personally prefer explicit messages like calling setState.

[shrew]

> Because you sometimes want to filter, sort or project your data.

The idea that this type of thing should be happening anywhere near the view rendering loop is the exact reason I've not had a great time picking up React codebases.

By the time you're rendering data into markup, the data should be in the exact state you need it. No further filtering or data mangling or sorting. That type of data manipulation should happen at the point of data change and then it shouldn't happen again until the data changes again.

The simplistic templating languages in Vue/Svelte/Alpine/whatever-comes-next force you to pull your data manipulation back to somewhere more appropriate, with Vue even throwing a warning if you try to filter within v-for construct.

Because React is JS, people are let loose to do wildly inefficient operations and do them over and over and over whenever _anything_ in that component changes.

[code_runner]

I love vue’s concept of computeds. It makes me think back to knockoutjs when things felt like they “just worked” as long as you knew where the ES5 footguns were.

It’s nice to have a concept “ground truth” in data and props and then computeds that sort of tie it all together.

[shrew]

My feelings exactly, it makes for a satisfying separation of concerns, and if you understand what's going on under the hood it makes for cleaner templates and more obvious component code.

[gedy]

Yes, and those are available as well with MobX (in React), Svelte, etc.

You can do same/similar with React hooks, just not as clean or obvious.

[shrew]

You can 100% do these things in React, I don't believe React is a less able framework by any means. If anything it gives you a powerful toolbox and pulls down the guard rails.

I do, however, think that working with React changes your mental model somewhat, and when I'm working with React I catch myself doing a lot more data wrangling close or in the rendering loop than I would in any other modern framework. Certainly since class components have fallen out of favour, you're working with a function designed to be run hundreds of times, while Vue and Svelte both provide clear patterns to deal with data at the point of change, then separately deal with updating the display of that data as required.

It takes using something like MobX to really push a React codebase to a data-driven model and that means many inexperienced developers fall into the common pitfalls far more easily than if they're using an alternative framework imo.

[pier25]

Exactly. The whole paradigm of reactive data binding is that data dictates what the UI should render. Don't solve your data needs when rendering ffs.

[chriswarbo]

> So you end up with a secondary full featured language usually with worse IDE support, worse error messages, more surprising issues, etc.

Gilad Bracha calls these "shadow worlds" https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.htm...

[tjchear]

Haven't used solidjs before, but I paid the doc section a quick visit and saw that it's basically <For each={foobar}> where foobar can be whatever javascript code you want. So you can certainly do filter/sort/project on your data before rendering.

[Aeolun]

You’d probably not want to project inside that loop though, but before it, in a reactive effect.