SVG always reminds me of JS - a seemingly overcomplicated and slightly ungainly technology that actually just turned out to be ahead of its time. Back in the b

SVG always reminds me of JS - a seemingly overcomplicated and slightly ungainly technology that actually just turned out to be ahead of its time. Back in the bad old days when you had to install the Adobe plugin to view it at all, it was almost useless. But nowadays, almost all browsers have more than adequate native support and it turns out that it's actually very useful as a good way of doing declarative vector graphics (as opposed to the immediate mode world of Canvas). I switched to using SVG for all artwork in my apps about 2 years ago and haven't looked back once - there are no performance issues; I can retheme them via CSS (if loaded as objects rathe than imgs), they look perfect on arbitrary resolution displays, plus animation is trivial when desired. Meanwhile libraries like D3 show just how powerful and performant SVG can be. So: given a choice between a custom library which implements some kind of vector DOM on top of canvas, and having it baked into the native DOM of the browser with decent performance, I know which I'd rather have. The biggest problem I've seen in practice is when handling user generated SVGs - the risk of vulnerabilities in the implementations; XSS attacks - and design flaws like billion lol attacks. But such are the risks of using an expressive language like HTML, SVG, or heaven forbid postscript or PDF :)