The question is. Is such a small application a good way to measure how such frameworks perform for such comparison? In many many cases the actual differences starts to grow at large scale. When there is a lot more envolved than a few lines of code.
Not in the sense that compression works better with bigger chunks so this might be a bit conservatively pessimistic on component code size. However this applies to all.
TodoMVC is also fairly dense which is good for this and fairly uniform. Most larger uniform demos like HackerNews or Realworld demo have alot more static view code which emphasizes this more. If I recall the component code for each page in Solid's HN demo is almost half the size of Svelte for example. These examples of course are less uniform making more work to compare.
They also pull in data fetching and routing. Which effectively grow the vendor chunk. This is even more variable. I know the analysis under represents this additional library code which is why I think we should be targetting smaller component sizes to reach budgets.
Finally if the hope were to look at real sites in the wild. In a sense that would be best but the sample size would need to be enormous and need to figure out how to be representative not to be unfair to more popular frameworks used in less optimal ways.
Basically like with any microbenchmark this has limitations but artificially forces to the surface a measurable trend.
Yes exactly, well answered.
I am coming from the background of building large enterprise apps and I know large apps are different. The current app I am building right now is around 100k loc and has over 200 screens, the JS bundle over the wire jziped is still under 900kb which great. I am not yet in the area where I need to think of code splitting.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The question is. Is such a small application a good way to measure how such frameworks perform for such comparison? In many many cases the actual differences starts to grow at large scale. When there is a lot more envolved than a few lines of code.
Not in the sense that compression works better with bigger chunks so this might be a bit conservatively pessimistic on component code size. However this applies to all.
TodoMVC is also fairly dense which is good for this and fairly uniform. Most larger uniform demos like HackerNews or Realworld demo have alot more static view code which emphasizes this more. If I recall the component code for each page in Solid's HN demo is almost half the size of Svelte for example. These examples of course are less uniform making more work to compare.
They also pull in data fetching and routing. Which effectively grow the vendor chunk. This is even more variable. I know the analysis under represents this additional library code which is why I think we should be targetting smaller component sizes to reach budgets.
Finally if the hope were to look at real sites in the wild. In a sense that would be best but the sample size would need to be enormous and need to figure out how to be representative not to be unfair to more popular frameworks used in less optimal ways.
Basically like with any microbenchmark this has limitations but artificially forces to the surface a measurable trend.
Yes exactly, well answered.
I am coming from the background of building large enterprise apps and I know large apps are different. The current app I am building right now is around 100k loc and has over 200 screens, the JS bundle over the wire jziped is still under 900kb which great. I am not yet in the area where I need to think of code splitting.