Integrate Velocity.js to replace jQuery animate

[timmywil]

This issue is to explore the possibility of integrating velocity.js into jQuery. This is a huge change, so, naturally, we need everybody involved in the discussion.

/cc @SlexAxton @paulirish

[julianshapiro]

Hey, all! Author of Velocity. Even if it doesn't come to fruition, very excited to explore the potential and to improve animation in both jQuery and Velocity.

Thoughts:

Pro's:

• Faster animation within jQuery -- particularly on low-powered mobile devices (for which Velocity is optimized).
• My willingness to gut Velocity and redo the internals to wrap the Web Animation API, which means there will be even further performance benefits. (Particularly in situations of high concurrent main thread load, where CSS currently shines.)
• Considerably expanded workflow features for jQuery users. We're not talking about frivolous niceties here, but rather valuable basics that a lot of people would expect from jQuery in the first place: transform animation, SVG animation, a more robust scrolling syntax, color animation, and better animation chaining and multi-call management.
• Removal of redundant bloat for those who use jQuery w/ Velocity, GSAP, Transit, or an SVG animation library. With Velocity inside jQuery, there's quite a bit space saving. (Although, I will mention that I'm not one of those "remove all the bytes!" nuts.)

Con's:

• There could be breaking changes in certain edge cases, and I may ultimately not be interested in addressing them. If I attempted to address every edge case, then Velocity would wind up too far away from its original intention, which is to make animation better -- not "make jQuery animation better." Velocity uses jQuery's $.animate() syntax because it's awesome, not because I was trying to improve upon jQuery itself. I just wanted the best animation library I could make, and jQuery was the perfect starting point. Getting to my point: Users of Velocity, and people who care about web-based motion design workflows, would expect that same development principle going forward. The principle of don't be completely beholden to what jQuery did in the past. So, yes, there would likely be some minor breaking changes. (Nothing big, though. That's for sure; all the core stuff from jQuery $.animate() is in Velocity.) However, now that jQuery's going SEMVER with release 3.0, this should be par for the course anyway. If people want to stay in their comfort zone, they can stick with 3.0. If they want to catch up with the times, they can upgrade to 4.0 and read a few lines of new documentation. This is where jQuery probably needs to go regardless to remain competitive with other frameworks; big improvements require big changes.
• Politicking. This can't turn into a prolonged back-and-forth. There has to be a sufficient majority opinion within jQuery core to move ahead with this. And it should come within a reasonable timeline. If I have that, I'll put in the necessary work to get Velocity ready for an internal replacement.
• Whatever else you guys and gals bring to my attention :)

[AnthonyPAlicea]

Personally I love this idea. With GSAP and Velocity around, from a performance perspective, there's no reason to use the current jQuery animation engine (aside from the cost of adding another dependency to an app).

[markelog]

I will re-iterate points i made at the meeting:

1. It doesn't have tests, do not lint the code and no CI-integration
2. Uses ua detection instead of feature detection
3. It's not clear by how much there would be a performance gain, if there would be at all, since jquery is now also uses raf.
4. If you test velocity on animate tests as drop in replacement, it would fail most of the tests.

First point is widely considered as a bad way to write your code. Second, was recognized as bad practise long time ago, we (and basically everyone else) have always advocated against such logic.

Third point, is why i believe jquery performed slower, now this is shouldn't be the case. Would like to see performance test on that.

Forth point failures, are API incapability's, some of them are internal, while some of them really aren't. So i have mixed feelings about statement:

Velocity is an animation engine with the same API as jQuery's $.animate().

Although, i wouldn't consider it as replacement, but it would be interesting to see if we could re-use some of the tricks of this library. If, of course, there something interesting, aside from use of requestAnimationFrame.

I see velocity popularity as a result of qualified marketing efforts then anything else. It would be nice to prove me wrong.

[markelog]

/cc @gnarf

[julianshapiro]

1. It doesn't have tests, do not lint the code and no CI-integration

It does. I don't publicize them but I will later this week.

1. Uses ua detection instead of feature detection

This is a micro-concern that can be quickly refactored. Its sparing use of UA detection is only limited to a small subset of behavior. I could probably rip it out entirely. This concern is better suited for a subsequent discussion entailing what Velocity would have to refactor in order to be a replacement.

1. It's not clear by how much there would be a performance gain, if there would be at all, since jquery is now also uses raf.

There are articles that detail the Velocity performance optimizations that go far beyond rAF. I'd refer to the Velocity documentation. Regardless, the primary benefit of Velocity is one of workflow enhancement: reversal, proper scrolling, looping, SVG animation, transform animation, UI mocking, and more. That's why people who switch to it also continue using it. Performance is just the allure for checking it out.

1. If you test velocity on animate tests as drop in replacement, it would fail most of the tests.

Yep. One thing I spoke to David about was my interest in passing all those tests. But, something to consider: A jQuery 4.0 SEMVER release (for example) wouldn't necessarily have to pass every little-used animation edge case. More on this TBD, but I believe some minor breaking changes should occur for the better. Again, TBD.

