tweenjs / discuss Goto Github PK
View Code? Open in Web Editor NEWDiscussions about tween.js in general
Discussions about tween.js in general
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:
We could also provide some canonical interfaces. For example, we could write a jQuery plugin for tweening DOM elements.
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
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.
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...
So far I have been looking at:
Any other ideas?
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.
(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:
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! ๐๐ป
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?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.