3 ms·

JSON is based on (not a subset of) a purely declarative and structural portion of JavaScript. They really have nothing to do with each other except some surfac

JSON is based on (not a subset of) a purely declarative and structural portion of JavaScript. They really have nothing to do with each other except some surface syntax, which is wholly irrelevant. PostScript is a terrible intermediate graphics format. It is not structured like how SVG is, and thus does not lend itself well to editing. Consider the basic example of text: there is no such thing as a "text box" or "flow" in PostScript; rather, individual letters are placed at coordinates. You're right that Canvas is analogous to PostScript; Canvas also would make a terrible intermediate format. Sure, we could use it as one; it would certainly be a more universal final format than SVG; but then, what's wrong with PostScript there? It's certainly less verbose. Blurring the lines between data and code is a tarpit. I look forward to the day it's universally recognized to have been a dead end in the evolution of our field.

bobajeff 10y ago
Aren't .psd and .ai formats based off of PostScript?
- ygra 10y ago
  .PSD certainly not. Why would it? But .AI has originally been PostScript and currently is PDF. Pretty much in the same way as Inkscape uses SVG as its native format – application-specific things are encoded as additional data on objects which can (usually) be safely ignored by other applications rendering the same file format.
pavlov 10y ago
> JSON is based on (not a subset of) a purely declarative and structural portion of JavaScript. They really have nothing to do with each other except some surface syntax, which is wholly irrelevant. That's an ahistorical view that completely ignores the only reason why JSON became popular: it could be loaded into a browser using eval() or script tags at a time when JS engines were slow and limited. If the JS-compatible syntax were irrelevant, surely everyone would have standardized on one of the existing tidier formats? > Consider the basic example of text: there is no such thing as a "text box" or "flow" in PostScript; rather, individual letters are placed at coordinates. This is good. Imagine if Adobe had designed PostScript back in 1983 using the SVG design mentality. They could not have foreseen all the applications for PostScript. The original text flow model would have rapidly become inadequate, and they would have been forced to pile on hacks into the standard -- just as happened with CSS. Between PostScript and HTML+CSS, the former is a much more useful industry standard. It's relatively easy to implement a PostScript interpreter from scratch. It's practically impossible to build a new HTML+CSS renderer. > Blurring the lines between data and code is a tarpit. I look forward to the day it's universally recognized to have been a dead end in the evolution of our field. You'll be waiting for a while. Users will keep wanting applications that do more, not less.
- colanderman 10y ago
  > 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.

bobajeff 10y ago

Aren't .psd and .ai formats based off of PostScript?

ygra 10y ago
.PSD certainly not. Why would it? But .AI has originally been PostScript and currently is PDF. Pretty much in the same way as Inkscape uses SVG as its native format – application-specific things are encoded as additional data on objects which can (usually) be safely ignored by other applications rendering the same file format.

pavlov 10y ago

> JSON is based on (not a subset of) a purely declarative and structural portion of JavaScript. They really have nothing to do with each other except some surface syntax, which is wholly irrelevant. That's an ahistorical view that completely ignores the only reason why JSON became popular: it could be loaded into a browser using eval() or script tags at a time when JS engines were slow and limited. If the JS-compatible syntax were irrelevant, surely everyone would have standardized on one of the existing tidier formats? > Consider the basic example of text: there is no such thing as a "text box" or "flow" in PostScript; rather, individual letters are placed at coordinates. This is good. Imagine if Adobe had designed PostScript back in 1983 using the SVG design mentality. They could not have foreseen all the applications for PostScript. The original text flow model would have rapidly become inadequate, and they would have been forced to pile on hacks into the standard -- just as happened with CSS. Between PostScript and HTML+CSS, the former is a much more useful industry standard. It's relatively easy to implement a PostScript interpreter from scratch. It's practically impossible to build a new HTML+CSS renderer. > Blurring the lines between data and code is a tarpit. I look forward to the day it's universally recognized to have been a dead end in the evolution of our field. You'll be waiting for a while. Users will keep wanting applications that do more, not less.

colanderman 10y ago
> 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.