Re:We Removed jQuery
by DonHopkins on Saturday October 20, 2018 @07:36PM
(#18266036)
Have you ever single stepped through the jQuery code and looked at the return stack? shudder
There's a whole lot of complexity due to cross platform browser compatibility, working around various quirks, especially in the event handling plumbing, etc. It provides some nice conveniences, but if you're not using them, you're still paying for that big fancy layer.
Also, jQuery's APIs tend to be very polymorphic and fuzzy and interpretive, taking different numbers and types of parameters, supporting multiple overloaded interfaces, wrapping and unwrapping proxies, sniffing parameter types and shuffling them around, applying various defaults and shortcuts, bending over backwards to be "fluid", etc.
That kind of dynamic code has a cost and doesn't optimize so well, compared to the simple crisp unambiguous calls with with regularly typed parameters directly into native code that the newer standard DOM APIs tend to provide.
But the worst thing about jQuery isn't its own fault, it's the way people use it. I've seen so much jQuery code that repeats selectors and other slow searching method calls again and again because the programmer apparently thought calling into jQuery was faster than using a local or instance variable, doing the expensive computation once, then re-using the result.
Or maybe it's because using local variables doesn't match with jQuery's "fluid" style of chaining method calls. As if it was bad luck to break the chain of method calls by using a local variable and giving something a name.
And many people tend to use jQuery as a crutch to avoid learning and using JavaScript itself. (This explains all the excitement about that jQuery plugin that adds and subtracts numbers.)
There's a whole lot of complexity due to cross platform browser compatibility, working around various quirks, especially in the event handling plumbing, etc. It provides some nice conveniences, but if you're not using them, you're still paying for that big fancy layer.
Also, jQuery's APIs tend to be very polymorphic and fuzzy and interpretive, taking different numbers and types of parameters, supporting multiple overloaded interfaces, wrapping and unwrapping proxies, sniffing parameter types and shuffling them around, applying various defaults and shortcuts, bending over backwards to be "fluid", etc.
That kind of dynamic code has a cost and doesn't optimize so well, compared to the simple crisp unambiguous calls with with regularly typed parameters directly into native code that the newer standard DOM APIs tend to provide.
But the worst thing about jQuery isn't its own fault, it's the way people use it. I've seen so much jQuery code that repeats selectors and other slow searching method calls again and again because the programmer apparently thought calling into jQuery was faster than using a local or instance variable, doing the expensive computation once, then re-using the result.
Or maybe it's because using local variables doesn't match with jQuery's "fluid" style of chaining method calls. As if it was bad luck to break the chain of method calls by using a local variable and giving something a name.
And many people tend to use jQuery as a crutch to avoid learning and using JavaScript itself. (This explains all the excitement about that jQuery plugin that adds and subtracts numbers.)
https://github.com/cbrandolino/jQuery-basic-arithmetic-plugi...