> Even JSON is going to be "bloated". This cries out for a well-done, well-thought out binary format Well unless it doesn't. I've recently read more than one b

> Even JSON is going to be "bloated". This cries out for a well-done, well-thought out binary format Well unless it doesn't. I've recently read more than one blog post that claimed JSON was actually borderline faster—sometimes more than borderline—than some popular binary formats like protobufs. I won't link those benchmarks here because none were well enough conducted or presented to warrant a link; I myself treat those reports as plausible but anecdotal hints. It's not like saying "binary format" makes all your troubles go poof. You still have to parse it. Yes, you can control it better when you create it, but when you've created it and it sees a lot of adoption, then updating it will be just as troublesome as updating any popular format, meaning many clients won't support some of the new features for at least some time. Numbers of course are central in any actual SVG, and it turns out using a textual format to send numbers is not as stupid as it sounds, space-wise: `1` is just one byte, but it's 8 bytes (I think) of RAM when turned into a JS IEEE754 number. You can represent arbitrary precision or restrict yourself to integers on a whim when using text, something probably not true of most binary formats. One of my qualms with SVG are that XML itself is a needlessly complex format. As sort-of-proof for that claim I present you the fact that the [namespace on the `href` attribute has been elided from the standard](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use). This of course is just the tip of the iceberg of XML complexity. The other big Qualm is that for some reason the authors of SVG felt it necessary to open the doors for a lot of variation on how to write things like e.g. the `<path>` element's `d` attribute, like you can add commas or leave them out, you don't need whitespace in `"45-67"` because that can be parsed as `(45,-67)` and so on. Not useless stuff, but in the end more than minimal complexity. I find text-based formats so much better in many regards. Just look at the rich appearance of web pages today, almost all of that has been done using text-based formats. They're really powerful, and where needed, may be compressed using a generic algorithm.