Interestingly, I've been hearing a lot of native speakers making the same mistake lately. Maybe it's because I live in San Francisco, and we hear foreigners make this mistake all-day-long - now it's rubbing off on people.
Ah ok, I understand. Yes, the docs now look too much like a giant wall of text. My plan for 0.4 is (among other things) to organize the documentation a little better, and I will also add the examples inline
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.
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?
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.
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?".
So is the primary purpose of the library to save you from having to type "M 0 0 L 1 0 L 1 1", instead letting you type "Path().moveto(0, 0).lineto(1, 0).lineto(1, 1).print()"?
Well, if you are familiar with SVG and you just want to write at this level of abstraction, yes. But of course, this is only the lowest level API.
The actual purpose of library is to provide with more complex shapes and graphs, while still leaving you the possibility to write a path by hand, should the need arise.
Moreover, consider that even if you stay wit the lowest level API, the data you have may be dynamic, so that it may be easier to call a function with parameters at every frame, rather than hand-concatenating string (although this use is admittedly rather limited)
I guess you didn't make it more than a third of the way through the README.
This looks super useful for the many circumstances where interpolating things into strings to generate SVG paths is quite unpleasant (ie. anything much beyond "M #{x} #{y}").
Not sure you actually meant it as a question, but just to spell it, in case someone might actually consider it a genuine question.
SQL query builders can have the capability that they make queries composable.
Sending a string around will require you to do double and tripple check for parameters, logical combinations and what not in every step of a composable action.
Besides that, most SQL query composers assist you in isolating parameters from query, and this protects you from SQL injection.
Looks nice, but I would really prefer the samples on the sample-site to be in plain Javascript.
Coffescript isn't for everyone, on the web Javascript should be considered the lingua franca.
By all means, keep the Coffescript if you like, just don't limit it to just a non-standard language web-wise. I can test JS in my browser, with coffescript... Not so much.
Parent is referring to the "demo application", though I personally disagree that one should worry about it on the demo app. The docs sure, but the demo app is readable enough even if you're not a coffeescript aficionado.
If this is viable for making dataviz, it will be a great relief to get away from D3's disorganized mishmash of data wrangling and dom manipulation code!
This is a brilliantly conceived library. It does one thing well and even within that, decomposes into clear layers of abstraction. I've been using it at work and found the experience much nicer than the various high-level charting libs built on top of d3.
Only complaint is that some of the charts are a bit lacking in features (no stacked bar charts, for example). But it looks easy to hack on, which I'd take over a zillion different options.
I just recently wrote something that does the lowest layer of this (generating SVG path strings) and didn't consider it "Show HN" worthy... https://github.com/akx/gravelly.js
(And no, this isn't an attempt at an underhanded sneaky "Show HN", just a thought.)
28 comments
[ 3.6 ms ] story [ 77.0 ms ] threadhttp://andreaferretti.github.io/paths-js-demo/
It is mentioned in the README (How does it look like?) but maybe it is not apparent enough
"How does it look like" is a minor but grating error to native english speakers.
The rest of the document looks good, as does the library.
They are simple enough to include the results right next.
- 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.
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.
The actual purpose of library is to provide with more complex shapes and graphs, while still leaving you the possibility to write a path by hand, should the need arise.
Moreover, consider that even if you stay wit the lowest level API, the data you have may be dynamic, so that it may be easier to call a function with parameters at every frame, rather than hand-concatenating string (although this use is admittedly rather limited)
This looks super useful for the many circumstances where interpolating things into strings to generate SVG paths is quite unpleasant (ie. anything much beyond "M #{x} #{y}").
SQL query builders can have the capability that they make queries composable.
Sending a string around will require you to do double and tripple check for parameters, logical combinations and what not in every step of a composable action.
Besides that, most SQL query composers assist you in isolating parameters from query, and this protects you from SQL injection.
Coffescript isn't for everyone, on the web Javascript should be considered the lingua franca.
By all means, keep the Coffescript if you like, just don't limit it to just a non-standard language web-wise. I can test JS in my browser, with coffescript... Not so much.
There's a nice example of using it with a declarative templating library like react or ractive.js here: http://mlarocca.github.io/01-22-2014/pathsjs_ractive.html
Only complaint is that some of the charts are a bit lacking in features (no stacked bar charts, for example). But it looks easy to hack on, which I'd take over a zillion different options.
I just recently wrote something that does the lowest layer of this (generating SVG path strings) and didn't consider it "Show HN" worthy... https://github.com/akx/gravelly.js
(And no, this isn't an attempt at an underhanded sneaky "Show HN", just a thought.)