Velocity v3 and the future
Rycochet opened this issue · 7 comments
So this has been paused for quite a while, the reason basically came down to not having the time / spoons for writing Unit Tests to be able to do a proper release for v2...
Now almost two years later I've been actively coding Velocity again for a couple of weeks, and all I can say is... I've started a lot again!
Things have changed a lot in the past two years - there were things I wanted to do with the code before that were so bad for performance they couldn't be justified, but that's all changed, and now a lot of these things that could improve the interface for Velocity are now first-class citizens in the JS world of browsers - so I'm in the process of splitting Velocity up even more than before and making it significantly more powerful!
In a rough end-user explanation, the API for animations will remain the same as V2, which itself was very similar to V1 in most ways (only properties such as scrolling were complete changes).
Things that are changing are pretty much all behind the hood:
- Far more abstracted design, which means we can do more Unit Tests to make sure things are safe and working correctly
- Splitting almost everything apart - there's going to be more packages published (with the old
velocity-animate
being retired) - We've got a new namespaced project@velocityjs
- so it's easier to use what you want - there will be a@velocityjs/animate
which will effectively be the same as the old one for direct script use in browsers though (and will include everything from all other core parts of Velocity - though likely not specific modules such as React / Ember / Angular etc) - All modules for Velocity will be using the same public API that anyone can use, so there's (almost) nothing they can do that someone else can't hook into to extend!
- The core part of Velocity no longer knows or cares what it is animating... All the browser support is being put into
@velocityjs/dom
, which might not seem like much - but it means that adding support for animating anything else becomes a lot simpler. What else might you animate? How about an Object that's being used to generate some WebGL display - and you can write your own custom functions for getting / setting any properties!
A lot of these things are still being designed in terms of the best ways to do them, and I encourage anyone who wants to see what's happening have a look at the V3 branch - though be aware that a lot more is likely to break before it works again (the changes are too extensive to keep things working in the interim, but hopefully it won't take long to get back there again).
I also want to write a performance / stress testing module that can compare all current animation libraries with each other - and give a good idea on what needs to be improved - so any ideas and support would be awesome!
Internally we're now using Lerna for monorepo support, TSDX for package building, and will be using Jest for unit testing, and Storybook for showing off individual components that can be (as that also lets us include example code that can be played with). As with V2 this is 100% in Typescript, but the "everything" package of @velocityjs/animate
will be compiled with Webpack and Babel for older browser compatibility.
NOTE: The current V2 state is now being saved under the V2 branch - it never quite reached release due to the lack of testing, but still works very well for a lot of people.
Thanks for your report of the current state of velocity :) I have some questions:
- At this point, would you recommend to update an existing project (heavily based on velocity) from
1.5.2
to2.x beta
? Or should I wait for3.x beta
? - Do have any idea, of a raw timeframe, when to expect the first 3.x beta?
As a User v2 and v3 will remain almost identical - only if creating sequences, easings, or similar extensions to Velocity would there need to be any code changes - and they should be more around the wrappers of creating, rather than the content itself. The breaking changes were all in v1-v2 where inconsistent APIs were cleaned up and new features added :-)
For timeframe I really can't say - a lot depends on my work and energy at the end of the day, I'm also running 3x D&D games a week, so there's only really weekends - I'm hoping to have it in public beta and with tests being filled out (will be alpha before the tests are in, and will come out of beta once tests are all done and there's some form of performance metrics) before the new year!
Any news here available in the meanwhile?
With best regards
Any news here available in the meanwhile?
With best regards
Sadly not - with no time / energy for any more, I have local changes that are part-way done (and pretty extensive in how things are being done) I need either more holidays, or people helping me :-/
What form might that help take? I'm about to create a Drupal module to make this library more easily available to Drupal developers and would like to put a call-to-action on the module page.
Belay that, without slideUp and slideDown there's no point, sorry for the noise.
@Rycochet I'm a bit confused about current state of this project. You've stated there is v2, I can see tags, but there is nothing on npmjs. Is there something what prevents v2 to be released on npm as well?
Also, you've stated to work on v3, but there is no activity since 2020 in this repo. Do you plan to work on it further? Or is there some successor you can recommend? Thank you very much.
@dakur v2 was a huge improvement, but hadn't quite hit the stability I wanted, I then started on improving the things that weren't as good as they should have been on a (local) v3 branch, which I probably haven't touched in close to two years. The biggest things in the way are wanting to move the project into its own organisation (so it'd not be attached to a single person's account - agreed even before this, but not done), and getting no help for a long time.
TL/DR It's not dead, just not got enough enthusiasm to work on it given my other responsibilities in life...