(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

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

i went through that table when i wanted to add search into skeetgen, was pretty neat seeing how many choices there are

redid the post so its less snarky

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

there's the matter of patterns as well wrt speed, but that's something i'd have to decide on my own

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

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

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!