3 ms·

Using the collective knowledge and testing that has been used to derive the methods in jQuery is hugely attractive, grappling with cross browser issues every ti

Using the collective knowledge and testing that has been used to derive the methods in jQuery is hugely attractive, grappling with cross browser issues every time you want to achieve something would be utterly pointless. Despite this, every time I start a new project that requires some DOM manipulation etc I lament at having to include the entire library just to harness a tiny aspect of it's power. A delightful solution to this would be a similar degree of modularity as there is in, for example, jQueyr UI. I know there is a degree of modularity (https://github.com/jquery/jquery#modules-new-in-18 https://github.com/jquery/jquery#modules-new-in-18) but this is reasonably high level and at this level the argument of using google's CDN and so encouraging a cache hit is still very strong. If you could strip both jQuery core and shizzle (I rarely/never use attribute selectors for example) right down to a hundred lines of so of what you really needed, this would be very very compelling. I had a relatively brief investigation into the codebase a while ago with a view to how hard this would be to implement but didn't really have the time to follow it through. My conclusion was that it wouldn't be easy, anyone have any ideas/thoughts on this?

lbotos 14y ago
There was once someone trying to make a Modular jQuery. I'm not sure how far that got. Have you tried stuff from the jeesh? http://ender.jit.su/#jeesh http://ender.jit.su/#jeesh Super lightweight and a comparable syntax style.
untog 14y ago
Before jQuery took over everything, I was very happy using Mootools, which cones with a modular builder: http://mootools.net/core/ http://mootools.net/core/ It was, and remains, great. But jQuery seems like an unstoppable force at this point.
johnbender 14y ago
You can do custom builds if you fork the repo: https://github.com/jquery/jquery#modules-new-in-18 https://github.com/jquery/jquery#modules-new-in-18 As far as I know the core team is planning to continue the trend along with a builder at some point. For my part I've proposed a separation of the dom manipulation from the collection and argument handling: https://github.com/johnbender/wield https://github.com/johnbender/wield
ricardobeat 14y ago
Zepto is a nice alternative, with a jQuery-compatible API and a way smaller source. It would be the perfect replacement for jQuery if it wasn't for it's lack of IE support. For that reason I and a friend started a project called Rye[1] that is a light wrapper around the DOM and other browser APIs; it's made of small modules that you can pick as needed. Despite being < 6kb, it also favours readability over code size, so it's easy to spy under the hood. Ender[2], a hybrid library/package manager, has a similar philosophy. [1] http://ryejs.com http://ryejs.com [2] http://ender.no.de/ http://ender.no.de/
- thomseddon 14y ago
  Rye looks cool, but the main pull of using jQuery (or a jQuery "module" as I would like) is the sheer amount of battle every single line of the library has seen, as the OP said.
  - ricardobeat 14y ago
    Of course, yet more lines of code = more bugs. The browser landscape these days is much more stable if you ignore legacy IE.
dmethvin 14y ago
> A delightful solution to this would be a similar degree of modularity as there is in, for example, jQuery UI Except that jQuery Core is a completely different thing. You know if you're using jQuery UI Menu but not jQuery UI Dialog so you can decide to include them or not with a custom web-based builder just by clicking boxes. The jQuery Core features used by all the plugins you collected to build your site are not immediately obvious. Did they use .replaceWith() for example, is it safe to leave that out? What about .load(), did they use that API? Oh, wait, there are two different things that .load() does, one is AJAX-y and one is event-y, if they did use it which one did they mean? By having the full library there you don't need to spend lots of time tracing down these dependencies. And in JavaScript these are all dynamic, you can never really be sure you got the dependencies right until you find out you didn't. That's why I strongly advocate that the average programmer should just use the whole standard jQuery core library unless you are in some spot where saving 10-20KB gzipped is so important that you're willing to chase down those dependencies yourself.
- thomseddon 14y ago
  If your point is "if you aren't able resolve the dependencies in the code you include, then don't try" then I suppose I agree. Frankly with the amount of plugins I usually use (0-2) this isn't really problem... The point is, there are some great features and fixes tucked away in there and sometimes I only want say <5-10% of the library, I could write it myself but then I loose all the collective knowledge embroiled throughout.

lbotos 14y ago

There was once someone trying to make a Modular jQuery. I'm not sure how far that got. Have you tried stuff from the jeesh? http://ender.jit.su/#jeesh http://ender.jit.su/#jeesh Super lightweight and a comparable syntax style.

untog 14y ago

Before jQuery took over everything, I was very happy using Mootools, which cones with a modular builder: http://mootools.net/core/ http://mootools.net/core/ It was, and remains, great. But jQuery seems like an unstoppable force at this point.

johnbender 14y ago

You can do custom builds if you fork the repo: https://github.com/jquery/jquery#modules-new-in-18 https://github.com/jquery/jquery#modules-new-in-18 As far as I know the core team is planning to continue the trend along with a builder at some point. For my part I've proposed a separation of the dom manipulation from the collection and argument handling: https://github.com/johnbender/wield https://github.com/johnbender/wield

ricardobeat 14y ago

Zepto is a nice alternative, with a jQuery-compatible API and a way smaller source. It would be the perfect replacement for jQuery if it wasn't for it's lack of IE support. For that reason I and a friend started a project called Rye[1] that is a light wrapper around the DOM and other browser APIs; it's made of small modules that you can pick as needed. Despite being < 6kb, it also favours readability over code size, so it's easy to spy under the hood. Ender[2], a hybrid library/package manager, has a similar philosophy. [1] http://ryejs.com http://ryejs.com [2] http://ender.no.de/ http://ender.no.de/

thomseddon 14y ago
Rye looks cool, but the main pull of using jQuery (or a jQuery "module" as I would like) is the sheer amount of battle every single line of the library has seen, as the OP said.
- ricardobeat 14y ago
  Of course, yet more lines of code = more bugs. The browser landscape these days is much more stable if you ignore legacy IE.

dmethvin 14y ago

> A delightful solution to this would be a similar degree of modularity as there is in, for example, jQuery UI Except that jQuery Core is a completely different thing. You know if you're using jQuery UI Menu but not jQuery UI Dialog so you can decide to include them or not with a custom web-based builder just by clicking boxes. The jQuery Core features used by all the plugins you collected to build your site are not immediately obvious. Did they use .replaceWith() for example, is it safe to leave that out? What about .load(), did they use that API? Oh, wait, there are two different things that .load() does, one is AJAX-y and one is event-y, if they did use it which one did they mean? By having the full library there you don't need to spend lots of time tracing down these dependencies. And in JavaScript these are all dynamic, you can never really be sure you got the dependencies right until you find out you didn't. That's why I strongly advocate that the average programmer should just use the whole standard jQuery core library unless you are in some spot where saving 10-20KB gzipped is so important that you're willing to chase down those dependencies yourself.

thomseddon 14y ago
If your point is "if you aren't able resolve the dependencies in the code you include, then don't try" then I suppose I agree. Frankly with the amount of plugins I usually use (0-2) this isn't really problem... The point is, there are some great features and fixes tucked away in there and sometimes I only want say <5-10% of the library, I could write it myself but then I loose all the collective knowledge embroiled throughout.