[ FEEDBACK WANTED ] Velocity is dropping jQuery

[julianshapiro]

@nmussy developed a shim for the jQuery functions that Velocity depends on. I'm now focusing my attention on releasing this work. (I waited until all core Velocity features landed, which they now have.)

The shim works as follows:

• The shim is loaded as a separate JS file before jquery.velocity.js. Velocity automatically detects the shim then uses it for some of its internal functions -- so long as jQuery isn't also present on the page, in which case Velocity will always default to using jQuery proper.
• If the shim isn't loaded at all, jquery.velocity.js works exactly as it does now. No changes are being made to the core Velocity file. The shim's purpose is to simply act as a polyfill.
• If the shim is loaded, you inherently can no longer chain onto jQuery element objects, e.g. $("div").velocity() won't work since you don't have access to jQuery's selector engine nor its chaining capabilities. Accordingly, all shimmed Velocity animation takes place via Velocity's utility function: http://velocityjs.org/#utilityFunction. Note that, when jQuery is loaded on the page, the utility function is normally an extension of jQuery's $ object. However, when jQuery isn't loaded (meaning, the shim is being used), the utility function is attached directly onto the window object and is therefore accessed simply via Velocity.animate(element, propertiesMap, options); This is the new syntax for animating with the jQuery-free version of Velocity.
• If the shim has been loaded and Zepto (instead of jQuery) is loaded on the page, Velocity will attach itself to Zepto's $ and $.fn and will automatically work exactly like it already does with jQuery, e.g. $zeptoElement.velocity();. Without the shim, jquery.velocity.js currently does not work at all with Zepto.

Questions for you guys:

• Should the shim file be named velocity.jquery-shim.js, velocity.shim.js, or something else?
• Should the shim not be a separate file? Instead, should the shim code be baked into Velocity itself, and then should jquery.velocity.js be renamed to simply velocity.js? Note that the shim has a minified size of 4Kb and that minified Velocity is currently at 30Kb.
• An alternative to the above option is to have two versions of Velocity from here on out: velocity.js and jquery.velocity.js. One of them simply bakes in the shim code at the top. Accordingly, the shim itself would not be released as a separate file. (My concern with this option is that there starts to be a lot of download options for users, and I don't want to make them think twice about what file to use.)

Notes:

• There is no performance benefit to not using jQuery. jQuery was never a bottleneck for Velocity. Don't drop jQuery just because you want "increased speed."
• Dropping jQuery and using the shim will only work for IE9+. IE8, which is normally supported by jquery.velocity.js, will not be supported in the shimmed version.
• Since you'll inherently lose access to jQuery's delay() and queue() functions when not using jQuery, you'll want to replicate their behavior by leveraging Velocity's delay option as well as its begin/complete callbacks.

Any questions, concerns, or comments?

[WesleyAC]

How will this affect the amount of work that goes into Velocity? It seems like it might end up as a sort of split codebase, but I haven't looked at the source at all, so I don't know how much it relies on jQuery right now.

I personally don't think I'll use it, but I'm glad that it's an option if I need it.

[julianshapiro]

Hey @WesleyAC,

Great question. The reason I waited this long to release the shim is to ensure that the shim file will never have to be touched. If Velocity winds up needing more jQuery functions in the future (which is highly unlikely), I will simply bake them into Velocity directly. As for how this affects Velocity itself: It won't. I actually don't have to go out of my way to add compatibility for the shim (as opposed to jQuery proper); the architecture of Velocity is such that Velocity can automatically attach itself to jQuery, Zepto, or the plain window object. It doesn't care which of the three; it works the same in all cases.

In short, this won't affect development load on Velocity at all :)

[ianmaddox]

Dumb question: Why? Which use cases are improved with the shim and how?

[julianshapiro]

@ianmaddox: Not a dumb question at all. Example use cases:

• Some people use Zepto, or no helper library at all, when developing mobile apps.
• For lightweight desktop sites that don't need jQuery but do contain heavy motion design, devs will now be able to include Velocity but forsake loading jQuery (which -- marginally -- weighs down the page in terms of file size).
• There are also some edge cases where badasses like @scalvert and @kpeatt are bundling Velocity into a third-party library and would like to avoid forcing the library's users to install jQuery if they aren't already using it.

Tangent: Some people also steadfastly refuse to use helper libraries like jQuery/Zepto for "performance reasons." These people are idiots. They're forsaking extreme efficiency and cross-browser normalization because they think they're saving on precious Kb and ms. Truth is, you can remove one image from your page to make up for the Kb jQuery takes up, and the performance degradation you experience with jQuery (on the scale of a few milliseconds) is completely negligible in the real world for everything but animation, which Velocity already solves.

[jordaaash]

👍 I think this is great. I'm already using React, superagent, LoDash, bluebird, and other specific-purpose libraries, so I find myself not needing the DOM, Ajax, or general utility functions built into jQuery. The performance has never been an issue, but the API for Ajax, the broken promises/deferreds, and the overall large surface of jQuery is a drag, especially if you don't have to target less modern browsers.

I think the loss of delay and queue is a good thing. Things that are queued for the animation's completion like that can be flexibly handled by Promises, so it's always seemed duplicative to me.

I definitely like the plain velocity.js and window-global Velocity.animate and the 4K if the shim were baked in isn't an issue for me, though since the project's heritage comes from jQuery, if it makes sense to others to separate it, that's cool too. However, I think velocity.jquery-shim.js could be a bit confusing because it only contains some of jQuery's functionality, and thus might lead some to believe they can use it like jQuery.

Is there a WIP of the shim or anything like that? I'm not very familiar with the internals of Velocity, so it would be cool to read through the source to see what's being shimmed specifically.

Edit: I did some digging. Is this about the whole of it here?

[julianshapiro]

I think this is great. I'm already using React, superagent, LoDash, bluebird, and other specific-purpose libraries, so I find myself not needing the DOM, Ajax, or general utility functions built into jQuery.

Thanks for contributing this. Another great example of when people don't need jQuery.

I think the loss of delay and queue is a good thing. Things that are queued for the animation's completion like that can be flexibly handled by Promises, so it's always seemed duplicative to me.

Couldn't agree more.

I think velocity.jquery-shim.js could be a bit confusing because it only contains some of jQuery's functionality, and thus might lead some to believe they can use it like jQuery.

True. Definitely a point against going with that option. As it is, I'm already leaning toward having the two versions. If people wouldn't complain about the 4Kb file size boost, my genuine preference would be to just have a singular velocity.js though.

Is there a WIP of the shim or anything like that? I'm not very familiar with the internals of Velocity, so it would be cool to read through the source to see what's being shimmed specifically.

Yeah, but I need to clean it up. I can post a link on here in a couple days :)

