+1. This is a significant danger with something like Pixi, although it was also a danger back when Java embeds or Flash embeds were a thing on the web. I don't like having the limit, because sometimes you need a LOT of separate charts and things. But having 16 separate canvases animating will not do your users a lot more favors than having 16 WebGL contexts, either. Mixing black-box bullets with regular HTML has always been an architectural problem - and a very understandable one when you want to have lots of cool modules going in separate places, but don't want to make your whole site a black box. I'm not a typical engineer, and 99% would disagree with me, but I think if you need that many custom animated/interactive components on screen at any one time, in separate places in the DOM, you might be better off writing your own UI components and making the whole thing into a single Pixi app the way we used to write apps in Flash/Air.

Just to also say: I have one major project that uses Pixi to generate graphics and charts, sometimes up to 100 per page, but it uses one Pixi.Application to do all of that statically, and then copies out temporary images and deploys them around the DOM. When the user clicks on one, a new Pixi app starts there to redraw it as an interactive component. When it loses focus, it's destroyed after awhile. This was my solution to having dozens of Pixi things in an HTML doc at the same time. It's probably not great, but it made sense given the constraints.