> fast is easily left behind when looking for frameworks.

Nah. React, for example, only garnered attention because it said "Look how much faster the virtual DOM is!". We could go on all day.

> People want features, people want compatibility

Yes, but under the assumption that it is already built to be as "fast" as possible. "Fast" is assumed. That's why "faster" is such a great marketing trick, as it tunes people into "Hold up. What I'm currently using actually sucks. I'd better reconsider."

"Fast" is deemed important, but it isn't asked for as it is considered inconceivable that you wouldn't always make things "fast". But with that said, keep in mind that the outside user doesn't know what "fast" is until there is something to compare it with. That is how some products can get away with not being "fast" — until something else comes along to show that it needn't be that way.

▲

timeon 7 days ago | parent | next [-]

Isn't React one of the slower frameworks?

https://krausest.github.io/js-framework-benchmark/current.ht...

	▲	dmix 7 days ago \| parent [-]
		Reactivity as an idea allowed you to manage data and dom/UI updates in a more performant way than the approach prior to React being popular. But React started a movement where frontend teams were isolated from backend teams (who tend to be more conservative and performance minded), tons of the view was needlessly pushed into browser rendering, every paged started using 20 different JSON endpoints that are often polling/pushing adding overhead etc. So by every measure it made the Web slower and more complicated, in exchange for some slightly easier/cohesive design management (that needs changing yearly). The particulars on the vdom framework itself are probably not that important in the grand scheme. Unless it's design encourages doing less of those things (which many newer ones do but React is flexible).

▲

NohatCoder 7 days ago | parent | prev | next [-]

It is only fast compared to a really dumb baseline. But you are right that the story of React being fast was a big part of selling it.

▲

PaulHoule 7 days ago | parent | prev [-]

"Look how quickly it can render the component 50 times!"

▲

tobyhinloopen 7 days ago | parent [-]

"Look, it can render the whole app really quickly every time the user presses a key!"

▲

PaulHoule 7 days ago | parent [-]

That gets into a very interesting question of controlled vs. uncontrolled components.

On one hand I like controlled components because there is a single source of truth for the data (a useState()) somewhere in the app, but you are forced to re-render for each keypress. With uncontrolled components on the other hand, there's the possible anarchy of having state in React and in the actual form.

I really like this library

https://react-hook-form.com/

which has a rational answer to the problems that turn up with uncontrolled forms.

	▲	tobyhinloopen 7 days ago \| parent [-]
		That's neat, thanks for the link!