great timing. I'm in the process of creating an application displaying complex timelines with hundreds of elements, and EaselJS (or any canvas lib I suppose) is quite a handful.
it's not like canvas is slow (EaselJS' cache is a savior in this case). it's more like it hurts for me to even think of all the complex operations a canvas lib has to do to cope with various mouse interactions (calculating the objects under the mouse pointer), animation redrawing etc.
Out of interest, I'm considering porting an open source diagramming package that I wrote a while back (before canvas was widely supported) that although it was written mostly in JavaScript use a Flex component to actually render stuff and handle user input - given that EaselJS is pretty much a port of the Flex display object model to JS and canvas I thought it would be a good choice.
porting that would not be a problem, I'm quite sure.
but problems? yes. for example, the default EaselJS build strips out such DisplayObject methods that are not documented but are present in the unbuilt source code, e.g. getBounds(). I do understand there are reasons for it being undocumented, sure -- calculating bounds for a raster object may be very expensive on canvas, but since I'm working with strict square shapes, it works for me very well, hence I've got a custom EaselJS build to maintain.
I also had some problems with TweenJS (a tween co-lib for EaselJS) -- this was also solved by a custom build, as the downloaded minified version they're currently hosting was not up-to-date with EaselJS' newest changes (at least it wasn't couple of days ago).
that said, even though my code is not quite render-agnostic, I'll definitely try out Svgjs, as it's methods are almost one-on-one match to EaselJS'.
one problem with canvas is there are use cases where you are going to want to export as a vector graphics file. This is doable (but somewhat non-trivial) in an SVG element, but basically impossible for a canvas element.
actually, for example, EaselJS is written up very neatly and IS easy to work with, so I see absolutely no problem writing a custom adapter which would recursively reiterate the EaselJS Stage object (toString() method) and parse out all the shapes and what-not to whatever format you could possibly want.
sure, but with svg you already have that, written by the good folks at mozilla/google/apple.
I don't know how easelJS works, but the other really nice thing about svg is that modification of some attributes (color, stroke-width, etc.) is done using CSS, so if you, say, wanted to have the user be able to customize the interface in general cases (I was using this to annotate DNA which usually are done with arrows - one user might want genes in yellow and promoters in green, another vice versa, etc) that's a trivial implementation; no need to write a custom lookup table.
it's not like canvas is slow (EaselJS' cache is a savior in this case). it's more like it hurts for me to even think of all the complex operations a canvas lib has to do to cope with various mouse interactions (calculating the objects under the mouse pointer), animation redrawing etc.
we'll see how svgjs copes with that.