2 ms·
Most of the solutions are great improvements! However, I don't think the global feature switch for comments is where it belongs, and I hope nobody forces the ro
by some1else 12y ago
Most of the solutions are great improvements! However, I don't think the global feature switch for comments is where it belongs, and I hope nobody forces the rounded mask on my album art just because of UI aesthetic.
I could live with the current SoundCloud version if the infinite scroll were changed back to regular pagination. Prolonged site usage heats up MacBooks. It would be interesting to pull off an iOS-like, high-performance scrolling algorithm that recycles a limited number of rendered objects, But I haven't seen anything like that with Backbone Models and Views.
- bzalasky 12y agoInfinite scroll can be a terrible anti-pattern when implemented poorly, and it's terribly difficult to pull off correctly. I dealt with this issue at the last startup I worked at (Stipple, now defunct :(). We had a masonry feed of annotated images with associated media like videos, audio and product links that was infinitely scrolling. What this meant in practice is that you could paginate about 20 times before the fan on your macbook would start roaring. LinkedIn had a great article about year or two ago about optimizing infinitely scrolling feeds, however, it only applies to single column feeds. Masonry layouts make things much more difficult. That being said, one of the benchmarks in that article mentioned toggling visibility improving performance (not what they settled on, but still a significant gain). This is what I was able to implement. We had to query the DOM to detect when an image in the feed was moving in and out of the screen with a buffer equal to screen height. With this in place, users could paginate 50+ times without trouble (at a solid framerate), though they would've eventually hit problems if they kept scrolling too long. TLDR; I hate masonry layouts for performance reasons.