[pathsjs]

Well, there are a few. The main one is that Paths.js only builds a descriptor of your path (the string that goes into the "d" attribute of the SVG path tag), and leaves to you the actual rendering. This has, for me, a few benefits:

- it is easier to integrate into frameworks like React or Angular (because both these frameworks and D3 think they have control on what goes rendered in the page)

- you can use templating, which leads to a declarative approach, instead of the imperative approach of D3

- it only involves pure functions (no side effects) which makes it easier to unit test your graphics

- not doing the rendering means you can use Paths.js also on Node

Of course, D3 is more mature and complete at this point, and it is easier to find examples and documentation. I hope eventually to fill the gap, at least partially.

Another difference, although minor, is that D3 includes a lot of utilities (parsing CSV, doing Ajax requests, working with dates and much more...). This may be a benefit for you or not. I prefer to have small building blocks, and Paths.js is only concerned with generating paths.

[mshark]

You should have a section in your README discussing differences from D3. I've used D3 a little and understand some of the pain points. Looking at your library I'm asking myself "why would I abandon D3 for this?".

[girinambari]

Thanks! make sense. I have observed that lot of JS based SVG libraries having memory leaks and slowing down browser over the time, how paths.js behaves in this context?

[pathsjs]

Well, I certainly hope Paths.js does not have memory leaks. Since it is made of functions without side effect, with the ultimate purpose of producing a string, every intermediate result should be eventually collected.

SVG itself is certainly not the fastest technology around, considering that the browser has to adjust the layout of the HTML and SVG together. Still it seems to work just fine for a few charts.

The only exception to the above is the Graph chart. That one is currently hideously slow, and one of the tasks for release 0.4 is to optimize it. The algorithm does not look too bad to me, but probably I am producing a lot of intermediate garbage which slows down the whole animation. I will have to look into some form of object pooling.