Repository navigation
Document which jQuery modules are relied upon #3791
Description
This would allow people to do a custom build of jQuery if they would like: https://github.com/jquery/jquery#modules
This would allow people to do a custom build of jQuery if they would like: https://github.com/jquery/jquery#modules
Activity
wagenet commentedon Nov 26, 2013
@lukemelia Are you volunteering? It should be a matter of running the tests with a custom build and seeing what fails.
lukemelia commentedon Nov 26, 2013
Yes, you can assign me. On a ongoing basis, do you think we would want tests to run with the necessary custom build, with all of jQuery, or both?
wagenet commentedon Nov 26, 2013
Good question. I think we might want to consider just changing the official dependency to be a subset of jQuery and just run tests against that. If we can run against a subset we should be able to run against the full thing in theory. We could also make the tests do both if we thought that was helpful.
wagenet commentedon Nov 26, 2013
/cc @rjackson
lukemelia commentedon Dec 21, 2013
Update: I spent about 30 minutes looking into this and found that jQuery's custom build system made it easy to create builds that don't work. It will be more complex than I expected to figure out which modules are necessary.
rwjblue commentedon Dec 22, 2013
How about this: run through the main modules, build jQuery without them (one at a time), run our test suite, and document the failures/errors by module. Then start picking off the lowest hanging items one at a time.
@lukemelia - Does that sound like a decent plan? If yes, I can devote some time to the first pass this week...
lukemelia commentedon Dec 23, 2013
Seems reasonable, Robert!—
Sent from Mailbox for iPhone
On Sun, Dec 22, 2013 at 6:55 PM, Robert Jackson notifications@github.com
wrote:
ebryn commentedon Dec 29, 2013
I've had luck on modern browsers using a custom jQuery 2 build with these flags:
grunt custom:-ajax,-ajax/script,-ajax/jsonp,-deprecated,-dimensions,-effects,-event-alias,-offset,-sizzleHTMLBars will require even less :D
wagenet commentedon Apr 15, 2014
@rjackson ping.
locks commentedon May 19, 2014
I just finished the first pass at this and I managed to remove more dependencies than I was expecting to. Results are up at https://gist.github.com/locks/cdbd04e6a2f9cefe8304.
@ebryn I tried removing sizzle but it broke quite bad, did you supply an alternative?
For the next pass I'm going to look into the failing tests and see if I can replace jQuery with native code.
tomdale commentedon May 21, 2014
@locks: Be careful with that one.
jQuery.remove, for example, does a lot of things that we implicitly rely on to keep our memory consumption down. Off the top of my head, jQuery unbinds events and clear any data that may have been added byjQuery.data, which will otherwise leak. Changing to using native DOM manipulation will introduce a memory leak into any Ember apps that use, for example, jQuery UI or jQuery Mobile.locks commentedon May 21, 2014
@tomdale how do you suggest I make sure I don't introduce regressions?
My general plan was to err on the side of aggressiveness, and then re-introduce the modules when problems were detected.
trek commentedon Jul 15, 2014
We're pretty close to removing jQuery as a dependency. There were several stabs at integrating jQuery's custom build system to work with rake-p and Broccoli, but it seems silly at this point.
locks commentedon Aug 6, 2014
@trek curious about updates on this front
tomdale commentedon Aug 8, 2014
@locks We discussed this at the core team meeting but still feel uncomfortable dropping the dependency, especially due to extremely common confusion around props vs. attrs (which jQuery fixes up). We're going to try to extract the functionality that we need into separate libs, but I don't think it's top priority at the moment.
locks commentedon Aug 14, 2014
@tomdale thanks for the feedback. it's understandable, I was even under the impression that when htmlbars was fully merged that my efforts could be for naught.
I feel like the gist is still useful for when extracting the separate libs.
runspired commentedon Aug 22, 2015
This RFC would nearly remove the reliance on jQuery for eventing: emberjs/rfcs#86
In my current implementation,
jQuery.event.fix(e)is used to normalize the event. This is something that could be pulled out as a micro-lib exposing the needed jquery AMD module.https://github.com/runspired/ember-capture-eventing/blob/master/addon/event_dispatcher.js#L379