[kpeatt]

my genuine preference would be to just have a singular velocity.js though.

This system works for me because we have no short term plans to move off of Zepto. Having the shim included as part of the main file makes my life a little easier.

That said, I think if I were using jQuery I'd prefer that 4kb be left out of what I'm loading. Right now, we use require to concatenate scripts together so it doesn't really cost us anything to have the shim as separate file. Whatever works best for you here and is easiest to maintain is the right answer. I wouldn't stop using Velocity because it was 34kb minified vs 30kb minified so that shouldn't be your decision maker.

Another potential reason to have two versions or just have the shim is that 90% of your use case is probably going to be jQuery users. Those who aren't using jQuery should be able to read enough to find the shim or alternate file. Those who are can just use the file as is.

badasses like @scalvert and @kpeatt

😎

[Rycochet]

Personally I like your third choice with 4 files in total (doubled due to minified versions) -

• nojquery.shim.js - just the shim
• jquery.velocity.js - normal version
• velocity.js - automatically built from shim + jquery
• velocity.ui.js - the ui pack we all know and love ;-)

The loss of jQuery functions isn't really an issue - if someone doesn't want to use jQuery then they've not got access to them to start with, and the more people using velocity the more feedback and ideas come in and the better it gets :-)

Most people who don't bother reading things are likely to just use the main named file without the "jquery" part in it - which would be the "works everywhere" one - though the temptation there is to rename the whole project to something to discourage inane and already-answered questions (iq-test.js maybe? :-P)

You could potentially have lazy-loading of the shim if jQuery isn't loaded - but I'm not a fan of scripts adding extra scripts, not least because of the whole issue about where to load it from etc.

[thiphariel]

For now on, I always try to avoid jQuery. In some cases, it's usefull, for others, it's not. But I'm not here to talk of it.

IMO, maybe you should provide your script twice, (velocity.js + jquery.velocity.js) because some devs will ever use jQuery, or sometimes, they have to.
"Layout trashing" method used in velocity makes it really blazing fast, and should be use in every project that contains animations, that's why you should open it for both kind of projects.

