> I do, however, like this thing called, Svelte.
Svelte is just another one of “those frameworks”, except with a vastly smaller community: https://trends.google.com/trends/explore?geo=US&q=svelte%20i...
I've had a great experience with it recently developing a smart tv app - which are dog slow even with a quad core ARM CPU due to the resolution so I decided to learn Svelte for the project. The big downside is another templating language to learn and as you said, the community is tiny, but the surface area is small enough that it hasn't been a problem regarding tooling or debugging. Pulling in other frameworks into a svelte app is also relatively easy so it can be part of a slow incremental rewrite, although as always it devolves into a webpack/rollup config mess.
Same could be said of React though. React components are literally just plain JavaScript functions which return VDOM nodes that get diffed and applied to the DOM by the runtime library.
The only objective advantage I see to Svelte is it's tiny footprint, which if you really need you can already get by using Preact (3kb vs Svelte's 3.5kb) without having to learn yet-another-completely-arbitrary-templating-language to no benefit.
"[Svelte is a] compiler that knows at build time how things could change in your app, rather than waiting to do the work at run time"
My point being there is a large amount of compile time code transformation at build time. The run time is not so much a framework as a library like libc. In Svelte when you update state there is no virtual dom, dom diffing, fibers, or anything. It would have been compiled into a direct dom update of anything depending on it. It's no longer a Svelte app just vanillajs. There are some details or course but it's a different paradigm than to react or other modern UI frameworks.
With react memoization and pure components, you get very similar benefits.
Sure svelte goes the extra step and removes unnecessary diffing of constant attributes that will never change and other opts. However there are tradeoffs