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()"?
Show HN: Paths.js – Generate SVG paths for geometric shapes
11–20 of 29 posts
Re: Show HN: Paths.js – Generate SVG paths for geometric shapes
#12So 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)
Re: Show HN: Paths.js – Generate SVG paths for geometric shapes
#13So 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()"?
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}").
Re: Show HN: Paths.js – Generate SVG paths for geometric shapes
#14Any core differences between Path.js and D3?
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,…
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?
Re: Show HN: Paths.js – Generate SVG paths for geometric shapes
#15Any core differences between Path.js and D3?
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,…
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?".
Re: Show HN: Paths.js – Generate SVG paths for geometric shapes
#16So 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()"?
Consider, why do people use SQL query builders when you could just use a string?
Re: Show HN: Paths.js – Generate SVG paths for geometric shapes
#17Earlier quoted context omitted.
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,…
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.
Re: Show HN: Paths.js – Generate SVG paths for geometric shapes
#18Looks 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.
Re: Show HN: Paths.js – Generate SVG paths for geometric shapes
#19[deleted]
Re: Show HN: Paths.js – Generate SVG paths for geometric shapes
#20So 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()"?
Consider, why do people use SQL query builders when you could just use a string?
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.