tweenjs / discuss Goto Github PK

(or: why sole is afraid of getting too close to the current code)

The first release of this library was sometime around 2010. This is ancient in JS terms! So much has changed, so many people have participated on it. It's used by many but maintained by few. This has to change.

The amount of bugs and issues is way more than I can deal with, and one of the big reasons for that is that I do not understand all the code that I didn't write. There are missing tests, and the interactions between some features are... quite unexpected sometimes.

Also, the way things are done on the web is different now. We have node.js modules and build processses, we have ES6 and better JavaScript, we have getters and setters (which tween does not support for some reason), there are CSS animations, etc etc... People often just want to use the easing equations, but they have to include the whole library. Etc.

There were talks for a "es6" version of the library but it never took off for various reasons (here's a repo for it).

As it stands right now, I don't think an ES6 version is attractive per se - the tooling around ES6 to ES5 is quite volatile, and I can't find immediate useful advantages of rewriting in ES6, but what would be really interesting is to start a V2 that is built out of other modules. Each module should be a different project and github repository, published to npm individually. Then "Tween-v2" should be built by requiring those modules.

An structure could be this:

• Tween-v2
  • Tween Manager (the current TWEEN object)
  • Tween (the current TWEEN.Tween)
  • Easings (the current easings)

I believe this would be a good compromise between trying to adding new stuff into the existing single src/Tween.js file, which is getting really unwieldly, and rewriting everything with a new syntax and having to add lots of slow build steps to eventually end up transpiling into ES5 because no browser implements ES6 modules yet.

Another advantage is that we would enter this mindset of splitting things in modules and get used to building Tween or importing parts of it Tween just as we need them, instead of piling all into The Code Monolith. For example, we could have a project that simplifies animating CSS properties by adding 'px' etc (which the current version doesn't). This would not be used by everyone, hence it would live on a different repository.

It makes it easier for people who want to contribute with new features, as maintainers do not need to be super worried that a new addition is going to break the core functionality.

I am inclined to think that we do not need a new "future" tween.js project repository. We could probably start prototyping this new version in a new branch and publish to npm with a 'next' kind of tag if people want to play with it. The most important stuff would be actually in other modules anyway. When we consider the new version solid enough we can merge it back to master, and if someone needs an old version for compatibility, there will always be an archive.

Thoughts? Enthusiasm? Who wants to jump on board? Everyone welcome! 🙋🏻

There are multiple bugs regarding chain

tweenjs/tween.js#153
tweenjs/tween.js#269
tweenjs/tween.js#176

But many projects use the current syntax.

Making a change here will probably be breaking, but people regularly are confused by chain so we probably need to do something about it.

I feel like we should adopt some standard terminology for method names and objects. The terminology should be intuitive and also help the documentation and code be more consistent.

One issue is what to call the object being tweened. Sometimes I have referred to it as the "target" object, because it is the object targeted by the tween, although that could be confused with the object containing the final values. We can call starting values and ending values the "start value object" and "end value object", or "source object" and "destination object".

It is also important that we use good idioms when designing the es6 API. In the current version I think that users probably find the distinction between "remove()" and "stop()" confusing. It's made worse by the fact that we have no real "pause()" method. Also, if we did have a "pause()" method, then it would need to be clear which kind of pausing it did - there's the kind where it will jump ahead when it resumes, and the kind where it will continue where it stopped when it resumes.

I know this can seem trivial, but many users will not want to spend more than 5 or 10 minutes trying to understand this library, so we want to make things common-sense and easy to comprehend.

In the main repository tweenjs/tween.js should we close issues that are asking for help rather than reporting an issue with the code or documentation? Should we create a forum for help requests, or otherwise try to redirect them?

Oftentimes contributors suggest changes that 'improve performance'. Other times they suggest changes but we are reluctant to merge them just in case they 'worsen performance'.

But right now we have no way of measuring performance other than looking at FPS graphs and trying to make sure "it doesn't look worse", but this isn't very accurate, and it's also a bit time consuming.

We cannot tell for sure whether something is better or worse, but we should!

In the past I ran manual tests for comparing between changes but as anything manual, it puts you off.

The ideal benchmark...

• can be run in an automated way (no user intervention required other than initiating the benchmarks, via tests or just the benchmark itself)
• can run on travis (so it's part of the tests before PRs are accepted, and if things are slower than a certain baseline we should reject a PR?)
• could aggregate historical records so we can see if we're going slower or faster (or compare between platforms and engines - some engines optimise things differently) - this would be a stretch goal

So far I have been looking at:

• https://benchmarkjs.com/ which looked good, but it had some strange incompatibilities with node.js.
• related to it, https://jsperf.com/ could aggregate records but it's sort of on pause at the moment.

Any other ideas?

I think it would be helpful to provide examples and tutorials for how to use tween.js with other libraries. We should also consider compatibility with other libraries and real-world use cases when designing new features. I think this will help increase the popularity of the project.

Some libraries that should work with tween.js, for example:

• Three.js
• React.js
• Bootstrap
• jQuery
• Two.js
• Pixi.js
• Ember.js

We could also provide some canonical interfaces. For example, we could write a jQuery plugin for tweening DOM elements.

I think it may be better to just use a discussion label for topics like these, so it is easier to track in one place.

People want to use 'modern JavaScript' with tween.js but some things just don't quite work as you would expect. Sometimes it is due to the way we iterate before deciding which properties to tween, other times it's a consequence of how classes are not 'exactly' objects so things are not iterable. Other times it might be a consequence of transpilers rewriting code so what you see isn't exactly what tween.js sees.

The end result is that things do not work as you expect them to work, which isn't good.

(some) related issues:
tweenjs/tween.js#287
tweenjs/tween.js#267