Does it make sense to split jQuery into smaller modules?

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.

Author: Fantashit

2 thoughts on “Does it make sense to split jQuery into smaller modules?

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

Comments are closed.