Velocity v3 and the future

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.

[Rycochet]

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!

[Rycochet]

@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…