Live data from Hacker News

From SVG to Canvas – A new way of building interactions

felt.com

31–40 of 97 posts

Re: From SVG to Canvas – A new way of building interactions

#31
post #10

Earlier quoted context omitted.

> 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 combinati…

> 2. Google docs wants the same document to render exactly the same on all OS / browser combinations. Thats not something that web browsers guarantee. Nor is it something Google Docs guarantees, since it still uses the browser for font shaping and rendering. The easiest way to demonstrate this is in Firefox, Settings → Fonts → Advanced → untick Allow pages to choose their own fonts, instead of your selections above ,…

Ok, sure - you got me. If you mess with obscure browser options, you will successfully change how google docs renders content. But I suspect all of the people who select that option would fit in one meeting room, with a sign out front from google which says "WONTFIX".

One thing people do do all the time in word processors is mash enter until the next bit of content ends up at the top of the following page. If a user does that, then they print their document from a different computer, it should print correctly. The next content should appear exactly at the top of the next page. If the word processor does anything else, users will be frustrated and blame the software. Word and Docs both put in a ton of engineering effort to get this right.

(Educated users will insert a page break instead, but plenty of users don't know about page breaks. They still expect their documents to render correctly.)

Re: From SVG to Canvas – A new way of building interactions

#32

> These InteractionHandlers are just objects satisfying a specific TypeScript interface. They’re not coupled to React or hooks or anything like that, which feels quite freeing, honestly. There’s no worrying about stale closures or dependencies or hooks rules - it really is just TypeScript. This is a great example of "fighting the framework". React + SVG got them from nothing to a working product. But then they had to…

It's unfortunate that coevolution like this usually lands in a very suboptimal start. If we tore it all down and started from what we knew we'd have much better things. Occasionally stuff like that happens, but it's really hard to fight against the momentum of decades of shit

Re: From SVG to Canvas – A new way of building interactions

#33
I’ve been building a kinopio.club clone in Phoenix LiveView and the problems the author faces align with my experience from working with uis that require explicitly setting element position for the document. Having to manage all of the imperative handler logic was a huge pain on the JS side. I had also given myself the limitation to not use React for more complex Phoenix Hooks. It’s all native document rendering with the only dependency being x-state.

Moving the mouse event handler logic out into a state machine was where I found myself going in comparison to this author’s approach. I was pretty tickled by how much more maintainable it had been than the first time I had implemented it. x-state was by no means a requirement but it had a handful of features I didn’t feel like building for the current project.

I can absolutely believe that this is worth the effort, especially considering the fact that the team works with maps so much. The mental model presented in the article would be far easier to grok when working in the codebase than having to deal with the somewhat tricky to remember Event api provided by browsers for these types of use cases.

Others are mentioning fighting the framework but this is still a pain without React. But of course adding in React on top of all of this would make it harder.

Re: From SVG to Canvas – A new way of building interactions

#34

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.

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

aha love this

Re: From SVG to Canvas – A new way of building interactions

#35

ctrl+f "accessibility" in part 2: zero results ctrl+f "accessibility" in part 1: zero results Does anyone care about digital access to content for disabled people ? Or about the ADA ? Svg to canvas without any answer for accessibility is backwardness, plain and simple. You are letting down anyone who's deaf, blind or has trouble hearing or seeing, anyone who does not know how to read, has motor impairments, temporary…

[flagged]

Re: From SVG to Canvas – A new way of building interactions

#36
post #30

It sounds like most of their problems were with using the browser SVG event handlers (or perhaps the framework). They could have written their own event system for SVG (e.g. using event handlers on document), which would have fixed the gripes they blamed on SVG events. They wrote their own event system for canvas, so probably not much more difficulty in coding work? Performance is the remaining issue that isn’t clear…

Author here.

I know this is the orange site and we have to expect this type of comment, but still…

I’ve been building software for more than 20 years, and using React since it came out.

You’re right that this event handling system isn’t exclusive to canvas. But then I’m not sure if you read the first part of the article where we talk about the other big reason: performance.

Your assertions that setTimeouts should be banned show immaturity. There are some cases where certain browsers do things in a different order and you really are required to use a hack like that.

You also neglect the fact (and this also points to your immaturity) that products are built by a number of people over a long period of time, with different constraints on them as things change.

The SVG approach was done for good reasons and the code made sense for what it was for initially. Then things got more complex and people started making more complex maps.

What we also found is that the complexity of maps people made increases with our performance gains: the faster the app is, the more people do with it.

I haven’t got time to go into everything either in the articles or certainly this reply, but I’d ask you to have a look at yourself and decide if you really want to be That Guy on HN.

Re: From SVG to Canvas – A new way of building interactions

#38

ctrl+f "accessibility" in part 2: zero results ctrl+f "accessibility" in part 1: zero results Does anyone care about digital access to content for disabled people ? Or about the ADA ? Svg to canvas without any answer for accessibility is backwardness, plain and simple. You are letting down anyone who's deaf, blind or has trouble hearing or seeing, anyone who does not know how to read, has motor impairments, temporary…

Unless they have a legal requirement to provide product for disabled people, why would they care? It's a huge investment for very little output, unless this product is specifically targeted.

Re: From SVG to Canvas – A new way of building interactions

#39

ctrl+f "accessibility" in part 2: zero results ctrl+f "accessibility" in part 1: zero results Does anyone care about digital access to content for disabled people ? Or about the ADA ? Svg to canvas without any answer for accessibility is backwardness, plain and simple. You are letting down anyone who's deaf, blind or has trouble hearing or seeing, anyone who does not know how to read, has motor impairments, temporary…

Tangential question: how does accessibility work in Google Docs after they've switched to canvas?

Or in Google Maps, which would be a much closer parallel?

Re: From SVG to Canvas – A new way of building interactions

#40
post #39

ctrl+f "accessibility" in part 2: zero results ctrl+f "accessibility" in part 1: zero results Does anyone care about digital access to content for disabled people ? Or about the ADA ? Svg to canvas without any answer for accessibility is backwardness, plain and simple. You are letting down anyone who's deaf, blind or has trouble hearing or seeing, anyone who does not know how to read, has motor impairments, temporary…

Tangential question: how does accessibility work in Google Docs after they've switched to canvas? Or in Google Maps, which would be a much closer parallel?

While not directly related to your question, Google docs' switch to canvas broke my custom dark theme which I'd been maintaining for years, and several others were also using. This had been the main draw for me switching to Google docs in the first place and they took it away. I'd argue this is much less accessible as I can't use the product at night. Ironically, I feel like I've experienced more bugs after the switch than before
Post reply on HN