Was pretty confused at first about why this would have a Backbone dependency until I looked through the source and saw they they're just pulling Backbone.Events.
I think it says a lot about Backbone that people are doing things like that. Modularity is nice.
That's not a big surprise. jQuery's events use native browser events behind the scenes. Which is nice for dom-oriented plugins; you get bubbling for free and all the native event listeners just work. It's got a pretty fair amount of overhead though. Backbone's events are just a pure JS event emitter implementation.
I'm curious, though, why they added an external dependency instead of just inlining a solution. There's a couple of good MIT licenced barebones implementations[1][2] floating around, and it's pretty straightforward to reimplement yourself in an hour or two if you prefer.
This landing page and documentation is just beautiful. Simple hashtag nav, soft colors, great header, and good examples. Only suggestion would be to have a way to link to individual methods in the docs w/ hashes. I really commend the effort here.
I've been monitoring the development of pixi.js mostly because it uses WebGl but automatically fails-over to canvas if Webgl support isn't available.
I was even contemplating using pixi for some experimental web-animation things (non-game related) since I didn't find any other webgl-with-canvas failover drawing APIs.
Along these lines I've written projects in canvas only to realize later I should've written in SVG. One of the aims of two.js is to afford a canonical API for the developer. So the idea is that if you're rendering lots of particles and not doing any manipulation to individual particles, canvas or webgl will render faster than svg. Two.js aims to make it easier to test and switch around between the contexts. However, I should caveat all of this with two.js is very nascent...
From my understanding Raphael is specific to the SVG context. Two.js is renderer agnostic, you can choose whether it draws in SVG, canvas, or webgl. This is one of many differences between the two.
Rapahel does SVG but most importantly it also renders VML when SVG is not supported by the browser, as a result it supports IE6+ unlike two. (don't get me wrong I still think two is great)
Not the same - e.g. rotating a set of elements causes each individual element to rotate around their individual centers, rather than causing the group to rotate around a central pivot.
Unfortunately Kinetic is (and probably always will be) canvas-based, which is already a limiting factor. Which is unfortunate as it's API is really rather nice and I wish I could combine it with WebGL!
Kind of random, but this looks very similar to Ming (php plugin) which renders flash in a very similar manner. I open-sourced a library for rendering animations using it just a few days ago (although the project itself it 6 years old) - https://github.com/erbbysam/ming-icanimate
Thanks for this, I'm probably going to spend some time recreating that ming-icanimate rendering system with two.js
Very nice! I'm also working on a similar scene graph (Canvas/SVG, WebGL soon), which also has bounds, DAG-support, and implicitly inserts the needed layers for performance (http://phetsims.github.io/scenery/).
I look forward to seeing what other performance optimizations I may be missing!
I started a project in SVG a few months ago, and searched for a library to use. Dojo's GFX is a great library, with comprehensive support of the native features (Text, etc).
That said, I'm planning on switching to good-old DOM, the performance of SVG was underwhelming to me. Also, the lack of text-wrap.
I'd be curious to see the performance differences between this drawing on 2d canvas, webgl and similar code in plain JS. Mostly curious at that webgl benchmark
From my gut, I'd say that the WebGL renderer is fast at rendering lots of shapes with only translation / rotation transformations applied to them. SVG is highly optimized on Webkit and handles shape morphing really well and so the SVG renderer handles that really well. Canvas sits somewhere in between the two.
Not familiar with forcast.io — thanks for sharing! Before I got into web development I worked at a company called Prologue doing motion graphics in After Effects and Photoshop. Even if you've never heard of them, you've probably seen their work: http://prologue.com/
This background is much of the motivation for the library.
Ah cool. Yeah, I instantly thought of use cases like Forecast.io's weather animations for your library. I think this is a _major_ trend about to explode, and approaching it with a JS library instead of animated GIFs seems like it has big potential.
Check out www.forecast.io to see the UI polish I'm talking about.
Be careful — two.js is only for drawing things to the browser. It doesn't do much else. There are many game libraries/fraemworks available, both 3d and 2d.
That doesn't make it any less useful at all? I am very fond of abstractions and modularity. Two.js is a nice rendering component. You can easily add an input component on beside of it if need be.
Indeed! I just wanted to be clear and not over promise anything. If you're interested in make input components that talk with Two.js I recommend taking a peak at /src/shape.js and /src/vector.js this is where the bindings are created. I believe that this form of binding allows for a lot of creativity when it comes to visualizing positions.
I think it says a lot about Backbone that people are doing things like that. Modularity is nice.
Oh, and thumbs up for Two.js. Well done.