Does it make sense to split jQuery into smaller modules?

[stevemao]

Since npm is doing a great job, and browserify and webpack are becoming popular, commonjs style is highly recognised by a lot of front-end developers. jQuery also embraces npm, which makes npm the future package manager for JavaScript of both front-end and backend.

However, jQuery is quite heavy, bloated with methods that would probably never used by a website, and this is not quite the npm way. Say if I want to iterate over objects, why would I use jQuery.each but not lodash.each? I can even load different versions of lodash methods in one app without requireing the whole lodash src files.

Therefore, I'm asking: Does it make sense to split this module into smaller ones so that developers can cherry pick the methods they are going to use? In fact, jQuery src is already modulised so it wouldn't be hard to publish each small piece to npm (just need a build tool to convert them). Packages like cheerio is doing some similar things and jQuery could potentially share some small modules with it in some way. Angular.js could just use the ones they need instead of building jqlite themselves.

Just like lodash, jQuery can also develop some build tool to build different versions for different purposes.

[dmethvin]

First, to answer the question: Yes, some of the modules can be made smaller. There's already #1864 but I'm sure others can find similar opportunities. Go for it!

But I have to dispute most of the assertions above...

However, jQuery is quite heavy, bloated with methods that would probably never used by a website, and this is not quite the npm way.

Front-end web development is nowhere near as bloated as npm. For proof, look no further than the node_modules directory. Node development is like layers of an onion. The reason it doesn't look bloated from the top level is that you're only seeing the outer layer of a very pungent onion. But every module you include in npm can (and usually does) include many other modules.

What worse, projects can (and usually do) include different versions of the same modules. So when you at the top-onion-skin project layer dutifully npm update your own dependencies, the dependencies in these lower layers are not in your control. Your code may still be saddled with whatever bugs you thought you were escaping.

Say if I want to iterate over objects, why would I use jQuery.each but not lodash.each?

Since jQuery itself depends on jQuery.each it is there and usable "for free". You can, of course, include other utilities that have the same functionality if you prefer, but this will lead to further bloat.

I can even load different versions of lodash methods in one app without requireing the whole lodash src files.

Yes you can, and obviously this is a behavior upon which many node programs depend as mentioned above. But again it adds to bloat. To reduce bloat (and allow for sane debugging) the developer should choose a single version and use that.

jQuery src is already modulised so it wouldn't be hard to publish each small piece to npm (just need a build tool to convert them).

I don't see producing or publishing the modules as the problem. There is the challenge of them sharing a single object to support Continuation Passing Style ("chaining") but that can be overcome.

To me the bigger issue is the consumption of these modules. First, most front-end code doesn't have a package.json file. Think about the thousands of jQuery plugins out there, we don't know what their dependencies are. Second, we can't do what node does and just include multiple versions of everything at every layer of the onion, because all of our code is moving over the Internet and not just resting in node_modules. Instead, these tools need some way to flatten the duplicate dependencies and only include one version. Yet that can't happen automatically in all cases, the developer will need to resolve conflicts.

These are not jQuery-specific issues. No matter what node developers preach, npm is not an ideal tool at all for client-side web developers right now. We're working with npm and a lot of others to improve that, but at the moment you could summarize it as "Mo modules, mo problems."

As a JavaScript development community, we're a very long way from solving this issue. The solution so far has been to invent multiple incompatible workflows with different package managers, module loaders, etc. So now we have to defrag the mess and agree on a smaller and simpler set of processes. Otherwise most web developers will rightly stay with a workflow that's simple and comprehensible like including files manually via <script> tags.

[mgol]

Note that we'd like to eventually switch from AMD to ES6 modules & compile to AMD (and potentially CommonJS) so doing this whole modularization now would require changes really soon.

Also, publishing lots of tiny modules would complicate our release process significantly. I'd much rather just work on switching to ES6 modules once they're implemented, implementing the transpiling and then if someone needs only some modules they can just do require('jquery/commonjs/ajax') etc.

[timmywil]

If bloat is the primary concern, modules are not the way to go. Using our custom build process has a smaller footprint than using the modules directly.

Also, jQuery is not a utility library. It has utility methods like each and map because they are used internally and it's convenient to our users to expose them, but in the grand scheme, there aren't actually that many methods that make sense as standalone methods. For instance, it seems intuitive to publish $.ajax separately, but ajax has so many dependencies (Deferred, Callbacks, Core), it quickly becomes simpler to just include the whole of jQuery. Would you publish $.post separately? Perhaps all of the ajax methods together in one module? Then you're getting into grouping again and ending up with a compiled file about the size of jQuery anyway (given that you'd be leaving all of the module wrappers).

