5 ms·

Show HN: Paths.js – Generate SVG paths for geometric shapes

86 points by pathsjs 12y ago

imaginenore 12y ago
Your documentation needs images (or, you know, actual SVG).
- pathsjs 12y ago
  Hi, you can find a working demo on http://andreaferretti.github.io/paths-js-demo/ http://andreaferretti.github.io/paths-js-demo/ It is mentioned in the README (How does it look like?) but maybe it is not apparent enough
  - catfive 12y ago
    I reccomend changing the title of that section to either "How does it look?" or "What does it look like?" "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.
    - pathsjs 12y ago
      Done, thank you!
    - bsimpson 12y ago
      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.
  - imaginenore 12y ago
    I'm talking about the documentation examples, not the demo. They are simple enough to include the results right next.
    - pathsjs 12y ago
      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
girinambari 12y ago
Any core differences between Path.js and D3?
- pathsjs 12y ago
  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.
  - girinambari 12y ago
    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 12y ago
      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.
sidcool 12y ago
Inexplicable hostility towards this post. It's quite a handy library.
dgreensp 12y ago
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()"?
- pathsjs 12y ago
  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)
- bshimmin 12y ago
  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}").
- mambodog 12y ago
  Consider, why do people use SQL query builders when you could just use a string?
  - josteink 12y ago
    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.
- untog 12y ago
josteink 12y ago
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.
- untog 12y ago
  All of the example code appears to be JS?
  - jasallen 12y ago
    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.
deleted 12y ago
[deleted]
ffn 12y ago
Hey, this is actually pretty useful. Thanks
woah 12y ago
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!
chrisdevereux 12y ago
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. 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 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.
akx 12y ago
Hm. 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 https://github.com/akx/gravelly.js (And no, this isn't an attempt at an underhanded sneaky "Show HN", just a thought.)
spb 12y ago
This is OK, but it would be a lot more useful if the low level API used the standard names from CanvasPathMethods for compatibility with Canvas and Path2D: http://html5index.org/Canvas%20-%20CanvasPathMethods.html http://html5index.org/Canvas%20-%20CanvasPathMethods.html

86 points by pathsjs 12y ago

imaginenore 12y ago

Your documentation needs images (or, you know, actual SVG).

pathsjs 12y ago
Hi, you can find a working demo on http://andreaferretti.github.io/paths-js-demo/ http://andreaferretti.github.io/paths-js-demo/ It is mentioned in the README (How does it look like?) but maybe it is not apparent enough
- catfive 12y ago
  I reccomend changing the title of that section to either "How does it look?" or "What does it look like?" "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.
  - pathsjs 12y ago
    Done, thank you!
  - bsimpson 12y ago
    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.
- imaginenore 12y ago
  I'm talking about the documentation examples, not the demo. They are simple enough to include the results right next.
  - pathsjs 12y ago
    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

girinambari 12y ago

Any core differences between Path.js and D3?

pathsjs 12y ago
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.
- girinambari 12y ago
  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 12y ago
    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.

sidcool 12y ago

Inexplicable hostility towards this post. It's quite a handy library.

dgreensp 12y ago

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()"?

pathsjs 12y ago
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)
bshimmin 12y ago
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}").
mambodog 12y ago
Consider, why do people use SQL query builders when you could just use a string?
- josteink 12y ago
  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.
untog 12y ago

josteink 12y ago

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.

untog 12y ago
All of the example code appears to be JS?
- jasallen 12y ago
  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.

deleted 12y ago

[deleted]

ffn 12y ago

Hey, this is actually pretty useful. Thanks

woah 12y ago

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!

chrisdevereux 12y ago

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

akx 12y ago

Hm. 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 https://github.com/akx/gravelly.js (And no, this isn't an attempt at an underhanded sneaky "Show HN", just a thought.)

spb 12y ago

This is OK, but it would be a lot more useful if the low level API used the standard names from CanvasPathMethods for compatibility with Canvas and Path2D: http://html5index.org/Canvas%20-%20CanvasPathMethods.html http://html5index.org/Canvas%20-%20CanvasPathMethods.html