5 ms·

Lots of those are for Sizzle. jQuery would be great if it broke up all those tiny little and completely orthogonal things it does into modules so that people c

Lots of those are for Sizzle. jQuery would be great if it broke up all those tiny little and completely orthogonal things it does into modules so that people could use them as needed. No one library is going to provide everything for every project but making everyone require your ajax code when all they wanted was an `offset()` function is equally backwards thinking. We have much better tooling now to work with modules and to reuse code. Arguments about CDN caching are some sort of premature optimization (or I don't know what really). Most early projects don't need it and other projects can trivially use many of the free (or super low cost) CDN providers if they care that much. My issues with jQuery are not at how awesome it has worked in the past or how well it has hidden/handled lots of browser quirks; it is that thinking in terms of "everything is dom manipulation" is the wrong abstraction for doing organized and maintainable front-end code. The things jQuery does well would be useful within smaller components or libaries but now we are back to the original issue of jQuery is one giant blob.

rwaldron 13y ago
OMG, you should file a ticket for jQuery core to implement some kind of system for breaking up the source into modules!! Here's a link: https://github.com/jquery/jquery#modules https://github.com/jquery/jquery#modules
- shtylman 13y ago
  As long as every jquery plugin and other code that depends on jquery continues to require all of jquery, all this module stuff is useless. I am sure it helps you organize jquery Dev but it still doesn't help actually define real dependencies on a per component basis.
  - siddboots 13y ago
    So just ship your code along with the specific jQuery modules that you want to use. The fact that there isn't a better way to do this is a fault of javascript, not a fault of jQuery.
    - crugej 13y ago
      There is, it is called browserify and npm :)
      - rwaldron 13y ago
        So... browserify is like http://static1.wikia.nocookie.net/__cb20131111220942/harrypotter/images/5/53/Harry_potter.jpg http://static1.wikia.nocookie.net/__cb20131111220942/harrypo...?
        underwater 13y ago
        Snarkiness and sarcasm aren't the best way to get people to take your arguments seriously.
        rwaldron 13y ago
        I wasn't being snarky, I was making playful jokes :P
  - usingpond 13y ago
    Personally, I don't think you can simultaneously use tons of plugins and also complain about being forced to include jQuery. If you don't have the time to roll your own, then you probably don't have the time to prototype Array ten times again for missing features in various clients.
Encosia 13y ago
> it is that thinking in terms of "everything is dom manipulation" is the wrong abstraction for doing organized and maintainable front-end code. I don't understand how the presence of jQuery on a page forces you to think that way (or any specific way).
- jaredmcateer 13y ago
  I don't understand either but it's a habit I've had a hard time breaking out of "full stack" developers.
  - jerf 13y ago
    The natural way to code is that you sit down to do a task, and you set out to do that thing in the most direct way possible, then you are done. The insight that more advanced coding techniques can metaphorically collapse space entirely and make the sum journey shorter tends to be something only picked up after years of experience... if that. Bashing DOM nodes together to do a task is merely one manifestation of this. Multi-thousand line functions, code that makes thousands of queries to a DB and manually performs some enormous task that could have been more easily done in three slightly more complicated ones, code that just flings open a socket every time it needs to do something on the network and just starts stuffing bytes at a remote service... it's all manifestations of this. I don't have a good word for this. I wish I did. Probably something buried on C2 somewhere if I poke around hard enough.
    - matthewmacleod 13y ago
      "Bad management" These are the things that get cleared up by code reviews, break sprints, bug hunts, periodic refactoring… in many cases, YANGTNI applies. That's not an excuse for long-term sloppy code, but it's an excuse for developing good practice when making changes to an existing codebase.
    - Encosia 13y ago
      > Bashing DOM nodes together to do a task is merely one manifestation of this. I suppose that's what I was getting at originally. There's absolutely nothing that removing or adding jQuery will do to impact the larger problem of treating client-side development as software engineering instead of incoherent scripting. None of the advice on the originally posted site would change those organizational/logical problems.
donatj 13y ago
Mootools, rest in peace, was completely modular and you'd check the features you wanted see: http://mootools.net/core/ http://mootools.net/core/
- nostrademons 13y ago
  Polymer is also following the same general approach, and has the advantage of most of it being built into the browser and webstandards.