I love using modules in my JS, but publishing jQuery methods or modules individually would be a lot of effort with surprisingly little reward.

Sounds interesting. So jQuery willl be converted to ECMA-6 and more modular in the future? I saw a repo yesterday: https://github.com/Kflash/ES6-workflow

Is this how you guys think about the future for jQuery?

[dmethvin]

If we used ES6 syntax in jQuery and transpiled, I suspect it would add unneeded bulk to the resulting source. Also, we probably wouldn't get a lot of benefit from ES6 features like arg destructuring and default arguments, given the parameter-hockey-happy way the API was defined a decade ago.

Might be fun to see what it looks like though. Maybe we could find a subset of ES6 that was more pleasant to write but wouldn't add bulk. It's pretty easy to play with the Babel REPL and see what comes out.

You're always free to use ES6 in your own code when you call jQuery no matter how we build it, and most likely you'll transpile your own source down to ES5 for the next few years anyway. If you actually want to use most of the ES6 syntax and not just the modules, you should look at something like https://github.com/thoughtram/es6-babel-browserify-boilerplate instead of ES6-workflow.

[timmywil]

Thank you for this issue, but this will not be in the roadmap for the foreseeable future. We will probably take a look at es6 modules after 3.0, but it may be a while.

[stevemao]

Thank you guys, this is in the back of my mind for a while.

I love using modules in my JS, but publishing jQuery methods or modules individually would be a lot of effort with surprisingly little reward.

Very surprised about this but I don't know..

[stevemao]

Looking at this issue again after more than a year, many projects actually start using monorepo approach and with tree-shaking, devs don't need to worry about the size.

Note that we'd like to eventually switch from AMD to ES6 modules

Definitely the way to go 😄

[CelticParser]

I think everyone on the development team has forgotten what the term 'bloat' means. Bloat is were ( in this case of jQuery ) is when code is not utilized by the end user. There are several university studies based on Akanomi Data and other nonprofit organizational data shows less than 15% of jQuery is utilized by the end-user bin 99% of all sites that require the library. Also, search engines and other notable organizations are more and more recommending to steer away from third-party libraries designed for "lazy developers" ( jQuery is at the top of these lists) and to get back to Bonilla JS.

I am not a fan of NPM because the majority of those developers leave development dependencies and assets in their releases which IS a huge security issues. However, NPM is on the right track helping both development flow and reducing bloat. @dmethvin is way off by saying that:

Node development is like layers of an onion. The reason it doesn't look bloated from the top level is that you're only seeing the outer layer of a very pungent onion. But every module you include in npm can (and usually does) include many other modules.

This is is not true; modules only include dependencies. If a module is included deep in those 'onion layers', it's because it's a 'dependency'. Despite the security issues NPM developers impose in their releases, those development tools left in can easily be removed.

The problem with jQuery is its an "all or nothing" library and because it's development is stuck on this mentality, I honestly don't see it surviving another five years ( conservativly speaking ).

Another issue with "one big module" it's much more complicated to maintain and release - esp for security patches.

It's about UX more than cattering to developers these days; making web apps faster, more secure and cost effective for all as in maintainability, end development, and most importantly for the end-user by keeping bandwidth to a minimum.

[mgol]

@CelticParser The fact that we only publish one package doesn't mean you have to compile the whole jQuery. We have source broken into separate small AMD components, you can load only the ones you need. In the future we'll most likely switch to ES6 modules so it'll be even easier to integrate with various tree shaking tools.

[shrpne]

@mgol in 2015 you were talking about switching to ES6 modules in the future.
Isn't future already came? 😄

[dmethvin]

@shrpne As always, pull requests welcome.

[timmywil]

@shrpne Sort of. The primary place jQuery is used is in the browser, and while transpilers have seen widespread usage, es modules (defined in the es2015 spec) are still not supported natively in any stable browser (except Safari 10.1, surprisingly). That said, they are getting there. So, I understand there is an argument to be made that jQuery can get ahead of browsers here. But still, I wonder how much we actually gain. Most jQuery users use the compiled version of jQuery. It seems like it wasn't until we made the slim build available that we saw a notable amount of jQuery users including a custom build in their code. Rewriting our modules and build system to use es modules will require a lot of effort, and I predict very few users will actually take advantage of it.

The final issue is time. Again, this will require a lot of effort and we are all volunteers. If anyone wants to take the time to do this, we would welcome a PR.

[shrpne]

@timmywil what about open this issue?
Or better sum up everything about es6 modules in new issue?
Because for now all issues about es6 modules are closed and looks like it is unwanted feature.

I will be glad to see it with some milestone badge, at least "Future".
So it always be before the eyes and may be somebody would like to carry on it.