6 ms·

I've built diagram like tools several times, constantly umming and ahing between Canvas and SVG. SVG seems to get you pretty far, but I always end up with Canv

I've built diagram like tools several times, constantly umming and ahing between Canvas and SVG. SVG seems to get you pretty far, but I always end up with Canvas in the long run. Fun fact: Google docs is actually a canvas.

thrashh 3y ago
Same. Working around the issues with SVG sometimes takes as long as rewriting parts of SVG from scratch. It’s not an SVG problem so much as Canvas and SVG are not reconciled into one bigger rendering system, so when you hit an edge case that requires breaking outside out of SVG, you have no path.
alixanderwang 3y ago
i'm building a diagramming tool (https://terrastruct.com https://terrastruct.com) and still umm and ah b/t it. I'm kind of waiting for webgpu to reach 95+% browser support before switching though. If I do all the work of switching, SVG better not get gpu/hardware-acceleration support the next day
- Solvency 3y ago
  I'm confused... Figma can seemingly do all of this already, from a rendering perspective. And it's outrageously performant. It's one of the most performant web apps I've ever seen. Why don't you do exactly what Figma is doing?
  - avmich 3y ago
    A long time ago a small startup used unusual tooling in the industry. The startup was small, but the tooling had some great qualities, which allowed the startup to compete with bigger teams feature for feature, spending less efforts to produce the same functionality as their industry peers. Eventually the startup had a successful exit, the founders become rich, and one of them even started sharing his experience in a rather systematic manner. Happy end. Is it so that SVG requires to use all the features of it, or is it possible that you can mix and match, choosing what's important now and what's not, while benefiting from already existing SVG features? Is it possible that SVG followers don't do something which SVG does for them? Aren't there features, sufficiently aligned with SVG, which outperform directly working with other layers?
  - alixanderwang 3y ago
    It's hard to get as performant as Figma does, not as straightforward as a rendering medium switch. What if webgpu lets me get Figma performance with my little 6 person startup team without the massive engineering man-hours Figma has spent on performance? Anyway, if it were high priority for us, we'd have done it already (switching to canvas/webgl). But right now it feels like buying a Quest when the Vision Pro is coming soon.
  - rikroots 3y ago
    Figma is excellent at many things, but they struggle with accessibility. It's been a year since they wrote a blog post about their accessibility efforts so I don't know how far they've managed to solve the issues they identified - https://www.figma.com/blog/a-step-forward-in-our-accessibility-efforts/ https://www.figma.com/blog/a-step-forward-in-our-accessibili...
- rapnie 3y ago
  Nice! I found https://d2lang.com https://d2lang.com via your link, and thought it warranted a separate submission: https://news.ycombinator.com/item?id=36224084 https://news.ycombinator.com/item?id=36224084
