Size in JavaScript Frameworks is actually a pretty tricky thing to estimate.
Even nailing down the size of runtimes is unclear. You might go to b...
For further actions, you may consider blocking this person and/or reporting abuse
I have to relay that while the payload size is important, as a converted evangelist to Svelte, I can't pass by a chance to say that my dev satisfaction with Svelte is off the charts. I'm aware that this is totally relative, but I don't care! Dev satisfaction is something that isn't even on the radar these days.
It's not unusual. When I do a performance article often someone points out how ecosystem or DX or jobs are the undervalued thing we are missing. But those are always the most commonly talked about things from my perspective. Performance is something that generally gets shelved for these other priorities which is why it's important to bring awareness.
My feeling is that dev satisfaction in JavaScript is on the radar more these days than it ever has, often at the cost of performance. Which is probably why I sound like a broken record. So much so that we've seen the rise of more developer advocates and DX specialists in companies even.
I think what we have is an abundance of good choices. Svelte is likely a high, but a lot of people are really really satisfied with React, Vue, and other popular options. Sure people can always complain about what they are forced to use because of their jobs, but on the DX side things have only been getting better. I think the challenge is things like SSR are offering new territory and complexity we haven't figured out the best patterns for. But in general we've seen a maturing in the JavaScript ecosystem that has made it more accessible than ever before.
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.
I've done these measurements with $mol-based implementation: todomvc.hyoo.ru/
It uses a radically different approach to build. For example, there is no separation into vendor and application bundles. In addition, styles, scripts and some images fall into a single bundle.
By the way, it would be necessary to add not only the size of JS to the measurements in a good way, but also the size of CSS, since it is no less important and strongly depends on the techniques used in the framework for working with styles. Oh well.
The total bundle of $hyoo_todomvc without minification and with gzip compression weighs 27.6KB. Let's assume that after minification, cutting out styles, images and compressing brotli, this size will be reduced to 21.5KB (online tools failed, and I'm too lazy to start it all locally, but let's take a very conservative estimate). If we throw out the reused code, styles and images, then the remaining pure JS code $hyoo_todomvc after minification and brotli weighs 1.5KB (online tools have coped here). That is, the non-specific code for $hyoo_todomvc is <=20KB.
We get the following picture:
It seems to be a lot. However, the $mol implementation does a bit more than the rest:
Beat me to it. It's also a joy to work with
I wonder how alpineJS does on the todoMVC
Alpine wouldn't be an equivalent comparison. The template in the HTML would require a different way of measuring size.
I did implement Alpine in the JS Frameworks Benchmark and one thing I noticed was the base framework size was about 16kb. It isn't really built for treeshaking (github.com/alpinejs/alpine/discuss...).
I think for Alpine the approach of HTML template is going to limit you to smaller applications any way (intentionally), so assuming the best case I'd picture it similar to Vue except you probably wouldn't go past 40kb.
I appreciate the well written comment.
I have seen "large" projects where the largeness was take up by php and used minimal to none javascript on top of using an overkill framework.
I should have clarified. I meant large JavaScript rendered projects, since that is what we are measuring here.
I should make a TodoMVC for Sleek.
One of the normalizing things I did for this comparison was use Vite to do the build. Riot's SFC format is perfect for the comparison, but I haven't seen a Vite plugin as of yet.