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