I see velocity popularity as a result of qualified marketing efforts then anything else. It would be nice to prove me wrong.

Most of the articles and tutorials on Velocity focus on its workflow benefits -- not its performance. The workflow benefits are inarguably a game changer for anyone doing UI motion design. If it were a fad, its popularity wouldn't be enduring. (P.S. Some cool Velocity stuff: http://codepen.io/search?q=velocity&limit=all&depth=everything&show_forks=false.)

[markelog]

I'd refer to the Velocity documentation

I think its better to do the perf test, numbers are best arguments i think

workflow benefits

Not arguing against that, but i wonder if it is in jQuery scope, since one of the jQuery goals is to try to be as small as possible. While if you want something more extensive, then that task might be better suited for the specific animation framework.

I'll be quieter now so i wouldn't clutter/derail the discussion, since it would be really interesting to hear thoughts of the "/cc" people :-).

[gnarf]

jQuery Animate wasn't ever about "performance" imo... It was about dealing with some of the REALLY common animation use cases in the web dev world. Those use cases are changing, and velocity has more of them covered.

I'm more interested in knowing what parts of the jQuery animation unit tests would need "compat" to work with velocity at the core, if any of them "can't work" with velocity at the core, and how much work @julianshapiro thinks it is, or his own personal cost/benefit.

I don't think performance should even be a topic in this thread. It's micro-perf at best. Performance is something we can work on together as well, a lot of us have experience here.

I'm interested in hearing from @arschmitz as well.

[arschmitz]

I have been following Velocity, and the change of jQuery .animate to raf pretty closely since jQuery Mobile is planning on switching to JS based animation and transitions. This decision is partially as part of our move to share code with UI, and partially as we have seen improvements in the speed of JS based animation with things like velocity, and had a lot of headaches surrounding css based solutions.

@gnarf as well as the rest of the UI and Mobile teams have talked about the pro's and cons around this and our current approach was going to be to start with jQuery Core animate and see if performance was an issue or not

Depending on the outcome of that our next step was going to be to either look into using velocity directly, or what it was doing, and try to improve animate directly. I have done some limited prototyping around this a few months ago to see what the performance looked like on older mobiles.

These tests were purely visual ( no frame rates or anything ) and at the time velocity did not give a noticeable benefit though the pages were admittedly simplistic, and more complex pages, is where velocity would make more of a difference, from my understanding.

I don't think performance should even be a topic in this thread. It's micro-perf at best. Performance is something we can work on together as well, a lot of us have experience here.

👍 I think we can work together so that either way perf will not be a concern

I don't really have an opinion on velocity vs animate, or replacing animate with velocity, beyond that i would really like to see us work together, on whatever solution is going to make the most sense as a whole.

[gnarf]

Also @julianshapiro feel free to reach out to me in IRC (@gnarf) or google hangouts gnarf37 at gmail if you want to talk about any of the unit tests / why we do them in jQuery.

[gnarf]

Thanks for the edit of your "reserved" comment @julianshapiro (everyone else should scroll up and re-read comment number 2) --

There could be breaking changes in certain edge cases

Do you have an idea what those edge cases may be?

(Although, I will mention that I'm not one of those "remove all the bytes!" nuts.)

Do you have an idea what the difference in weight between effects.js and velocity.js is currently? We do like small compact things (and we have a few of those nuts that could probably help)

Politicking. This can't turn into a prolonged back-and-forth. There has to be a sufficient majority opinion within jQuery core to move ahead with this.

I'm totally on board with the plan as is, but I'm just a little worried about breaking >too much< backwards compat, or significantly increasing the file size of "basic jquery"

---

Have you given any thoughts to making "velocity-core" which we could include, and then adding the bigger (byte size) features (like color) in plugins? Also, have you looked at the jquery-color api/way it does it's thing? I really like the idea of taking "core" velocity to replace effects (if it can cover most of the units) for the "minimum needed" and then have easy to install plugins for everything else?

[timmywil]

@julianshapiro

Thank you for all your effort! There are obviously still details to work out concerning the implementation, but I think it would be safe to say that we can move forward, with just a couple addenda.

1. As you take the lead on adapting velocity for inclusion, the team is here to help. However, we still have a lot to do for 3.0, so I would just ask for your patience while we first address the remaining 3.0 issues.
2. While we do want to move ahead, I don't think we can say for certain that it's going to be included until the code has been prepared and we reach a point where we can reassess.

Some things that we'll need to take care of before inclusion:

1. While we are following semver, we also try not to make breaking changes unless we have to. Passing our unit tests should be the goal for which we shoot. There is leeway here, but the holy grail would be to pass all of them.
2. After the bulk of the work is completed, it would be great if we could put together some numbers for performance comparisons. It may not be our primary concern here, but it is still a concern and the first step to improving performance is measuring it. Also, having these numbers is great when making release notes.
3. Your ambition to improve jQuery animations is much appreciated. :)

[gnarf]

Your ambition to improve jQuery animations is much appreciated. :)

QFT 😍

