svelte-it-will-scale VS solid

Compiled code logic redundancy. Some readers may worry that if the complexity of the business logic, resulting in a straight line increase in the size of the code file after compilation, whether it will lead to a certain degree of performance degradation?Github on the relevant developers for this problem to analyze svelte-it-will-scale:

That N is very large. E.g. here's a page that talks about it: https://github.com/halfnelson/svelte-it-will-scale. I'll note that was done with Svelte 3 and that with Svelte 4 components are at least 10% smaller, so it's actually even better than that. SvelteKit is also very efficient at JS splitting per-route thanks to Vite. It ensures only the JS that is necessary for a page is loaded and you're extremely unlikely to be using anywhere near that many components. Based on the article above, you'd have to have three entire sites worth of components on a single page.

Sure, performance (bundle size), performance/predictability, simplicity (blog post)

Finding Svelte's Inflection Point

yes am aware, but also in any realistic scenario, code splitting comes in well before the crossover point where that even remotely comes into question. this has been independently verified twice now:

https://twitter.com/sveltesociety/status/1301168598988107776...

https://svelte-scaling.acmion.com/

https://github.com/halfnelson/svelte-it-will-scale

sveltekit has further opportunities for whole-app optimization but honestly given this research i lost interest bc its more than good enough

Svelte lowers the initial size of your app, however the incremental cost of each component creates an inflection point, where the added size of each component exceeds the size of a pre-bundled framework. What actually matters is where this inflection point is. This experiment actually evaluates that https://github.com/halfnelson/svelte-it-will-scale. Essentially, you would need a project equivalent to four times the size of the svelte.dev website to reach this point.

Naturally, the first thing I want to do is put these to the test, but it would be anecdotal at best. The first thing that came to mind was the comparison of Svelte Component Scaling compared to React. Some sort of test to see how much difference a small library that ignored all this compared to a large library that didn't.

The strength of V-DOM definitely doesn't lay in performance. It made it easier for developers to write more maintainable interactive UI. Other than that I'd rather think of it as a compromise. Fortunately, frontend web dev continuously progresses and there are initiatives like https://github.com/ryansolid/solid which focus on compilation-time diffing.

You see I work 12 hours a day. 8 hours of that is my professional job where I am a developer on the Marko core team at eBay. Then after some much-needed time with my family, my second job starts where I am core maintainer of the under-the-radar hot new reactive framework Solid.

They’ve been well received, and the core ideas behind them have inspired the likes of Vue’s Composition API and a big part of Solid’s API.

After discovering solid js, I wondered how feasible it would be to write such a framework in Rust. After two days of hacking around, here is the result!

After discovering solid js, I wondered how feasible it would be to write such a framework in Rust. After two days of hacking around, here is the result!

Solidjs UI library uses Proxies in order to make state reactive https://github.com/ryansolid/solid

[0] https://github.com/ryansolid/solid#the-gist

The key thing to understand though is this is not a React-only approach. I make heavy use of this pattern in my Solid projects as it makes a really nice isomorphic solution and works really well with the next topic...

The main ones that I'm referring to have proxy implementations along with their basic signal atoms. MobX's `observable`, Vue's `reactive`, Solid's `state` all are reactive proxies that properly handle subscriptions.