The article has a humorous history of graphics APIs that I very much enjoyed. I did the the Vulkan tutorial for kicks one month on Windows (with an nVidia GPU) and it was no joke, super fiddly to do things in. I look forward to trying WebGL in anything that isn't JavaScript (some language that compiles to WebASM or transpiles, I guess).
Not wanting to disregard your pint, but there are definitely applications in SVG. The user interface for the most famous kitchen “robot” (Thermomix) is done entirely in SVG, and they (through open source consultants Igalia) are one of the most important contributors to SVG and Canvas functionality in WebKit.
Oh the comparison to PDF was perfect. PDF and Metal have the same recent ancestry with postscript.
What ugly prejudices so many people on this thread seem to have. And how trivial and nonsensical. All I said was she should not have omitted svg in her history of graphics apis since she's writing an article about browser graphics. To deny that svg is a part of that, or that people don't program to it... well, I was going to write "ridiculous" but the xkcd about people who don't know things comes to mind...is it possible you just don't know that so many people make things with SVG? In any event, it seems I've touched a nerve that I didn't want to, and I find it ugly, and this is my free time, so I'm leaving the convo.
> All I said was she should have not omitted SVG in her history of graphics APIs since she’s writing an article about browser graphics. To deny that SVG is a part of that
You are continuing to double down on a straw man, which is why you’re getting all the push-back. The ugliness is ugliness you’ve single-handedly created because this is not an article about the history of browser graphics. It would have included SVG if that were the case, but it’s not, and you’re making assertions that aren’t warranted or justified here. This was an article about GPU APIs. Canvas was only mentioned briefly off-hand in passing twice, and the history of Canvas was not discussed at all, nor was the history of browser development. Nobody denied that SVG is part of anything, you are projecting your off-topic wishes onto a discussion where SVG simply does not belong, it’s tangential and not relevant to the article. It’s not relevant here how many people make things with SVG.
SVG is great. I wish development for SVG2 hadn’t stalled out, I would like to see SVG2 become broadly supported, there are some new options for dynamic scaling I’ve wanted to use for ten years. That said, this is a completely separate topic from the article & thread. You could get your SVG fix by submitting an article to HN that’s actually discussing SVG rather than trying to hijack the comment thread on an article about GPUs.
Not only that, his comments are factually incorrect, while glibly dismissing a well written factually correct article as untrustworthy, based on his incorrect assumption that his incorrect facts imply her true facts are false. "So one should take it with a grain of salt." Sheez. How rude.
In what sense is Metal descendent from PostScript? The comparison is anything but perfect: they're practically polar opposites.
Metal isn't a text based programming language like PostScript, and it has a completely different graphics model.
PostScript isn't pixel oriented, or 3d oriented, and Metal doesn't have a stencil/paint graphics model or text rendering.
They're totally different things, by totally different people and organizations.
Metal uses SPIR-V binary byte code, which is nothing like PostScript, a stack based high level polymorphic cross between Lisp or Forth, and a descendent of Interpres, JaM, and Design System.
As programming languages go, and as imaging models go, PostScript and Metal are at completely different ends of the spectrum.
SVG, like PDF, is the PostScript stencil/paint imaging mode, without the Turing complete programming language, but expressed as XML, with some CSS thrown in. And some implementation of SVG even let you define event handlers in JavaScript, but Metal sure doesn't let you do that. And to top it off, SVG is "object oriented" (i.e. a DOM) while Metal is "immediate mode" (i.e. an API). They couldn't be more different.
Since your facts are wrong, and you're throwing around insults like "ugly prejudices" and "trivial and nonsensical" and "ridiculous" and "people who don't know things" and "I've touched a nerve" and "I find it ugly", then it's a good thing that you're "leaving the convo", because you haven't contributed anything but misinformation and insults.
That's right, I was mistaken. The point I was trying to make is that compiled shader languages are very unlike dynamically interpreted PostScript, which is much more like Lisp or Smalltalk than C or C++.
She omitted it because it's not an API, it's a file format. Even if you want to be lax about what you call an API, svg was never a competitor in this space. She also left out canvas, directdraw, direct2d, gdi, etc, because they're just not relevant to any of this.
Despite the name, WebGPU isn't limited to browsers, I think the article sort-of implies that without explicitly pointing it out (until late into the article).
Instead WebGPU has a good chance to become the 'missing link' standard cross-platform 3D API that sits above D3D12, Metal and Vulkan and at the same time is relatively straightforward to use for mere mortals.
SVG is just a file format though, that I suppose you can manipulate in the DOM. By your standard glTF files would be an "API" also. Have you written D3D/GL/Vulkan/Metal? It's not even remotely similar.
These are all tools programmers use to draw to the screen. In the browser there are now 3 such tools: svg, canvas, and webgpu.
svg's primitives are shapes and you program it with js and dom.
canvas primitive is a 2D array of pixels, and you program it with js and an api.
webgpu's primitive are pipelines (or whatever) and you program it with js and an api.
Maybe you're hung up on using the dom instead of an api. But the dom is an api, and it is further specialized by svg. Mutating the screen is exactly equivalent to mutating the dom within SVG. The mental model is that of a persisting scene that you nudge around with changes. This, versus the mental model of canvas where shape persistence is up to you. My understanding of low-level 3d graphics (limited to that of a hobbyist) is that driver commands setup a pipeline and then nudge around a scene graph in a similar fashion to svg. So it is doubly ironic that she would omit it.
Why are you excluding the HTML Title? Someone made a game that you play entirely in the browser's Title? https://titlerun.xyz/
Why are you excluding GIF? I can't find it, but I saw someone made a remote desktop client that encoded the video as a never-ending GIF stream.
Why are you excluding fonts? You can create custom fonts and use them to draw all kinds of crazy things.
We draw the line somewhere. I thought the History of Graphics APIs in the article was great. Sorry it disappointed you. I felt your attack on the author's credibility, "[I]t omitted SVG entirely. So one should take it with a grain of salt" was pedantic and rude.
> svg's primitives are shapes and you program it with js and dom
Maybe you do and that's fine. I program SVG by dynamically generating it on the server in Lisp. No js required unless I need to change an element at runtime. SVG is much more centered on "paint a picture with vectors and then send it to the browser" than "call a function to draw this vector RIGHT NOW" which is why people here are saying it's not really an API the way Vulkan and WebGL and WebGPU are.
For SVG to be considered an API, HTML would have to be one too. For SVG to be relevant to TFA, it would also need to express 3D geometries, and SVG is focused on 2D.
