Building Better Interfaces with SVG (2015)

Re:Building Better Interfaces with SVG (2015) by aidos on Monday January 09, 2017 @10:42AM (#13357094)

It is different but I guess my point was that SVG is a brilliant tool for developers. We (generally) approach problems in a programatic way, and SVG allows you to do that for graphics, which is incredibly liberating.

Performance is good! I've definitely had to come up with some pretty clever hacks but it feels smooth once the SVG has loaded. In our case we need to be able to zoom in to arbitrary levels and still have crisp vectors.

Here's an example of a document with about 150,000 dom nodes. You'll see that it's a little sluggish when you're zooming in and out but after it catches up it's really quick to move around. Most of our documents are much smaller than this so there's no real delay on zoom in those cases.

https://dl.dropboxusercontent.com/u/233998/example_movement....

[ Parent | on HN ]

Re:Building Better Interfaces with SVG (2015) by jordache on Monday January 09, 2017 @10:51AM (#13357174)

is it suppose to be device agnostic? I'm on a core i7 device so it's not a good indicator of how performant a given web solution is.

Generally speaking when you have that many elements, you've surpassed the threshold of what SVG is intended to do. Canvas can be a seamless replacement for SVG without any tradeoffs, other than additional build complexity

[ Parent | on HN ]

Re:Building Better Interfaces with SVG (2015) by aidos on Monday January 09, 2017 @11:13AM (#13357376)

The problem with canvas is that our users need to be able to zoom very deep and still have crisp rendering. We wouldn't get that with canvas unless we rendered to a really huge canvas, right?

Yeah, the machine is definitely going to make a difference, though as I say a) most our documents are smaller than this and b) we have ways of speeding up bigger documents where required.

Sure, SVG isn't made for this, but it works. Going to canvas would mean a load of extra work and you can be sure there would be other tradeoffs and issues to work around. Additionally, SVG is super hackable. You can work with it easily front and back end. You can read it and understand what's going on.

And hey, if your users are happy.... :-)

http://www.capterra.com/takeoff-software/spotlight/144811/Co...

[ Parent | on HN ]

Re:Building Better Interfaces with SVG (2015) by jordache on Monday January 09, 2017 @01:25PM (#13358466)

i think you can redraw the canvas when zooming in. So even if the canvas dimension is finite, you can redraw it with infinitely higher resolutions of data.

[ Parent | on HN ]

Re:Building Better Interfaces with SVG (2015) by aidos on Monday January 09, 2017 @03:17PM (#13359436)

I get the idea, but then I'll be doing the work that the SVG engine is currently doing. So really, here you're trying to get canvas to do something that it wasn't designed to do - which is weird, because that was your argument against svg in the first place. A quick google reveals the general solution of "sounds like you should be using svg." [0]

Given that svg 100% works for my usecase, I don't have any reason to attempt anything else at the moment. People give svg a hard time about performance and I think that's counterproductive. My suggestion is that everyone should give it more of an honest shot and I suspect they'll find that there are plenty of cases when it becomes the first tool they reach for.

[0] http://stackoverflow.com/questions/19284304/how-redraw-on-ca...

[ Parent | on HN ]