Why don’t You work on a JavaScript/JScript/webKit-Tween-Library ?

JQuery is just so ugly with all these nested anonymous functions !

Bon courage avec “Eaze” !

Honestly after many years of Flash animation and dev I have yet to find a project that I couldn’t have done comfortably with even the most basic tween engine.

Also the fact that you will usually not manipulate tween object yourself (even if it’s possible with Eaze) is imho a better security against memory leaks because the engine was designed and tested to be careful about that. I’d be more anxious to have beginner devs with an object-base tween engine (like Adobe’s) where you must keep tween references to be able to override or stop them.

Unfortunately all of these libraries seem to save state information, and sometimes even complex data structures containing references to all existing tween-related objects, in static variables that are hidden from the user. This can make it very difficult to avoid subtle bugs and memory leaks, especially in larger or modular applications.

I would take a clean, simple design, modularity and extensibility over performance any day as long as performance is “good enough”. It continues to escape me why all anyone cares about is raw benchmark performance.

The test from BetweenAS3 that I am using is fair with all the engines and using only the generic tweening features. Maybe I should have mentioned that the results of other libs like Tweener, Adobe Tween or gTween are ridiculous compared to the 3 libs we are discussing.

That said, I insist that my conclusion is that coders should give little importance to speed and memory aspects and use what they are more comfortable with.

The flaw mentioned in #1 didn’t have so much to do with using an outdated version of TweenMax – it was that the BetweenAS3 test itself tweens Sprites in the TweenMax flavor of its test which use 12.6 times more memory and require a lot more processing to update whereas it tweens Point objects in the BetweenAS3 flavor of its test – not at all fair. I’m sure it was probably an honest mistake on their part and I was just hoping you spotted it and corrected it before running your tests. The big difference in memory use you reported made me suspect that the flaw may still be present (it’s easy to miss).

I’m confused as to why you called the “FAST*” stuff in my test a flaw and a “trick”. I include the standard versions in my test as well and clearly explain the difference in the text below. People can try both and see the difference for themselves. The point was to demonstrate what is easily possible with plugins. Were you aware that BetweenAS3 uses the exact same technique (strong data typing for DisplayObject properties) to improve its speed?

I haven’t provided FLAs in the TweenLite/Max zip downloads for quite a while. Did you mean that you’d prefer that I not provide the swfs like Plugin Explorer and the basics demo? A lot of people have specifically asked for those to be included, but I can see why they might be annoying for knowledgeable developers like yourself who just want the code and no extras.

Anyway, please don’t take my points of clarification as insults or discouragement at all – you’re obviously a very talented developer and have invested a lot of thought and time in Eaze. I don’t want it to be a “my engine is better than yours” thing at all – the community really benefits from generous guys like you who share ideas and code. I just thought you might want to know about the Sprite/Point discrepancy in the BetweenAS3 test you’re using (again, it’s very easy to miss).

1) I’m doing all my tests after updating the libraries to the latest available – I respectfully did it when doing my speed comparisons. I’ll still check that I had the latest release of your lib and update the numbers accordingly.

I’d like to mention that your own speed test (which I tried too) is flawed by your “FAST” trick which use specialized strongly typed objects to appear faster than other engines in your demonstration.

2) I never said that more classes is a sign of poor quality: when TweenLite was one class the code was arguably poor (v11 code looks good to me) but at this time you provided a nice little syntax improvement over Tweener. On the opposite, BetweenAS3 has definitely a great design and code quality, but a hell of a lot of classes.

Now I don’t expect a lot of popularity for Eaze – as for FlashDevelop I like developing my own tools and I enjoy sharing them.

Finally, I’d have a suggestion for TweenLite: provide small, focused, source archives without FLAs and all. Like only TweenLiteNano AS2 that I’d happily give to my animators to drop in their banners work.

1) Were you aware that there’s a huge flaw in the BetweenAS3 speed test? It has TweenMax tweening Sprite objects which use 12.6 times more memory and require 2.2 times more processing power to update x and y properties compared to the Point objects that they tween with BetweenAS3! It’s no surprise that the test makes it look as though TweenMax is a memory hog and slower. Did you correct the flaw when you ran your tests? If not, it’d be cool if you’d do so and edit the results.

2) I always find it curious when people seem to think there’s an inverse relationship between the quality of a platform and the number of classes it employs. Originally, TweenLite was a single class and the simplicity was great. But I think you’ll find that as the platform matures, it makes a lot of sense to break things out into classes in order to benefit from inheritance and minimize file size when not all of the classes are needed (true in most scenarios). You complained that TweenLite/Max now have almost 70 classes but in reality, TweenLite is only 4, TweenMax is one more, and the rest are optional plugins. I think the days of “cram everything into one big class file” are largely [pardon the pun] over.

Anyway, best of luck with Eaze. It certainly does sound fast and I’ve got a lot of respect for anyone who throws their hat into the tweening engine ring because I know how much effort goes into creating one that works reliably and fast and at the same time tries to balance feature richness with minimum file size while putting together good documentation and supporting end users. Prepare for lots of questions And if you’ve got any suggestions for the GreenSock stuff, I’m all ears.

Cheers!