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
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
@samuel.fm
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
Kevin Shay
Obviously that requires some followup inquiry into what’s going on and not just “use this chart to pick a framework”
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