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.
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
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.
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.
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.
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.
> 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.
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.
Fuck the future. JavaScript was formed full and feature complete and these newfangled "improvements" are nothing but abominations atop its pure and perfect form.
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.