I think the take-home lesson from this is that LLMs produce bad code and, while you might get something that works well enough if that's all you need, if you're actually writing a benchmark that's supposed to measure optimal performance, getting an LLM to generate the code is pretty stupid...
@ nah! I didn’t request anything. All I do just want to express my thought on it. I don’t give a damm thing if he likes vue or not, just don’t like the way he tryna ignore Vue in the game even he knows Vue also was also falsely benchmarked initially but never talk, and that’s it. And it’s not just me, let’s look at other comments. Thanks
@@justafreak15able why you assuming something about people you do not know? You do not know, how we will react. If Vue is legit, all props to you and Evan You :) It is just happened that people got a liking to a different things, than you, which is totally normal btw. :) If you like Vue, what do I care? Good for you :) There are many jobs for Vue, so it is good opportunity for YOU!
@imbk feels that way which is odd since it is definitely used quite a bit especially in bigger companies and governments. Not gonna say I particularly like it but I have had to work with it quite a bit over the years
@@jatinkumar7287 read the room and the title. 😄 he's a react developer and has dabbled in a few other things. Vue not being on of those things isn't a travesty. i get wanting Vue to get more of a shine, but you're looking in the wrong places.
Why does everyone say Theo ignores Vue? I guess they are just babbling without watching the entire video clip. Shame on them. 11:26 He said "Vue aws surprisingly fast..." 14:54 "But it's also crazy that Vue with similar capabilities is able to be so close to Fastify".
The react base component is generating a list of react nodes without adding a key to each element forcing an entire tree swap for the component in each re-render no?
@@BurgerBurglar8964Theo defends React with all excuses possible "oh, but look, it's'just' half of the performance" meanwhile the only comment he does about Vue is "Vue looks good". I don't dislike him for that, but I found this funny. Maybe he's too deep in the rabbit hole.
True. In the end Solid is the only implementation taking the hit for generating extra attribute. In some ways that is fair because of our hydration method. But without it we are out significantly ahead of even fastify.
@@ryansolid I think if u read the blog post it talk about this problem of solid, but they go ahead with this cause they wanted something same base line or whatever for every framework. Im just amazed Vue on top and theo reaction to it they doing great and move on.
@jatinkumar7287 Which is also fair. But it does put into question what is being shown unless that is that every tool can be faster than it is today if they put in the time to address it. Fastify as the baseline approach(which doesn't hydrate) isn't actually the baseline. And the room for most frameworks to improve is still measurable.
@@jatinkumar7287 I read it, I just don't find this convincing enough. Feature parity makes more sense than testing the "normal operation of the framework" because the framework can do something that is very convenient but at the same time very expensive in the baseline. But if you wanted the same speed than fastify without that feature, removing it opt-in would be a thing you would already have in mind when chosing the technollogy. You can clearly see it by thinking about it this way: If you remove something that do matter and will make the features of solidjs less than the features of fastify, it would be very easy to just use it as an argument and say that "solid is only as fast or faster if we remove something that makes it good", but in the case of removing hydration it appears to not put it below fastify in any way, so the only perspective that benefits itself on not using that benchmark is fastify. Of course, you can also argue that we should prioritize the "out of the box experience" in that benchmark, which would be fair, but from the article this did not appear to be their intent.
This is such a goofball thing to measure. I love it. I think what I really learned is that LLMs can and will lead you down the wrong path and that it's really easy to deliver poorly optimized code in Node.
The same happens with Deno, the creators of Deno are obsessed with performance but seeing that even with their version 2.0 Bun continues to surpass them they prefer not to include it in their comparisons on their website. "Let's pretend that they don't exist"
@SilasDuarte-e9k that's how all benchmarks are because it's good for marketing. there is a faster runtime than bun called just-js. web frameworks do the same thing. they show comparisons across different languages and intentionally leave out faster languages or faster frameworks in other languages.
I'm always impressed with Vue's performance numbers in these shootouts (once the testing is fixed). Performance isn't one of those things they tout very much unless they make some significant performance update (Vue 3.5), you just get it for free. It isn't always first place, but it's always middle-top of the pack, which is reassuring that the only one who's going to slow my code down is me.
@@hasnatjamil1101 As I remember, I never wrote Angular, but I feel that I dislike it :) It is just because :) Everybody talks shit about it, so I got influenced. Because writing classes is not fun. Unless you are doing it with Primagen. With him classes feels NATURAL, like for real, he is an expert!
why tf you are always ignoring anything related to Vue? vue creator was tweeting about it nuxt core team was involved there was a PR in the benchmark repo what else needs to happen to simply cover it the same way as you cover others?
@@naughtiousmaximus7853 I mean, we just sadly got to accept that Theo isn't some kind of tech reporter with some oath to treat each and every technology equal. If they don't have any interest in Vue, then why would they talk about it? Besides, Vue is great, don't get me wrong, but it isn't going to get any clicks since it isn't trendy anymore so the value here is little. What I can see here is just the fact that he has been more personally involved with the people behind these frameworks and that's why he likes to cover them, which is probably not the same for Vue. Nothing to do with Vercel or whatever
@@javierflores09 It's not about making content about it. It's about not deliberately ignoring it, if it's somehow related to the things Theo wants to make content about, like in this case, he entirely ignored that the initial score was wrong for Vue too.
@@bartek.igielski "deliberately ignore" is a rather harsh assumption to make. It could just be that he didn't see the initial rebuttal tweet from the Vue people like he had seen the others, that isn't ignoring but just not being aware of it. Sure, you could argue that Theo could've gone "if React and Solid guys said this then Vue's one must have been flawed too" and go on a crusade to find the flaws on the Vue benchmark, however as I said earlier, it isn't like he is a tech reporter so he has no obligation to do that, and I certainly wouldn't if I took no interest in the framework. Vue has rebutted their place in the benchmark as it should have and now the misconception is gone for the people who have seen the corrected benchmark. I am aware it can be frustrating that an influencer you follow doesn't do coverage of the framework but truth to be told, it isn't necessary anyway, with the amount of people that have pointed their fingers towards that benchmark, it wouldn't cause a dent to Vue's reputation in any sort of way as people are already dubious of all the results
Any framework that cooks its benchmarks like this is an immediate, giant, blaring red siren for me. Sketchy as fuck. You can't blame AI for that either. Any dev worth their salt reviewing those benchmarks is going to know the difference instantly. It's intentional.
To be fair I feel like we overuse JavaScript today to essentially spit out pretty basic html. There are of course situations where it makes sense but most of the time we should not be generating static html. It should just be served as is already. I'm not sure when writing basic html and css became such a naughty dirty thing.
What's really quick, is the speed at which a dev gets himself egg on the face by posting a half-assed test. You guys are really tolerant ; it's nice to see, because the damage could've been real. I'm sure Matteo learned his lesson ; benchmarking is more subtle than it seems.
I think the way they handled being wrong is great. One thing though is that what the produced at first showcases the potential for letting AI write code.
It's not that SSR performance doesn't matter. But you can scale always scale when your problem is server side. When your problem is client side your only solution is to optimize the code. We better see some real life examples thast would include all loading time to compare better.
On garbage-collected languages, there are two major performance issues with arrays: 1. Every time you create a new array, it allocates on the heap, which is costly. 2. Every time ur array is elegible to be collected, it freezes your process, throttling it. Solution: Use array pools to reuse arrays, keeping them from being garbage collected and avoiding new heap allocations.
Theo what's your criteria for taking channel sponsors? Just wondering as I'm not really able to differentiate between if you're sponsoring for the sake of sponsoring or if also because it's a product you think would be valuable to you or your demographic.
Realistically when was the last time the framework performance actually remotely had an impact on your app? This never comes up in business apps in 99%+ of cases and the only time I've ever encountered it is screwing around for fun, messing around with 3D + webGL, etc. Unless a framework is perceptibly slow to users it doesn't really matter and it won't cost you any users or customers, but it will cost you money if you get sucked into premature optimization.
again, you could definitely get a quicker response from react if you used a stream? waiting for the entire request to finish would surely negate the rum stats associated with this being bad?
Theo isnt a vue guy. The tool of choice is React. Its not a secret and shouldnt be a surprise. So this is a video about a React guy being curious about a framework test. Focusing on react. Its cool and you shouldnt be surprised. And the comparison almost doesnt matter. Ignoring fastify as its just html. Doesnt matter which of Solid+Vue+Svelte you choose as they are fast "enough" so then it comes down to "the rest" and what you prefer.
Yea we all get that, but he's literally title the video about benchmark. More importantly nobody wants theo to know ins and out for vue, everyone just want similar treatment as solid and svelts received. these are not react framework but theo talk about what changes they implemented and go indepth what it change for them. even if its 1 min talk atleast he talk about it. Here he just completely ignored vue like a plague. All vue mention can be under 15 sec of his whole 8 min video. Nobody in the perfect mind of any benchmark video will talk this less about the winner of that benchmark. when other candidates getting talk about 1-2 min time and forgot about the last candidate React.
Anyone else still suspicious of the results even after they were "fixed"? If all the first examples were AI generated and the person benchmarking them isn't actually equipped to write basic examples within the various frameworks why should we trust their framework is actually fastest, there can be plenty of other minor things destroying the performance of the others. Not just the most obvious dev mode vs prod mode, furthermore in the fixed svelte 5 example it was faster, but in the final benchmark fastify is once again fastest so what changes were made to the fixed svelte 5 example to make it slower or what improvements did they make to fastify to get the additional performance gains and if so why weren't those gains in the original example coming from the framework author themselves? This doesn't seem trustable at all, and extremely cherrypicked to make their framework seem better than the others when in reality it doesn't really seem to deliver in that regard.
that's benchmarking in a nutshell. i enjoy benchmarking but it should always be taken with a grain of salt. when there is a significant difference in performance, it will usually mean something, but this benchmark is not exhaustive enough and is too minimal.
where is the link for the article you just read? please at least link such things edit: just to be clear, i can find it myself, the point is that if you are making use of the entire contents of something, you should at least link it
It's the same story every single time and it's tiring. Each time a benchmark is posted it's almost always just disingenuous advertisement for a product/framework. You almost immediately have people in the replies pointing out flaws. I see this with runtimes (Deno vs Node vs Bun), I see this with frameworks, I see this with libraries. Literally none of this matters because it's possible to write crappy/slow software in any framework.
I don't know, but the truth is wordpress scales horribly when you keep stacking plugins for the things you need, and eventually it just becomes slower than any modern solution.
@@ekrem_qb Hahahhaha, you are being funny, aren't you? :D Do you know how much stuff React is doing besides rendering an html trmplate. I think you do not understand the depth. Theo has a video exactly about that. It is about benchmarks also, I do not remember exact name, but it is very similar to this video! I'm for one very proud that React is able to compete with such fast tools almost on pair! While doing so much stuff and useful features.
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
we need a benchmark for benchmarks
but what benchmarks the benchmarks for benchmarks then?
Vue on #1 in terms of SSR speed 🙌
Where can I check this out?
Vue ftw
I think the take-home lesson from this is that LLMs produce bad code and, while you might get something that works well enough if that's all you need, if you're actually writing a benchmark that's supposed to measure optimal performance, getting an LLM to generate the code is pretty stupid...
Thing is, Vue keep getting better.
Vue js always has been the best choice but people overlook it.
react is ok, the problem is next
just wait for Vue vapor kek
VueJS Options is peak framework. No debate on that one.
Vue is great but I feel Sveltekit is better than Nuxt...
At this point, I ultimately realize and accept that Theo really overlook and ignore Vue, no matter how good Vue is. *sigh*
11:25
@bideshbanerjee5506 dude dun worry, I watch the whole vid before dropping comment.
@@xingxingforyou Then what's your real request, a vuejs dedicated video? That's fair but tbh he would do it already if vuejs drags enough traffic
@ nah! I didn’t request anything. All I do just want to express my thought on it. I don’t give a damm thing if he likes vue or not, just don’t like the way he tryna ignore Vue in the game even he knows Vue also was also falsely benchmarked initially but never talk, and that’s it. And it’s not just me, let’s look at other comments. Thanks
@@xingxingforyou fair I like vuejs and also reactjs I was just wondering if you wanted more content or not haha
mentioning vue is like saying voldemort in front of everyone for him
Is Vue that scary? I don't think so :) It is just another JS framework :D
He still in denial. if he saying something good about Vue his React buddies will riot.
@@justafreak15able why you assuming something about people you do not know? You do not know, how we will react. If Vue is legit, all props to you and Evan You :)
It is just happened that people got a liking to a different things, than you, which is totally normal btw. :)
If you like Vue, what do I care? Good for you :)
There are many jobs for Vue, so it is good opportunity for YOU!
What I learned from this is Vue is the goat 😅
Evan You, always makes sure to make Vue better with new versions 👏👏👏
4:27 "They were running it in dev mode"
Had me laughing too hard🤣🤣
yeah lol, massive different between dev and prod
Vue disregarded.. yet again.
Love how Angular isn't even taken into consideration.
I believe some content creators hate it and intentionally leave it out as if it's not one of the most used and most loved frontend frameworks
@imbk feels that way which is odd since it is definitely used quite a bit especially in bigger companies and governments. Not gonna say I particularly like it but I have had to work with it quite a bit over the years
Vue the winner, as usual 😅
I like the way theo tries to ignore Vue 🤣🤣.
We know Vue is better and there's nothing much to talk about. What a tragedy.
he's not reacting to vue lol
he has never really written vue. and... that's ok for anyone. don't need silly flame wars.
@@natedunn3933 he's literally in this video talking about different frameworks. Doesn't the whole premise of video is about this benchmark.
@@jatinkumar7287 read the room and the title. 😄 he's a react developer and has dabbled in a few other things. Vue not being on of those things isn't a travesty. i get wanting Vue to get more of a shine, but you're looking in the wrong places.
Why Vue when it just just copied from Angular/React? not innovative like Svelte & also it's such a great joy to code in Svelte.
You thinbk Theo dogs on Vue? He basically pretends Angular doesn't even exist despite it having almost the same marketshare.
Okay, I get the point of testing performance on a base level, but when's the last time you made a web app without client side reactivity?
All these benchmarks but users and developers almost never see the difference
Why does everyone say Theo ignores Vue? I guess they are just babbling without watching the entire video clip. Shame on them.
11:26 He said "Vue aws surprisingly fast..." 14:54 "But it's also crazy that Vue with similar capabilities is able to be so close to Fastify".
The react base component is generating a list of react nodes without adding a key to each element forcing an entire tree swap for the component in each re-render no?
But thinking about it if what we are measuring here it's ssr page serving time then this detail shouldn't matter now that i think about it
Angular?
Someone else feeling like he is ignoring vue? lol
I think his ego just cant admit Vue is good. Like legit a good tech that you can use to build virtually anything while not having to speak vercelish.
11:25
It's literally mentioned in the video that Vue is fast
@@BurgerBurglar8964Theo defends React with all excuses possible "oh, but look, it's'just' half of the performance" meanwhile the only comment he does about Vue is "Vue looks good".
I don't dislike him for that, but I found this funny. Maybe he's too deep in the rabbit hole.
Honestly, Theo's content is better when he doesn't try to talk about shit he doesn't know. So maybe not a bad idea to stick to the basics here.
*Productivity benchmark when ?*
My God, Theo's disdain for Vue is palpable.
VUE MENTIONED LETS GOOOOOO VUE
@@v02dv Yes! I like the vibe! Cool mindset you have!
Why he did not used the Solid without hydration thing, was not it like 2x the speed and had the same equivalence with his templating thing?
True. In the end Solid is the only implementation taking the hit for generating extra attribute. In some ways that is fair because of our hydration method. But without it we are out significantly ahead of even fastify.
@@ryansolid I think if u read the blog post it talk about this problem of solid, but they go ahead with this cause they wanted something same base line or whatever for every framework. Im just amazed Vue on top and theo reaction to it they doing great and move on.
@jatinkumar7287 Which is also fair. But it does put into question what is being shown unless that is that every tool can be faster than it is today if they put in the time to address it. Fastify as the baseline approach(which doesn't hydrate) isn't actually the baseline. And the room for most frameworks to improve is still measurable.
@@jatinkumar7287
I read it, I just don't find this convincing enough. Feature parity makes more sense than testing the "normal operation of the framework" because the framework can do something that is very convenient but at the same time very expensive in the baseline. But if you wanted the same speed than fastify without that feature, removing it opt-in would be a thing you would already have in mind when chosing the technollogy.
You can clearly see it by thinking about it this way:
If you remove something that do matter and will make the features of solidjs less than the features of fastify, it would be very easy to just use it as an argument and say that "solid is only as fast or faster if we remove something that makes it good", but in the case of removing hydration it appears to not put it below fastify in any way, so the only perspective that benefits itself on not using that benchmark is fastify.
Of course, you can also argue that we should prioritize the "out of the box experience" in that benchmark, which would be fair, but from the article this did not appear to be their intent.
This is such a goofball thing to measure. I love it. I think what I really learned is that LLMs can and will lead you down the wrong path and that it's really easy to deliver poorly optimized code in Node.
anyone else thinks that Theo really hates Vue that much ?
Apparently the entire comments section, yeah
how about angular?
does theo have something against vue or its just me noticing vue was being ignored and its ignored in most videos when talking about js frameworks
The same happens with Deno, the creators of Deno are obsessed with performance but seeing that even with their version 2.0 Bun continues to surpass them they prefer not to include it in their comparisons on their website.
"Let's pretend that they don't exist"
@SilasDuarte-e9k that's how all benchmarks are because it's good for marketing. there is a faster runtime than bun called just-js. web frameworks do the same thing. they show comparisons across different languages and intentionally leave out faster languages or faster frameworks in other languages.
I'm always impressed with Vue's performance numbers in these shootouts (once the testing is fixed). Performance isn't one of those things they tout very much unless they make some significant performance update (Vue 3.5), you just get it for free. It isn't always first place, but it's always middle-top of the pack, which is reassuring that the only one who's going to slow my code down is me.
React being slower mostly comes down to creating a styles object for each div
0:45 JS frameworks ?, Why Angular is not included, it's not just in this benchmark, do frontend devs hate Angular 🤔
Well of course. You're not a true FE engineer if you don't hate the guts of Angular. It's just common knowledge.
@@hasnatjamil1101 No idea, I'm not a Frontend dev
Angular is for backend devs who don't know front-end
@@hasnatjamil1101 As I remember, I never wrote Angular, but I feel that I dislike it :)
It is just because :) Everybody talks shit about it, so I got influenced. Because writing classes is not fun. Unless you are doing it with Primagen. With him classes feels NATURAL, like for real, he is an expert!
why tf you are always ignoring anything related to Vue?
vue creator was tweeting about it
nuxt core team was involved
there was a PR in the benchmark repo
what else needs to happen to simply cover it the same way as you cover others?
He's paid by vercel to ignore vue. This guy's a self centered shill who has beef with everything including libraries and even inanimate objects.
Solid is similar to React and Svelte is tied to Vercel. He will never cover Vue and Angular, just because of that.
@@naughtiousmaximus7853 I mean, we just sadly got to accept that Theo isn't some kind of tech reporter with some oath to treat each and every technology equal. If they don't have any interest in Vue, then why would they talk about it? Besides, Vue is great, don't get me wrong, but it isn't going to get any clicks since it isn't trendy anymore so the value here is little.
What I can see here is just the fact that he has been more personally involved with the people behind these frameworks and that's why he likes to cover them, which is probably not the same for Vue. Nothing to do with Vercel or whatever
@@javierflores09 It's not about making content about it. It's about not deliberately ignoring it, if it's somehow related to the things Theo wants to make content about, like in this case, he entirely ignored that the initial score was wrong for Vue too.
@@bartek.igielski "deliberately ignore" is a rather harsh assumption to make. It could just be that he didn't see the initial rebuttal tweet from the Vue people like he had seen the others, that isn't ignoring but just not being aware of it. Sure, you could argue that Theo could've gone "if React and Solid guys said this then Vue's one must have been flawed too" and go on a crusade to find the flaws on the Vue benchmark, however as I said earlier, it isn't like he is a tech reporter so he has no obligation to do that, and I certainly wouldn't if I took no interest in the framework.
Vue has rebutted their place in the benchmark as it should have and now the misconception is gone for the people who have seen the corrected benchmark. I am aware it can be frustrating that an influencer you follow doesn't do coverage of the framework but truth to be told, it isn't necessary anyway, with the amount of people that have pointed their fingers towards that benchmark, it wouldn't cause a dent to Vue's reputation in any sort of way as people are already dubious of all the results
Would be funny if some Ruby on Rails dev contacted you that you are benchmarking wrong.
I'm so glad I've settled on SolidJs!!!
Any framework that cooks its benchmarks like this is an immediate, giant, blaring red siren for me. Sketchy as fuck. You can't blame AI for that either. Any dev worth their salt reviewing those benchmarks is going to know the difference instantly. It's intentional.
To be fair I feel like we overuse JavaScript today to essentially spit out pretty basic html. There are of course situations where it makes sense but most of the time we should not be generating static html. It should just be served as is already. I'm not sure when writing basic html and css became such a naughty dirty thing.
My benchmark is putting food on the table...
What's really quick, is the speed at which a dev gets himself egg on the face by posting a half-assed test. You guys are really tolerant ; it's nice to see, because the damage could've been real. I'm sure Matteo learned his lesson ; benchmarking is more subtle than it seems.
subtle?? Nah he used dev mode bro🤣🤣🤣🤣
My bro Angular was just ignored lol
"React in SSR" already looks weird.
I think react has reached the threshold
I don’t know why developer use react , once I used vue, angular, … I regretted that I wast my time on react ,
90% is benching ur chosen framework, 10% is building a good product
What surprises me is that with fastify we can handle ONLY less than 1k conn per sec for plain html.
That's awful.
I think the way they handled being wrong is great. One thing though is that what the produced at first showcases the potential for letting AI write code.
Vue is so damn underrated! I would _never_ pick React voluntarily and yet everybody keeps using it for some strange reason
Rat Race
@@jatinkumar7287 ?
Yheo WE WANT VUEEE
It's not that SSR performance doesn't matter. But you can scale always scale when your problem is server side. When your problem is client side your only solution is to optimize the code.
We better see some real life examples thast would include all loading time to compare better.
Wish they had Qwik too
Spread operator in loop... Classic.
WTF --- "We chose not to consider tools like Next.js, Astro..." - Are you saying that Astro SSR is not a real true SSR???
I like how everyone silently agrees that angular doesn't even need to be tested
summary: bad code = slow performance
no matter what framework/library you choose, if your code is sh** the performance too is sh**
i will look to create an angular sample this afternoon
10:50 8 gigs of ram is actually insane 😅
First thumbnail was good n can generate high CTR
Nextjs does provide a render method.
This is what happens when you mess with Svelte
3:15 Now I'm afraid of copying arrays
I'm reviewing my latest project code right now, because I know I chose to copy arrays instead of using push somewhere.
On garbage-collected languages, there are two major performance issues with arrays:
1. Every time you create a new array, it allocates on the heap, which is costly.
2. Every time ur array is elegible to be collected, it freezes your process, throttling it.
Solution: Use array pools to reuse arrays, keeping them from being garbage collected and avoiding new heap allocations.
Theo what's your criteria for taking channel sponsors? Just wondering as I'm not really able to differentiate between if you're sponsoring for the sake of sponsoring or if also because it's a product you think would be valuable to you or your demographic.
money?
@@billy818 Well I'd like to assume he has some motive for not selling trust for money.
Having a line on the first chart hurt me
What happend to Qwik, why do no body talk about it? Is it too similar to Solid and Solid won the popularity contest?
To be fair we had a 3 year head start. Just like Svelte had 2 years on us. Frontend is so saturated it is increasingly hard to gain traction.
Realistically when was the last time the framework performance actually remotely had an impact on your app? This never comes up in business apps in 99%+ of cases and the only time I've ever encountered it is screwing around for fun, messing around with 3D + webGL, etc. Unless a framework is perceptibly slow to users it doesn't really matter and it won't cost you any users or customers, but it will cost you money if you get sucked into premature optimization.
People are so attached to their old tools
It's Theo and the Avengers of frontend frameworks
Everyone defending their favorite framework is if it's a sports team is hilarious.
how do u think dev have fun ?
again, you could definitely get a quicker response from react if you used a stream? waiting for the entire request to finish would surely negate the rum stats associated with this being bad?
TLDR; being slow by 2x is acceptable(?) but being slow by 5x is not.
Please play the original audio by default 🥲
14:50 React is a library... 😂😂😂
Theo isnt a vue guy. The tool of choice is React. Its not a secret and shouldnt be a surprise. So this is a video about a React guy being curious about a framework test. Focusing on react. Its cool and you shouldnt be surprised.
And the comparison almost doesnt matter. Ignoring fastify as its just html. Doesnt matter which of Solid+Vue+Svelte you choose as they are fast "enough" so then it comes down to "the rest" and what you prefer.
Yea we all get that, but he's literally title the video about benchmark. More importantly nobody wants theo to know ins and out for vue, everyone just want similar treatment as solid and svelts received. these are not react framework but theo talk about what changes they implemented and go indepth what it change for them. even if its 1 min talk atleast he talk about it. Here he just completely ignored vue like a plague. All vue mention can be under 15 sec of his whole 8 min video. Nobody in the perfect mind of any benchmark video will talk this less about the winner of that benchmark. when other candidates getting talk about 1-2 min time and forgot about the last candidate React.
bro on dev mode 💀
There’s lies, damned lies, and benchmarks.
Anyone else still suspicious of the results even after they were "fixed"? If all the first examples were AI generated and the person benchmarking them isn't actually equipped to write basic examples within the various frameworks why should we trust their framework is actually fastest, there can be plenty of other minor things destroying the performance of the others. Not just the most obvious dev mode vs prod mode, furthermore in the fixed svelte 5 example it was faster, but in the final benchmark fastify is once again fastest so what changes were made to the fixed svelte 5 example to make it slower or what improvements did they make to fastify to get the additional performance gains and if so why weren't those gains in the original example coming from the framework author themselves? This doesn't seem trustable at all, and extremely cherrypicked to make their framework seem better than the others when in reality it doesn't really seem to deliver in that regard.
that's benchmarking in a nutshell. i enjoy benchmarking but it should always be taken with a grain of salt. when there is a significant difference in performance, it will usually mean something, but this benchmark is not exhaustive enough and is too minimal.
Is this not like an old month old?
You're X link is wrong !! Nice video btw
Is this a reupload? I feel like i've seen it already
Maybe it was live
hindi audio is not good, i had to switch to english version immediately
At this point benchmarks are only a marketing tool now , jokers running around with benchmarks 😂
The thing is, it doesn't matter 😂🤷
Always Vue , nothing else comes close fo it❤
where is the link for the article you just read? please at least link such things
edit: just to be clear, i can find it myself, the point is that if you are making use of the entire contents of something, you should at least link it
It's the same story every single time and it's tiring. Each time a benchmark is posted it's almost always just disingenuous advertisement for a product/framework. You almost immediately have people in the replies pointing out flaws.
I see this with runtimes (Deno vs Node vs Bun), I see this with frameworks, I see this with libraries.
Literally none of this matters because it's possible to write crappy/slow software in any framework.
Wtf svelte = react confirmed???
Svelte => React wrapper
Atleast give the tweet you made the video about...
Still, we love React
Nah react rocks, complex apps and ssr is odd.
Where does WordPress sit here?
Too high level. PHP could be benchmarked like this.
I don't know, but the truth is wordpress scales horribly when you keep stacking plugins for the things you need, and eventually it just becomes slower than any modern solution.
Those relying on AI to code are only working to further reduce the quality of future AI-generated code
It’s just the standard now.
La pista de audio en español es muy rara. Jajaja
He says veet
This is the way.
Vue is the best!
Thanks for hindi audio
Svelte yay
Once again *react-library* showed how awful it does the work. You all look miserable defending it, just accept the reality, guys.
@@ekrem_qb Hahahhaha, you are being funny, aren't you? :D Do you know how much stuff React is doing besides rendering an html trmplate. I think you do not understand the depth. Theo has a video exactly about that. It is about benchmarks also, I do not remember exact name, but it is very similar to this video!
I'm for one very proud that React is able to compete with such fast tools almost on pair! While doing so much stuff and useful features.
where's angular sir?
📊✅
Those kind of benchmarks are trash. Build real world apps then compare.
This is an old topic, isn't it?
Hindi translated audio is not good.