For the shim, if it's really light, why not including it in velocity core's ? 4kb minified is not a shame, and I think it could be easier to use for newbies. You could then share only 2 core files, velocity.js & jquery.velocity.js.
I know some of us are using Grunt / Gulp solution to build their apps, but if the shim is really designed for velocity, it should be included to it.

Thanks :-)

[lmartins]

Regarding your questions:

1. velocity.shim.js
2. Although I would a single file, baked into velocity itself (4kb is insignificant, not to mention the extra request if you're no concatenating files)
3. This is probably the option with less friction but I see your point.

Dropping the jQuery dependency is a really good move, thanks for taking the extra effort to make it happen.

[Oliboy50]

As a massive jQuery user, I won't mind if Velocity have a single file velocity.js containing both jquery.velocity.js & velocity.shim.js, actually I'll even be happy to type src="velocity.js" instead of src="jquery.velocity.js".

I think that someone who uses jQuery shouldn't care about add 4kb to its page (if he does, he should just stop to use jQuery which weight 94kb already).

Thanks for developing and maintaining Velocity.

[kevin-smets]

I'm all for it, velocity.js and jquery.velocity.js are imho the most clear way of doing it. Isn't it almost the de facto standard?

There is no benefit to splitting out the code? I'd imagine the ability to drop support for IE8 would benefit in some way no? I'm all for dropping IE8 by the way, all major frameworks are starting to do so and I'd say it's about damn time.

http://theie8countdown.com/

I'd have thought it would be lower than 10% by now but some people / companies just can't seem to let go... Even so, for IE8 I will not shed a tear, and I try to educate our bussinesses to do the same.

[julianshapiro]

Most people who don't bother reading things are likely to just use the main named file without the "jquery" part in it - which would be the "works everywhere" one

Good point, @Rycochet.

Thanks for the feedback, @thiphariel!

2. Although I would a single file, baked into velocity itself (4kb is insignificant, not to mention the extra request if you're no concatenating files)

think that someone who uses jQuery shouldn't care about add 4kb to its page (if he does, he should just stop to use jQuery which weight 94kb already).

@lmartins & @Oliboy50: This is what I'm hoping most people will say as well. Would love to get a poll going..

@kevin-smets There is no perf benefit to dropping IE8, and there would only be maybe 25 lines dropped in terms of file size. So, no real impact. But, darn, am I happy to see IE8 dying....

Thanks, guys! Keep 'er comin'!

[bendiksolheim]

My initial reaction to this was somewhere along the lines of "please make at least one release completely without the shim so I won't have to load unnecessary bytes", but the more I think about it the less it matters really. I think having just one release with velocity and the shim combined would be totally fine.

If you're afraid people will not be using Velocity it because of the "unnecessary" 4 kB, you can simply market it like this: "Velocity works without jQuery, but attaches itself to it if it is available". You don't really need to mention that it includes a jQuery shim. This way it is more a bonus, really. Also keep in mind that most people gzip their content as well (at least I hope so), which makes the 4 kB even less significant.

Might I add that dropping the jQuery dependency is a really awesome move. I wish more libraries would go in this direction.

[julianshapiro]

Thanks so much for that, @bendiksolheim. That's what I secretly wanted someone to say :) Definitely reassuring. I would LOVE, LOVE, LOVE to just have a singular velocity.js version.

[scalvert]

Going to weigh in on this and throw my weight (all 165lbs of it!) behind the one codebase option. It's infinitely easier to have a one file to rule them all solution. We all know what a pain it is to maintain appendages of code. Having a jQuery shim makes definite sense, as lots of people use jQuery, and are very familiar with a specific convention of API.

So to summarize, removing the direct dependency to jQuery is definitely the preferred option, with the added shim to adapt it to work with a familiar API.

[kevin-smets]

If possible, one codebase. There's no way you can be against that :).

[jordaaash]

I like how the "Velocity works without jQuery, but attaches itself to it if it is available" statement from @bendiksolheim sums up this approach. It could also transition to highlight some of the benefits of using Velocity directly for certain things, like returning promises, and especially the internal-but-exposed Velocity.CSS implementation, which is fantastic if you're not doing imperative DOM structure manipulation (i.e., doing it declaratively with React or Angular).

Also, I just wanted to say your desire for and response to feedback evidenced here is awesome, and I think it reflects in the tone of the discourse. It's really exemplary of how welcoming and productive open source development can be when done right.

[julianshapiro]

@jordansexton Thank you so much for the kind words.

In a minor twist / change of heart, I'm now leaning toward just going with jquery.velocity.js and velocity.shim.js since it's really only 1% of people who need the jQuery shim, and I don't feel like bloating Velocity with 425 lines of messy jQuery code that I'm not really allowed to modify/clean since I should be mostly adhering to their spec'd behavior for the sake of compatibility and maintainability.

[lmartins]

You mean you're going to two files after all?

[julianshapiro]

At least to start. This way, at minimum, we can iron out if there are any bugs and I can reconsider a merger (thanks to the comments in this thread) down the line.

[scalvert]

Any chance of wrapping it in a UMD?

[jordaaash]

I'm now leaning toward just going with jquery.velocity.js and velocity.shim.js

Haha now I'm confused.

1. Does this mean jquery.velocity.js is what Velocity is right now (Velocity assuming jQuery/Zepto on the page)?
2. Is velocity.shim.js just the shim itself, or is it Velocity + shim? If it's the former, does that mean you must load jquery.velocity.js as well (confusing if not using jQuery)? If it's the latter, I think jquery.velocity.js and just velocity.js makes a lot of sense, suggesting one is the plugin and one is the standalone.

[julianshapiro]

1. Correct.

2. Correct, it's just the shim. Yes, you still load jquery.velocity.js.

[Rycochet]

I think the UMD thing should be a totally separate issue - for when you reach v1 or later - split velocity up into separate parts that can then be put together by a build script or similar to let people build their own custom versions skipping things they don't want/need so they can strip every possible byte from things ;-)

Until then I want to say "stay on target, stay on target", but don't like the obligatory red-shirt moment that comes afterwards :-P

[Stolzenhain]

+1 for Zepto support; in my opinion that's more important than the no-dependency route.

You could handle this as a separate issue to allow for more focused discussions as this conversation revolves around the shim thing (which I find a good idea of handling this approach in beta state).

[soldsoul]

Is there a way to test this out now?

I am using velocity with npm / browserify and can't figure out how to keep from getting the global $ error thrown, other than including jquery in a script tag ( eww ).

Ideally I would be able to:

var velocity = require('velocity-animate'),
  el = document.querySelector('.foo');
velocity.animate(el, { width: 100 }, [50,7]);

[julianshapiro]

Google for how to require a jquery plugin. There's a shimming process. (No relation to my shim.)

Sent from my phone

On Jul 28, 2014, at 11:50 AM, soldsoul [email protected] wrote:

Is there a way to test this out now?

I am using velocity with npm / browserify and can't figure out how to keep from getting the global $ error thrown, other than including jquery in a script tag ( eww ).

Ideally I would be able to:

var velocity = require('velocity-animate'),
el = document.querySelector('.foo');
velocity.animate(el, { width: 100 }, [50,7]);
—
Reply to this email directly or view it on GitHub.

[scalvert]

What he said ^

We've defined our shim like so:

shim: {
    'velocity': {
        deps: ['jQuery'],
        exports: '$'
    }
}

This works for us.

[lmartins]

Is the non-jquery already available for testing?

[soldsoul]

Thanks, found this helpful stackoverflow for those interested:
http://stackoverflow.com/questions/21265814/shim-a-jquery-plugin-with-browserify

@scalvert The shim you supplied here is from a grunt task?

@julianshapiro Should this be added to the docs?

Will this remove the hard dependency on the global $ variable?

Would be awesome to not have to shim anything and just pass an element to Velocity.animate as I think you mentioned before.

[julianshapiro]

Hey Luis. No, there appears to be a bug on iOS6. Looking into it this week.

Sent from my phone

On Jul 28, 2014, at 2:49 PM, Luis Martins [email protected] wrote:

Is the non-jquery already available for testing?

—
Reply to this email directly or view it on GitHub.

[julianshapiro]

Fixing an obscure iOS6 bug in the next ~14 days then this will finally be released. Will open a new thread then.

Thanks, everyone.

[julianshapiro]

If anyone's curious what's taking so long, read this: #208

I could use your help!

[julianshapiro]

Big news. Spread the word. Velocity has DROPPED JQUERY! See http://VelocityJS.org/#dependencies .

[fattenap]

This is great news!!