rektide 3y ago
Google Docs document canvas is a tool. Most of the chrome & interface is html & works great. The switchover to canvas broke a ton of extensions. Chrome eventually went out & built a custom api to help users deal with some of the massive loss of functionality that switching off high-level html to go use lowest level html caused. But that took a ton of effort from Google, & the result is still a shadow of what was possible before. IMO, do the right thing for user agency & stick with higher level web stuff if you can, unless design truly compels it. Reinventing has many subtle pitfalls.
- josephg 3y ago
  > IMO, do the right thing for user agency & stick with higher level web stuff. Reinventing has many subtle pitfalls. This is great advice 99% of the time. But the browser has two big pitfalls which hurt google docs: 1. Browser rich text editing events are famously awful and inconsistent on different browsers and platforms. 2. Google docs wants the same document to render exactly the same on all OS / browser combinations. Thats not something that web browsers guarantee. In this case, I understand google's choice to build a custom renderer. I'm sure it was a massive effort for the team, but probably not quite as massive as working around all the browser quirks they were dealing with before. (From memory, before the canvas renderer, google docs ran their own rendering code then used CSS to absolutely position every single word in the document.)
  - dekhn 3y ago
    I spoke to the original creator of Google Docs (from before it was Google Docs, https://www.theverge.com/2013/7/3/4484000/sam-schillace-interview-google-docs-creator-box https://www.theverge.com/2013/7/3/4484000/sam-schillace-inte...) and he confirmed what you recall; they had to write their own text rendering code because the browser does not implement the behavior required by a word processor (one example: flowing text around an image)
    - chrismorgan 3y ago
      That was long before they switched to canvas rendering, too: they were still just using contenteditable, though potentially with mild layout augmentation with things like absolute positioning and sizing of things (I don’t know). Flowing text around an image: the web has been able to do this for donkey’s years, it’s the float property. More recently, there’s the CSS shape-outside property that even lets you use non-rectangular crop: https://developer.mozilla.org/docs/Web/CSS/shape-outside https://developer.mozilla.org/docs/Web/CSS/shape-outside.
chrismorgan 3y ago
> Fun fact: Google docs is actually a canvas. This is often said, and almost as often misunderstood as referring to what I call the “pure canvas” approach where you throw away almost everything the browser gives you and start from scratch. Some key points about Google Docs, just to clarify (I’m not disagreeing): ① Only its document area is rendered with canvas; its chrome is all still regular HTML. ② It still uses the browser for text shaping and painting, just not for macro-layout (breaking paragraph into lines, &c.). (I expect that’s what this article’s subject would be doing too, but it’s part of common misunderstandings.) ③ Even things like scrolling are completely left to the browser: it’s not a single <canvas>, but a regular DOM scrolling area contains a bunch of <canvas> tiles. ④ The shunning of using HTML-with-contenteditable for the entire thing makes editing perform very badly (throughput, latency and jitter), and things like keyboard caret navigation behave non-natively in ways that will be very frustrating for people that actually use and care about this stuff (you get to relying on things behaving the same, like with touch typing, so things that get it wrong like Google Docs and LibreOffice (which gets it all wildly wrong) constantly grate). ⑤ They could just as easily use HTML or SVG rendering as <canvas> (while keeping their input and layout the same, so I mean still with all manual line breaks and that kind of thing). You’d get quite similar performance (though probably overall a little worse), and the same problems (since it’s the input layer that makes it slow and jittery—it just fundamentally can’t be as good in those ways as boring old contenteditable, given the current primitives). In fact, it’d mildly surprise me if they didn’t have an SVG or HTML renderer handy, or did in the past and could revive it to complete indistinguishable functionality within a day or two (even if hacky). (I wrote a little more at https://news.ycombinator.com/item?id=33863185 https://news.ycombinator.com/item?id=33863185.)
- rektide 3y ago
  This is one of the best comments I've read on the much ballyhood Google Docs canvas! Favorited. I expect I'll be referencing this a good bit over the years.
paulddraper 3y ago
You start with SVG Then you go to Canvas Then you go to WebGL Source: Early engineer at Lucidchart
- thomasfromcdnjs 3y ago
  aha love this
- mkl 3y ago
  Then you go to WebGPU, I expect.
  - paulddraper 3y ago
    Not for graphics
- ygra 3y ago
  Similar journey here (yWorks, with a diagramming library, too). In our case the journey comes with drawbacks, though. Yes, WebGL allows for larger graphs, but it also does not support the flexibility (to customers) the other options offer.
- thekenwheeler 3y ago
  it depends. canvas is typically much more cpu friendly. and does a way better job with text. (2d)
- hicksyfern 3y ago
  Author here. For sure. That’s actually what we’re likely to do as the basemap rendering is done in webgl

thrashh 3y ago

Same. Working around the issues with SVG sometimes takes as long as rewriting parts of SVG from scratch. It’s not an SVG problem so much as Canvas and SVG are not reconciled into one bigger rendering system, so when you hit an edge case that requires breaking outside out of SVG, you have no path.

alixanderwang 3y ago

i'm building a diagramming tool (https://terrastruct.com https://terrastruct.com) and still umm and ah b/t it. I'm kind of waiting for webgpu to reach 95+% browser support before switching though. If I do all the work of switching, SVG better not get gpu/hardware-acceleration support the next day

Solvency 3y ago
I'm confused... Figma can seemingly do all of this already, from a rendering perspective. And it's outrageously performant. It's one of the most performant web apps I've ever seen. Why don't you do exactly what Figma is doing?
- avmich 3y ago
  A long time ago a small startup used unusual tooling in the industry. The startup was small, but the tooling had some great qualities, which allowed the startup to compete with bigger teams feature for feature, spending less efforts to produce the same functionality as their industry peers. Eventually the startup had a successful exit, the founders become rich, and one of them even started sharing his experience in a rather systematic manner. Happy end. Is it so that SVG requires to use all the features of it, or is it possible that you can mix and match, choosing what's important now and what's not, while benefiting from already existing SVG features? Is it possible that SVG followers don't do something which SVG does for them? Aren't there features, sufficiently aligned with SVG, which outperform directly working with other layers?
- alixanderwang 3y ago
  It's hard to get as performant as Figma does, not as straightforward as a rendering medium switch. What if webgpu lets me get Figma performance with my little 6 person startup team without the massive engineering man-hours Figma has spent on performance? Anyway, if it were high priority for us, we'd have done it already (switching to canvas/webgl). But right now it feels like buying a Quest when the Vision Pro is coming soon.
- rikroots 3y ago
  Figma is excellent at many things, but they struggle with accessibility. It's been a year since they wrote a blog post about their accessibility efforts so I don't know how far they've managed to solve the issues they identified - https://www.figma.com/blog/a-step-forward-in-our-accessibility-efforts/ https://www.figma.com/blog/a-step-forward-in-our-accessibili...
rapnie 3y ago
Nice! I found https://d2lang.com https://d2lang.com via your link, and thought it warranted a separate submission: https://news.ycombinator.com/item?id=36224084 https://news.ycombinator.com/item?id=36224084

rektide 3y ago

Google Docs document canvas is a tool. Most of the chrome & interface is html & works great. The switchover to canvas broke a ton of extensions. Chrome eventually went out & built a custom api to help users deal with some of the massive loss of functionality that switching off high-level html to go use lowest level html caused. But that took a ton of effort from Google, & the result is still a shadow of what was possible before. IMO, do the right thing for user agency & stick with higher level web stuff if you can, unless design truly compels it. Reinventing has many subtle pitfalls.

josephg 3y ago
> IMO, do the right thing for user agency & stick with higher level web stuff. Reinventing has many subtle pitfalls. This is great advice 99% of the time. But the browser has two big pitfalls which hurt google docs: 1. Browser rich text editing events are famously awful and inconsistent on different browsers and platforms. 2. Google docs wants the same document to render exactly the same on all OS / browser combinations. Thats not something that web browsers guarantee. In this case, I understand google's choice to build a custom renderer. I'm sure it was a massive effort for the team, but probably not quite as massive as working around all the browser quirks they were dealing with before. (From memory, before the canvas renderer, google docs ran their own rendering code then used CSS to absolutely position every single word in the document.)
- dekhn 3y ago
  I spoke to the original creator of Google Docs (from before it was Google Docs, https://www.theverge.com/2013/7/3/4484000/sam-schillace-interview-google-docs-creator-box https://www.theverge.com/2013/7/3/4484000/sam-schillace-inte...) and he confirmed what you recall; they had to write their own text rendering code because the browser does not implement the behavior required by a word processor (one example: flowing text around an image)
  - chrismorgan 3y ago
    That was long before they switched to canvas rendering, too: they were still just using contenteditable, though potentially with mild layout augmentation with things like absolute positioning and sizing of things (I don’t know). Flowing text around an image: the web has been able to do this for donkey’s years, it’s the float property. More recently, there’s the CSS shape-outside property that even lets you use non-rectangular crop: https://developer.mozilla.org/docs/Web/CSS/shape-outside https://developer.mozilla.org/docs/Web/CSS/shape-outside.

chrismorgan 3y ago

> Fun fact: Google docs is actually a canvas. This is often said, and almost as often misunderstood as referring to what I call the “pure canvas” approach where you throw away almost everything the browser gives you and start from scratch. Some key points about Google Docs, just to clarify (I’m not disagreeing): ① Only its document area is rendered with canvas; its chrome is all still regular HTML. ② It still uses the browser for text shaping and painting, just not for macro-layout (breaking paragraph into lines, &c.). (I expect that’s what this article’s subject would be doing too, but it’s part of common misunderstandings.) ③ Even things like scrolling are completely left to the browser: it’s not a single <canvas>, but a regular DOM scrolling area contains a bunch of <canvas> tiles. ④ The shunning of using HTML-with-contenteditable for the entire thing makes editing perform very badly (throughput, latency and jitter), and things like keyboard caret navigation behave non-natively in ways that will be very frustrating for people that actually use and care about this stuff (you get to relying on things behaving the same, like with touch typing, so things that get it wrong like Google Docs and LibreOffice (which gets it all wildly wrong) constantly grate). ⑤ They could just as easily use HTML or SVG rendering as <canvas> (while keeping their input and layout the same, so I mean still with all manual line breaks and that kind of thing). You’d get quite similar performance (though probably overall a little worse), and the same problems (since it’s the input layer that makes it slow and jittery—it just fundamentally can’t be as good in those ways as boring old contenteditable, given the current primitives). In fact, it’d mildly surprise me if they didn’t have an SVG or HTML renderer handy, or did in the past and could revive it to complete indistinguishable functionality within a day or two (even if hacky). (I wrote a little more at https://news.ycombinator.com/item?id=33863185 https://news.ycombinator.com/item?id=33863185.)

rektide 3y ago
This is one of the best comments I've read on the much ballyhood Google Docs canvas! Favorited. I expect I'll be referencing this a good bit over the years.

paulddraper 3y ago

You start with SVG Then you go to Canvas Then you go to WebGL Source: Early engineer at Lucidchart

thomasfromcdnjs 3y ago
aha love this
mkl 3y ago
Then you go to WebGPU, I expect.
- paulddraper 3y ago
  Not for graphics
ygra 3y ago
Similar journey here (yWorks, with a diagramming library, too). In our case the journey comes with drawbacks, though. Yes, WebGL allows for larger graphs, but it also does not support the flexibility (to customers) the other options offer.
thekenwheeler 3y ago
it depends. canvas is typically much more cpu friendly. and does a way better job with text. (2d)
hicksyfern 3y ago
Author here. For sure. That’s actually what we’re likely to do as the basemap rendering is done in webgl