4 ms·
I'm a little surprised they don't do something like iOS does for rendering list views quickly... have a small subset of item views rendered and basically reuse
by programminggeek 13y ago
I'm a little surprised they don't do something like iOS does for rendering list views quickly... have a small subset of item views rendered and basically reuse them. You aren't displaying all 7,000 items so while maybe it makes sense to load the data in one shot, does it make sense to load all the DOM elements? Probably not.
Also, I understand why things get slow, but I will never understand why performance benchmarking doesn't seem to exist in many places as part of the QA process. Writing tests and making things work right is usually there, but making sure things are performant and the user has an outstanding experience seems to get left until it's a "problem".
- yogo 13y agoThat could be seen as premature optimization. If you don't know things like the average number of cards, or the average for the power users then you don't know if you will have that problem. That would be like saying they should spend time on supporting 30,000 (made up number) cards right now.
- danabramov 13y agoAirbnb made a JS lib for this: “∞ is a UITableView for the web”. http://airbnb.github.io/infinity/ http://airbnb.github.io/infinity/
- vonseel 13y agoNice find!
- lennel 13y agoblocked rendering works, but reuse of existing dom components do not. much cheaper to break it into the list item and render around your display area in larger blocks than you would if you use native. detaching from the dom changing is cheaper than item reuse, still cheaper to render multiple fragments and converting and adding them once.