> Components are marginally larger in solid, and much larger in svelte.
That doesn't sound right. Components are usually much smaller in Svelte, both source and compiled output; if you have hydration enabled, the JS only contains code needed to hot-patch the DOM, and not rebuild the entire template including all the static parts as react/solid does.
When Svelte still called itself the "disappearing framework", the trade-off was larger overhead in the overall project due to repeated code, but in later versions Svelte ships a runtime with a shared library.
> we all seem to be in agreement that excessive rerenders are the leading cause of poor performance, and reactive frameworks are the solution
When we were hand-wiring components in Backbone, knockout.js etc, rendering was extremely optimized, since you decided on each and every action that would trigger it, and you did not want to overwrite potentially stateful DOM elements unless really needed.
It was way easier to get stuck into infinite loops, get desync issues, or simply completely loose track of chains of events, but unnecessary re-renders were not a major issue because they were much more expensive. React offered a solution to reason about the component tree more clearly, and along with flux and the unidirectional data flow, eliminate issues around stale data and mutations. It was not meant to be faster.
That doesn't sound right. Components are usually much smaller in Svelte, both source and compiled output; if you have hydration enabled, the JS only contains code needed to hot-patch the DOM, and not rebuild the entire template including all the static parts as react/solid does.
When Svelte still called itself the "disappearing framework", the trade-off was larger overhead in the overall project due to repeated code, but in later versions Svelte ships a runtime with a shared library.
> we all seem to be in agreement that excessive rerenders are the leading cause of poor performance, and reactive frameworks are the solution
When we were hand-wiring components in Backbone, knockout.js etc, rendering was extremely optimized, since you decided on each and every action that would trigger it, and you did not want to overwrite potentially stateful DOM elements unless really needed.
It was way easier to get stuck into infinite loops, get desync issues, or simply completely loose track of chains of events, but unnecessary re-renders were not a major issue because they were much more expensive. React offered a solution to reason about the component tree more clearly, and along with flux and the unidirectional data flow, eliminate issues around stale data and mutations. It was not meant to be faster.