[nawgz]

I'm not sure what you are asking. You can of course build a trivial use-case with a native feature and have it perform as one would expect from a native HTML element.

However, it's not like the UI guys in the article didn't do that and implemented some crazy shit poorly. They just slapped a table on the page, incidentally with 38k elements - sounds a lot like what you did actually, and it lagged the page due to browser painting/layout issues.

Now, finally: how exactly is what you did not just the same as this, except they were actually making a usable front-end so the addition of CSS broke the browser rendering engine? Because it sure doesn't sound like you would know what to do in the situation the article discusses...

[xmprt]

Usable has many meanings and to me personally, a website that isn't very responsive and lags when you scroll doesn't seem very usable.

[nawgz]

Did you read the article and the comment I was replying to? Both basically rendered 40k element HTML <table>s. Difference is, the Google UI lags because it is hampered by browser painting/layout computations taking forever, despite the <table>s in discussion having near-identical complexity, so one can conclude the Google UI bug is more-or-less a bad interaction between the UI's CSS and the browser rendering engine.

So, pray tell, how does parent comment decrying UI developers for supposedly not just rendering HTML tables make any sense in light of this context? It is just sass from someone who likes to rail against UI development, there is no insight