[shtylman]

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]

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

[shtylman]

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.

[usingpond]

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.

[siddboots]

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]

There is, it is called browserify and npm :)

[rwaldron]

So... browserify is like http://static1.wikia.nocookie.net/__cb20131111220942/harrypo...?

[underwater]

Snarkiness and sarcasm aren't the best way to get people to take your arguments seriously.

[Encosia]

> 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]

I don't understand either but it's a habit I've had a hard time breaking out of "full stack" developers.

[jerf]

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.

[Encosia]

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

[matthewmacleod]

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

[donatj]

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

[rwaldron]

MooTools modified built-in objects in future hostile ways. Do you miss that too?

[donatj]

Fuck the future. JavaScript was formed full and feature complete and these newfangled "improvements" are nothing but abominations atop its pure and perfect form.

[nostrademons]

Polymer is also following the same general approach, and has the advantage of most of it being built into the browser and webstandards.

[untog]

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.

[JacksonGariety]

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