- untog 13y ago
  Yep, I was a huge fan of Mootools back in the day. Took me a long time to switch over to jQuery, and even then it was because I had no other choice.
- rwaldron 13y ago
  MooTools modified built-in objects in future hostile ways. Do you miss that too?
  - donatj 13y ago
    Fuck the future. JavaScript was formed full and feature complete and these newfangled "improvements" are nothing but abominations atop its pure and perfect form.
JacksonGariety 13y ago
What you're asking for does exist: http://ender.jit.su http://ender.jit.su

rwaldron 13y ago

OMG, you should file a ticket for jQuery core to implement some kind of system for breaking up the source into modules!! Here's a link: https://github.com/jquery/jquery#modules https://github.com/jquery/jquery#modules

shtylman 13y ago
As long as every jquery plugin and other code that depends on jquery continues to require all of jquery, all this module stuff is useless. I am sure it helps you organize jquery Dev but it still doesn't help actually define real dependencies on a per component basis.
- siddboots 13y ago
  So just ship your code along with the specific jQuery modules that you want to use. The fact that there isn't a better way to do this is a fault of javascript, not a fault of jQuery.
  - crugej 13y ago
    There is, it is called browserify and npm :)
    - rwaldron 13y ago
      So... browserify is like http://static1.wikia.nocookie.net/__cb20131111220942/harrypotter/images/5/53/Harry_potter.jpg http://static1.wikia.nocookie.net/__cb20131111220942/harrypo...?
      - underwater 13y ago
        Snarkiness and sarcasm aren't the best way to get people to take your arguments seriously.
        rwaldron 13y ago
        I wasn't being snarky, I was making playful jokes :P
- usingpond 13y ago
  Personally, I don't think you can simultaneously use tons of plugins and also complain about being forced to include jQuery. If you don't have the time to roll your own, then you probably don't have the time to prototype Array ten times again for missing features in various clients.

Encosia 13y ago

> it is that thinking in terms of "everything is dom manipulation" is the wrong abstraction for doing organized and maintainable front-end code. I don't understand how the presence of jQuery on a page forces you to think that way (or any specific way).

jaredmcateer 13y ago
I don't understand either but it's a habit I've had a hard time breaking out of "full stack" developers.
- jerf 13y ago
  The natural way to code is that you sit down to do a task, and you set out to do that thing in the most direct way possible, then you are done. The insight that more advanced coding techniques can metaphorically collapse space entirely and make the sum journey shorter tends to be something only picked up after years of experience... if that. Bashing DOM nodes together to do a task is merely one manifestation of this. Multi-thousand line functions, code that makes thousands of queries to a DB and manually performs some enormous task that could have been more easily done in three slightly more complicated ones, code that just flings open a socket every time it needs to do something on the network and just starts stuffing bytes at a remote service... it's all manifestations of this. I don't have a good word for this. I wish I did. Probably something buried on C2 somewhere if I poke around hard enough.
  - matthewmacleod 13y ago
    "Bad management" These are the things that get cleared up by code reviews, break sprints, bug hunts, periodic refactoring… in many cases, YANGTNI applies. That's not an excuse for long-term sloppy code, but it's an excuse for developing good practice when making changes to an existing codebase.
  - Encosia 13y ago
    > Bashing DOM nodes together to do a task is merely one manifestation of this. I suppose that's what I was getting at originally. There's absolutely nothing that removing or adding jQuery will do to impact the larger problem of treating client-side development as software engineering instead of incoherent scripting. None of the advice on the originally posted site would change those organizational/logical problems.

donatj 13y ago

Mootools, rest in peace, was completely modular and you'd check the features you wanted see: http://mootools.net/core/ http://mootools.net/core/

nostrademons 13y ago
Polymer is also following the same general approach, and has the advantage of most of it being built into the browser and webstandards.
untog 13y ago
Yep, I was a huge fan of Mootools back in the day. Took me a long time to switch over to jQuery, and even then it was because I had no other choice.
rwaldron 13y ago
MooTools modified built-in objects in future hostile ways. Do you miss that too?
- donatj 13y ago
  Fuck the future. JavaScript was formed full and feature complete and these newfangled "improvements" are nothing but abominations atop its pure and perfect form.

JacksonGariety 13y ago

What you're asking for does exist: http://ender.jit.su http://ender.jit.su