Why You Should Never Again do a Scrollable List with ng-repeat

Anybody who’s ever done a long, scrollable list of items in a web interface knows that this can absolutely kill performance of the whole page, let alone the scrolling itself. People blame tools like Angular’s `ng-repeat` for performance problems, but the problem isn’t the tools: it’s just that they make it so damn easy to do things… you should not do. Performance of your page is inversely proportional to the DOM count, and a massive list of items may square or cube the number of elements in the interface.

We do all kinds of workarounds to deal with this: pagination, “infinite” scroll (which is badly misnamed, but I digress), etc. But there’s now a much easier, cleaner way to have as many items as you want, without penalty: don’t create elements for all the items in your list. Just however many will fit in the window, plus two or so. And recycle them into whichever position your user is scrolling in. (It’s Green!™) Conceptually, it’s very simple. Implementation-wise… most of us would like someone else to do the heavy lifting.

I first saw this approach mentioned in the Sencha Labs post about their “FastBook” experiment, in which they called it an ‘Infinite List’. Thereafter, I was surprised I hadn’t seen that approach adopted elsewhere in JavascriptLand soon after, and am sad I never got around to trying to build one myself. (Maybe someone else did. I missed it. Please share other implementations in the comments!)

But now, the Ionic UI framework has an Angular directive for this, which they call the `collection-repeat`. You. Must. Use. This. In Ionic, out of Ionic, whatever. And hack it, port it to other frameworks, tweak it, extend it, and just generally make sure that you never do long lists with naiive ng-repeat… ever again.

The Reports of WebSQL’s Death Have Been Greatly Exaggerated

Every time I poke around the interwebs looking for docs on various forms of offline storage, I find folks saying that WebSQL is ‘dead’, or more often: ‘deprecated’. Not so. It’s just that every browser that implemented WebSQL used SQLite, so work on a formal standard stopped:

The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path.