Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From SVG to Canvas – A new way of building interactions

felt.com

Post reply on HN
Print view View original

91–97 of 97 posts

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

#91

Post by sdiupIGPWEfh »

hicksyfern wrote: post #84
sdiupIGPWEfh wrote: post #63

Earlier quoted context omitted.

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…

I would agree with you if it was t for the fact that we’ve seen a big increase in the number of complex maps being made since the change. You give people a more powerful product and they’ll use the power.

Glad to hear it's working out! Hope it continues to prove to be an exception to the rule, then.

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

#92

Post by marcus_holmes »

aa-jv wrote: post #49
marcus_holmes wrote: post #9

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

Anecdotal counter-argument from applying frameworks successfully over decades: the framework is there to help us get up and running .. we get up and running .. we build out the weaker parts of the ship while we're sailing, only when the work in framework no longer applies .. the app grows .. the user base grows .. the framework grows ..

> the framework grows ..

I've seen too many teams fight Rails (in particular) to implement new product features to agree with this. The framework never grows, it stays the same size and eventually becomes a straitjacket for the product.

Like I said, though, this isn't a reason to not use a framework at the start. As long as everyone realises that at some point it'll need to be rewritten.

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

#93

Post by robocat »

hicksyfern wrote: post #90
robocat wrote: post #41

Earlier quoted context omitted.

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…

Appreciate the response. 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 i…

Thanks heaps for the details.

It is difficult to write a good blog post, and the extra detail is interesting.

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

#94

Post by aa-jv »

marcus_holmes wrote: post #92
aa-jv wrote: post #49

Earlier quoted context omitted.

Anecdotal counter-argument from applying frameworks successfully over decades: the framework is there to help us get up and running .. we get up and running .. we build out the weaker parts of the ship while we're sailing, only when the work in framework no longer applies .. the app grows .. the user base grows .. the framework grows ..

> the framework grows .. I've seen too many teams fight Rails (in particular) to implement new product features to agree with this. The framework never grows, it stays the same size and eventually becomes a straitjacket for the product. Like I said, though, this isn't a reason to not use a framework at the start. As long as everyone realises that at some point it'll need to be rewritten.

Well, thats the case where too much responsibility is being off-loaded onto the framework providers and someone hasn't quite grok'ed TANSTAAFL. I never use a Framework I won't feel comfortable modifying ..

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

#96

Post by rektide »

hicksyfern wrote: post #87
rektide wrote: post #79

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…

Author here. The example given is slightly contrived. A more realistic example involves large polygons that you zoom “inside” or locked elements overlaying active ones. But I had to try to give an example without a ton of context. 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 o…

Circling back just to say this was really fun & interesting stuff. Appreciate you responding with these cases!

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

#97

Post by deterministic »

Frameworks are great if your application fits perfectly into the subset of applications that the framework was designed for. However the moment your applications grows beyond the design boundaries of the framework, you might end up in a situation where you have to drastically rewrite the app or even do a complete rewrite.

Which is why I have always been more productive long term using my own frameworks. It takes longer to get started, but once you get the train going, nothing stops it.

Post reply on HN