[paulirish]

I was excited about this idea, mostly as the anti-rAF situation was getting bad (fixed now, yay!), but I feel a little conflicted now.

First, @markelog's original concerns seem pretty valid. Tests should be published from the get go, and hooked into CI for sure. My heart is broken over the UA sniffing; definitely seems addressable, but just kinda surprised..

the primary benefit of Velocity is one of workflow enhancement

True. Velocity, as a library, targets a sort of authoring & workflow feature set that's beyond what the basic animate() API shoots for. But inside of jQuery, we're really only interested in the animation engine and not the "reversal, proper scrolling, looping, SVG animation, transform animation, UI mocking" sugar that's available. In that respect, this combo is a little funny: velocity's value proposition is around these workflow aspects but jQuery only needs a very basic animation/tweening core. Even snabbt.js which is 1/3 the size of Velocity has more functionality than jQuery needs.

On performance, it'd be easy to show velocity whopping legacy animate() with some test cases. It'd probably be better to show the difference of a few real world sites. Before and after, measuring:

• avg framerate & std dev

• of missed frames

• CPU time per frame.

Tangentially related. I can see why julian questions the necessity of backward compatibility. In particular, the step & progress methods provide the ability to totally tank performance if developers either invalidate styles via mutations or force recalc or layout, which they probably will. Upgrading animate() performance might require addressing these two guys.

[julianshapiro]

@gnarf @paulirish

Do you have an idea what those edge cases may be?

I'll hook Velocity into jQuery's tests and find out shortly :)

Do you have an idea what the difference in weight between effects.js and velocity.js is currently? We do like small compact things (and we have a few of those nuts that could probably help)

If you take into consideration that Velocity's internal CSS getter/setter engine would replace jQuery's in the process (which is what I initially spoke to David about), then it would be a net negative -- we'd be saving bytes. Without taking that into consideration, probably around ~4kb ungzipped extra. Have to check. But if Velocity goes inside jQuery, I'd be removing some features to keep it more "necessity" focused, in which case there would likely not be a size boost even in this hypothetical situation.

Tests should be published from the get go.

I have my reasons (hint: I wanted to discourage PR's at the time -- was happy to code in feature requests myself), but I've always had great tests from day one. Will publish them this weekend as mentioned.

My heart is broken over the UA sniffing; definitely seems addressable, but just kinda surprised..

I feel like I let my dad down.

... but jQuery only needs a very basic animation/tweening core.

That's a core assumption that I haven't heard echoed elsewhere. In fact, as far as I understand the motivation on jQuery's behalf, it's to rethink that statement as a whole. In short, we must be asking, Should jQuery only be very basic in its animation functionality? The answer, from my motivation/perspective, is "no": On a base level, not having SVG, color, and transform animation support in 2015 is arguably unacceptable. If jQuery continues to lack these features going forward, its animation functionality will continue to need wide-spread supplementation.

On an enriched workflow level, I agree: The more advanced workflow features that Velocity offers do not (and probably should not) be part of jQuery. Here's the good news: They're not even part of Velocity to begin with -- they're relegated to Velocity's UI pack (VelocityJS.org/#uiPack) :)

[Rycochet]

Going to put my 2p worth in as a long time jQuery and VelocityJS user (and in the business of web development).

When I discovered Velocity (not long after it came out) I was impressed by it's low overhead and smooth animations compared to jQuery - to the extent that I now add it to any projects that need animations beyond the most basic. I use the best tool for the job, so am quite happy to custom build jQuery without animation support, or use css animations, depending on what I'm trying to achieve - but am still coming back to Velocity (something that is repeated in the large number of sites now using it). As of yet I've never run Velocity without jQuery, but that's more to do with the scale of the sites I need to develop for.

In other words - while $.animate() is useful, it's a bit like the hammer, and $.velocity() is the screwdriver (and both are bits of the toolbox etc).

Bringing the core of Velocity in (possibly with a couple of small changes to calls to fit in with how jQuery does things) would only be a positive thing. It's already there as an extra library, but that does mean extra bandwidth - part of the entire balancing act job.

I'd almost suggest a jQuery slimline base Velocity (ie, a->b animations and basic control), then add the rest of the things that make Velocity special into jQueryUI (colours, sequences etc, not unlike some things already in there) - both already have the ability to build custom version for what is needed, so while that would make for a major code shuffle, it's already a minor reshuffle to begin with.

As far as breaking things with changing the API goes, to the best of my knowledge any API changes would be additions rather than replacements, with most of the big differences more related to wrappers that can be updated.

The tl;dr version is basically this:

jQuery could write it's own improved animation code, then both projects could continue duplicating efforts to fix issues and improvements in browsers, or both projects could come together for extra initial work, but end up with something better ;-)

[timmywil]

This issue has been sitting for a bit. @julianshapiro Did you happen to hook Velocity up to jQuery tests?

[timmywil]

Thank you to everyone who gave input on this, but it doesn't look like it's realistically going to happen. We're still happy to review code on the matter and the issue can be reopened if necessary.