Velocity v3 and the future

[Rycochet]

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.

[exodus4d]

Thanks for your report of the current state of velocity :) I have some questions:

1. At this point, would you recommend to update an existing project (heavily based on velocity) from 1.5.2 to 2.x beta? Or should I wait for 3.x beta?
2. Do have any idea, of a raw timeframe, when to expect the first 3.x beta?

[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!

[Michas0206]

Any news here available in the meanwhile?
With best regards

[Rycochet]

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 :-/

[darvanen]

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.

[dakur]

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

[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...

[jarlah]

Hi @Rycochet 👋

I came across this repo through a GitHub search and wanted to reach out. You mentioned that moving this project to an organization and getting more contributors would be beneficial. I'm part of an open-source, voluntary organization called js-commons, which aims to revitalize popular JavaScript repositories by continuing development, improving features, adding tests, and updating dependencies. Our goal is to keep these projects running and safe to use.

I understand this project is owned by @julianshapiro and you're a contributor/admin/co-owner. Moving to js-commons would require either:

• Agreement from both of you
• No response or activity for a few months

After which we could fork and move the project.

What are your thoughts on this? Does joining such an organization appeal to you? Or were you considering creating a separate public organization for Velocity? Either way, I'm excited about the possibility of rekindling interest in this project and helping to keep it active.

Looking forward to hearing your perspective! Comments from others are also welcome.

[Rycochet]

@jarlah It's been sitting in limbo for literally years as I'm the only one that seemed to have any interest - and I couldn't take it further without the permissions needed (which moving to an org would make more apparent) - given that I've got a partially done update sitting on my computer (with some major for-the-time improvements) I'm not really in a position to mind one way or another - forking it won't get the published artefacts on npmjs to change though, which is sort of where it was hitting that road-block 😞

[jarlah]

I see :) Well, personally I think its best to "move on" and make a js-commons/velocity package. If you have write permissions to this repo, an update to the README with deprecation warning about the move to js-commons would be a possible solution. in npmjs we can make an opensource organization for js-commons that are not owned by a single developer. The license of this project is very permissive of such fork/move at least.

But about this "given that I've got a partially done update sitting on my computer". What do you mean with that? You have local changes to velocity not pushed to git?

Anyway, old artifacts in npmjs that point to deprecated or moved repos, are not a new thing. Its common i would say. Just tell me if want to move it. If its only been you the last years, you got the power :)