81–90 of 97 posts
What’s with all the tags in the text?
element would be a better choice, but meh, not a big deal)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.
I'm interested in Canvas - I write a lot of data viz in SVG. I find it to have lots of warts, but provide lots of value. I'm interested by this article and wish to challenge it too, here's my thoughts. Maybe I'm an idiot though - where is this library? I can't find it on their GitHub or linked from the articles > In the SVG world, we use CSS z-index to place the DragBox at the back and the SelectionFrame at the front…
Nothing wrong with a long comment, but it might facilitate discussion to break your long comment up into a few top level comments.
> 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 almost like there's no silver bullet, and neither management nor engineering are capable of sticking to one set of trade-offs. Instead, the product thrashes back and forth while trying to accommodate whatever the current feature demands happen to be, with no one applying enough higher order thinking to see that there is no end-state that satisfies everything. Just endless busy work, a few more paychecks, and act…
You give people a more powerful product and they’ll use the power.
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…
Shortly after this was merged to main (though under feature flag) another dev had to fix something and commented something like “I just fixed X in two minutes which would have taken me hours before”
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…
Author here. Absolutely right what you said about being easier to grok. Shortly after this was merged to main (though under feature flag) another dev had to fix something and commented something like “I just fixed X in two minutes which would have taken me hours before”
Plus the overall app state is done as a kind of reverse state machine where we derive the status from various app states. I would like to change this to not be backwards one day but it was too big of a lift to change everything at once!
Super late to this but they mention element overlap in SVG making thinks like drag & drop hard. That's their "interactivity" gripe, and the one that for me carried the most weight. I'd be very interested to get more discussion on this specific issue, of handling mouse events well in SVG. The particular example felt contrived, in that I might just apply a class HasPointerEvents to every element and change the pointer…
There are some more interesting but less easy to explain to a broad audience examples.
One is having “nearest the pointer” hovering logic rather than rectangles or circles overlaying each other.
Another is hovering line segments and the projecting the nearest hovered point onto the line. That was approximated with SVGs before and was just kind of a bug.
Another example is allowing some “wiggle room” for touching elements without having to render SVGs multiple times with transparent elements and stuff like that.
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
I'm interested in Canvas - I write a lot of data viz in SVG. I find it to have lots of warts, but provide lots of value. I'm interested by this article and wish to challenge it too, here's my thoughts. Maybe I'm an idiot though - where is this library? I can't find it on their GitHub or linked from the articles > In the SVG world, we use CSS z-index to place the DragBox at the back and the SelectionFrame at the front…
Aside from that, yes z-index was because there are multiple SVGs rendered. We also had non-SVG stuff for each element like inputs and stuff, plus it was just like that when I got here, and it doesn’t seem unreasonable to me.
Another thing was you said it’s a problem React solves rather than creates. This is very clearly not true.
If you add event listeners to every component which is big-standard React, you end up with 1000s or tens of 1000s of event handlers often doing almost nothing. And sure, JavaScript can do 10_000 lots of almost nothing very quickly, but it’s noticeable when you’ve got a strict frame budget.
Earlier quoted context omitted.
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…
Yeah, I should not have been so inflammatory and I should have limited my comments to where I have deep experience. The comments on preventDefault() and setTimeout() in particular repeat my own hard-won experiences: it is unfortunate you had to experience the same pain. In the previous article, maybe the first third is you fighting your framework, which is admittedly what happens to us all if we are on the bleeding e…
The thing is, for a lot of it I can’t go into huge amounts of detail otherwise I could write a book on it.
You’re right that the interaction system could keep the SVG as a renderer, and I don’t remember whether that point ended up in the final version! But I have done that locally just for fun to see if it works and it does.
I can give you one example of something that’s too much to go into in a high-level article: SVG and canvas are both very slow at drawing dashed lines. With mapping software, the overall zoom level gets to something like 50 million percent or something ludicrous, and what that means is often you have literal kilometres of dashed lines drawn off screen just if one pixel is on screen for that geometry.
With SVG the only real way to get good perf is to use transforms to move things around when you’re not zooming, or scale them when you are. This doesn’t work if you then need to viewport-clip your lines – you need to render every frame and that gets really slow. With canvas it’s just not a problem, I guess partly because you’re not always making enormous path strings on every frame.
Another example is viewport culling. To avoid thrashing the DOM as you zoom, you don’t really want to be adding and removing elements because it gets janky. We had a viewport culling solution in SVG land with a big dynamic CSS style switching each element on and off which alleviated the browser’s painting workload but it feels hacky as hell. With canvas, you just intersect the viewport with the world and that’s your display list so you render each element in that list. Much simpler model.
Seriously there’s so much involved in making this stuff work well I could literally write a book, but I had to settle for a 2 part article where I had to pick the simplest examples and shortcut some of the detailed explanations.
After all, it’s just a dev blog not an academic paper.