Samuel
@samuel.fm
(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
Kevin Shay
Yeah, I wasn’t talking about this table specifically but just generally that some tools are poorly suited to some tasks and that can show up in data like this
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
Jake Lazaroff
if you’re dealing with raster images, sure. if it’s an SVG editor, a node-based UI, etc, you’re prob rendering HTML at the end of the day. tldraw is built in react so framework choice is obvs not the only variable here. but imo web frameworks should let you build most things without optimizing perf