Samuel
(not directed at Kuba specifically) but this is meaningless. it's like measuring all your wrenches by weight to see which one is the lightest
2 11
Samuel
if you're writing slow react code I 100% guarantee you'd write slow solid/vue/preact/svelte/lit code
3 18
Brenelz
In some ways I agree but don't you potentially want a higher ceiling? I guess the argument is is the popular solution is good enough
Thiago
I was with you until here Thanks to the re-rendering model, React needs to tie the state to the component structure This means that in any other framework I can create the most complex app in the world in a single component and have a performance superior to the equivalent most optimized React code
EmNudge
You agreed with ‪@jovidecroock.com‬'s take, so I suppose you also disagree with yourself here. I get the overall point, but this one taken literally is wrong. React code is slow for reasons much different to other frameworks. It does not follow that experiences will be the same in other frameworks.
2
mary🐇
i find the table to be useful in some way because i find both speed and size to be crucial, i have faster internet now but at times i've been in places with spotty coverages and it sucks helps that smaller libraries are also easier to understand, and i can patch it myself if something is wrong
1 5
mary🐇
i went through that table when i wanted to add search into skeetgen, was pretty neat seeing how many choices there are
1 3
mary🐇
tbh in practice the amount of times i've had to patch something is pretty low, but i just like that i know exactly what happens behind the scenes, that i have the control to mess around with it rather than covering my eyes
1 2
mary🐇
there's the matter of patterns as well wrt speed, but that's something i'd have to decide on my own
1 1
Samuel
yep, that’s fair, and I can totally see the value in both size and simplicity. I just think speed is the least valuable metric because it’s highly unlikely that that’ll ever be the bottleneck in your code
1 1
Samuel
the problem with the table is that it’s easy to think “I want my app to be fast so I’ll pick the fastest one” when in reality that has little bearing compared to *how* you’re using the framework
2 3
Kevin Shay
It’s true that “green vs. lighter green” probably isn’t meaningful but I do think a big red outlier can at least indicate a potential pitfall
1 1
Samuel
if your bottleneck is swapping 2 rows in a list as fast as possible I'd love to hear your use case
1
1 more reply
Jake Lazaroff
if your app makes network requests and renders the responses in lists that’s probably true. i’ve definitely run into framework bottlenecks building eg graphics apps that need to update at 60fps. don’t think picking the fastest benchmarked framework would’ve solved the problem but it might’ve helped!
1
Samuel
yeah I mean that's just the wrong tool for the job, you want a game engine-type thing for that. this is microbenchmarks specifically for web frameworks
1
1 more reply
Jovi 🐨
We’ve seen this a lot at Preact as well. Micro benchmarks tell us something about the algorithmic complexity and efficiency. That part of an application is small, the times you replace 1000 rows is rare. The framework pushing you into good patterns is a million times more valuable.
3 10
Jovi 🐨
A framework can perform bad on replacing 1k rows but what if the one being fast for that also optimised for that. For instance the fast one forces replace for one small row update while the slowe one does not
1 5
Jovi 🐨
Deciding on micro benchmarks isn’t gonna lead to good decisions. It’s a data point but not a decisive one imho
1 6
Jovi 🐨
I am a maintainer on an oss repository where a really bad pattern is still not fixed because a micro benchmark regresses with the fix. Not fixing it means actively delivering worse experiences for users, it’s beyond me how our community lives with these things
5
Dev Agrawal
The best part about the benchmarks is finding frameworks that push you towards good patterns AND are also super performant so I can spend more time building features and less time looking for regressions
1 1
Jon Asby
My favourite thing to do on the internet is increase the page size and speed run the sort options
3
Tomáš Schmied
JS engines are ridiculously optimized, so not really surprised. The stuff V8 and JavaScriptCore are doing nowadays is borderline black magic.
1
Dev Agrawal
It’s literally testing the performance of rendering an array into a table/list Do you not have that in your app? I have like 20 of them in a normal app It’s a big and general enough task to not qualify as a microbenchmark
1 1
Ryan
This one in particular is pretty bad too, some folks spend huge amounts of time trying to inch their particular FW ahead over dozens of PRs. Optimizing the hell out of a benchmark is a neat skill & the repo owner is clearly ok with it, but it’s so far from representative real-world use cases.
2
Dev Agrawal
> so far from representative real-world use cases Rendering an array into a list/table is far from real world use cases?
1 1
Ryan
Rendering 1k+ rows at a time is, yes. There's no monitor in the world that could realistically fit 1k rows, most of that is going to be pure waste just for the sake of this microbenchmark. Not to mention the much sillier tests like swapping or replacing rows in that oversized table.
1
Ryan
Benchmarks like this are useful only in the context of a singular FW to catch accidental regressions over time IME.