This seems to take the declarative nature of SVG and make it more imperative, like HTML5 Canvas, even though it ironically uses a virtual DOM implementation under the hood. For my React projects I chose SVG over canvas because I could write my layout declaratively, and avoided imperative manipulation libraries. How do you modify existing SVG shapes with this library?
It's a shame React Art isn't mentioned more (https://github.com/reactjs/react-art). I'm pretty happy with the results from it, and it's a bonus that it works on iOS as well as drawing to Canvas, SVG, or VML on the web.
It doesn't support some of the more advanced features of SVG, but that's the trade-off for wider support.
I have basic text support for now, and will release a Rune.Font plugin next week that supports webfont loading and access to the font vectors. Line wrapping is also on the TODO list.
The server side rendering looks really interesting (I've been getting into SVG for mobile web graphics). Are there other SVG libs that do server side rendering, or is this unique as it seems?
You might be interested in paper.js: http://paperjs.org/ which is an evolution of Scriptographer. It has full support for the usual add, subtract, difference sort of boolean shape operations. Beyond that difference, I'm still trying to suss out the differences between rune.js and paper.js. Rune feels like it might provide more grid and typesetting tools, but still, the lack of boolean shape operations is disappointing.
Paperjs looks interesting. The major downside is that it is a separate programming language. It really makes me wonder why the authors could not separate concerns and make a self-contained library for those boolean shape operations.
Anyway, echoing andrewray, what’s the point of this? It seems no easier than just working with SVG directly. It’s considerably less powerful than e.g. using D3.
On a side note, regardless of the alternatives, or that there is a 'better' way to do things, I found this project very impressive.
The author has released their work open source (https://github.com/runemadsen/rune.js/blob/master/LICENSE). It is people like the author that drive large parts of our industry, with generous donation of their spare time. Given this, it is frustrating to see the unhelpful choice of words of people in this comments section.
If you read the about page, I have a very detailed explanation of why I created this project. First of all, I'm using this library as a basis for teaching my class on algoritihmic graphic design (http://printingcode.runemadsen.com/), and I cannot expect the students to know about the DOM or SVG. Also, there's a ton of functionality in the library that you don't get from using SVG directly: powerful color conversion and manipulation, a scene graph, debug mode to visualize bezier curvers, grid system support, etc.
I'm working on Safari support, but it's still a somehow young library.
I wasn’t and still am not trying to be rude – it looks like a neat class, the pages at http://printingcode.runemadsen.com/lecture-intro/ are filled with lovely examples, it’s clear a bunch of work has gone into the library, and it’s great to release code as open source – but I still don’t quite understand.
SVG already has a certain kind of “scene graph”. It’s made up of nested groups of objects in the DOM, where each group can accept an affine transformation via a 3x3 matrix (or an explicit rotation, translation, or scale). Like the rest of SVG, working with this can be done either declaratively or procedurally.
Is the goal of this library to be low-level building blocks on top of which students will build a more abstracted / higher-level library?
(P.S. With respect to color, I strongly urge everyone to avoid HSL/HSV to the extent possible (I wrote most of this Wikipedia page if that gives me any credibility https://en.wikipedia.org/wiki/HSL_and_HSV). These color models are a trivially thin shim over RGB, and are not directly relevant to human color vision. Working with them is unintuitive and tends to lead artists to severe misconceptions. Itten’s color theory is no better: Itten was a dabbler and a mystic who ignored the known color science of his time and mostly just made stuff up without much apparent reasoning – in my opinion much less capable with color than other Bauhaus artists such as Paul Klee or Wassily Kandinsky or teachers such as Josef Albers. Albers was a great teacher because (unlike the didactic Itten) he didn’t try to impose his vision, but built his pedagogy around making students learn for themselves through direct experience doing studies with colored paper.
Better is to use a system more aligned with the dimensions of human color perception, such as the Munsell color system, CIELAB, or CIECAM02. If you want a Javascript implementation of the latter, I put one up at https://github.com/jrus/chromatist a few years ago. But there are also several javascript libraries around for interacting with the simpler CIELAB and CIELUV models.
If you have questions about human color vision, color reproduction technologies, color models, etc. feel free to email me, I’ve spent several years studying those in great depth, and would be happy to recommend books or other resources.)
I have to disagree with you on most of the above. You cannot expect students who want to learn how to code to also learn about the DOM and write things like path DOM nodes by hand. This library is made to abstract DOM-specific functionality into something that they know from known and tested tools like Processing. There is a world of difference between writing SVG's by hand (or generating them in pure JavaScript) and using Rune.js. Just try to write the following example in pure JS, and I'm sure you'll see what I mean:
I agree that CIELAB is a very useful color model, which is why I also teach the difference in my class. But HSV is a great way to move away from rgb(255, 255, 255), and I've had nothing but success using it over the last 5 years in my graduate classes.
