> it could be loaded into a browser using eval() That's unrelated to the code/data distinction. But it does elucidate an important downfall of blurring code &

> it could be loaded into a browser using eval() That's unrelated to the code/data distinction. But it does elucidate an important downfall of blurring code & data: using eval() opened web applications up to major security holes. (Not to mention it was incorrect, JSON won't cleanly round-trip JS even with JSON.parse.) JSON is plain old data, nothing more, nothing less. Sure, I could replace all SVG tags with curly braces; that doesn't make it code. > Users will keep wanting applications that do more, not less. The ability to author vector graphics at a high level being a prime example of something more, that is not possible with a Turing tarpit of a data format like PostScript or JavaScript with lots of Canvas instructions. Applications like Inkscape are only possible because of rich data formats like SVG. Note the lack of authoring tools -- both for vector graphics and documents -- which work natively with unattributed PostScript. That's because its nature, as code, obscures all structure. It makes for a mediocre final format due to (as you point out) its ease of implementation, nothing more. And even there, PDF, which is not interpreted, has proven superior. JS+Canvas would suffer the same issues.