5 ms·

> _I was there_ ... In 2007, at the beginning of my journey > I started this blog. I remember my first JavaScript > tutorial which gained a lot of readers,

> _I was there_ ... In 2007, at the beginning of my journey > I started this blog. I remember my first JavaScript > tutorial which gained a lot of readers, even though I > wasn’t the expert in the field ... So when I recommended > jQuery, some people followed me in this opinion and tried > it. This post was a fun read simply because my own career path is not unlike the author's. I spent this time in comp.lang.javascript (;^)) and ##javscript, where I learned pretty quickly that I was decidedly not hot shit and that even frontend JavaScript development already had a significant history. Today I wouldn't entertain the idea that I was present at the start of some turning point, it was just the start of another career. Being a neophyte coming from the land of HTML, CSS, and A List Apart, I took to jQuery like a fish to water, but more experienced folks correctly slapped my hand when I championed it (like David Mark, the Voldemort of c.l.j.). I wasn't quite sure why it was so reviled in these circles, but given that I had arrived at these communities to learn and not teach, I went with it and just listened (and didn't write blog posts). Over time I saw jQuery for the abomination it is. A very usable, imprecise API that has "fluent interface" and a selector engine as its chief selling points, where a single prototype is the God object to end all God objects. Given that all of the other libraries implemented a comparable selector engine, I never felt deprived when working with Prototype, or MooTools, or Ext.js, or ultimately Google Closure. I could see that designs written with these other libraries were far more comprehensible and cohesive than what was coming out of the jQuery world, but to oppose the jQuery tidal wave was a fool's errand, so I just kept writing lots of software for my employers, and didn't write blog posts. Maybe some day the history of how jQuery "made it" will be written. It seems like a shining example of "Worse is Better." Recommendations like the one from the author were just the blind leading the blind. Now we're stuck with it. Maybe more of us who felt this way should have written blog posts, but as the author hints, that's the paradox! You can spend so much time writing software, or spreading ideas, but seldom is there time to do both prolifically. I still don't feel qualified to write blog posts like this one...

qznc 12y ago
Impostor syndrome?
pcthrowaway 12y ago
jQuery is beautiful and meticulously engineered (and also modularized) to a level far beyond other DOM manipulation/cross-browser compatibility/animation/promise/wart abstraction/whatever else libraries. It may not be the best at everything, and it's certainly not minimalist (though its components are now designed to be independent and customizable) but it is the meeting of many good practices and informed design across its many capabilities. It's the everything-and-the-kitchen-sink philosophy (with a focus on performance). > Given that all of the other libraries implemented a comparable selector engine This is not true; other libraries implement their own selector engines which, while (sometimes) smaller in size, are also less feature-rich. Sizzle (jQuery's independently developed selector engine) provides many additional selectors not currently available in the browser (such as nested pseudo-selectors: `:not(:has(div:first-child))`). If none of this appeals to you, you are welcome to use a different library. There are lots of other strong options. But just because jQuery doesn't fit your needs doesn't make it 'an abomination'
- oinksoft 12y ago
  You're right that Sizzle was the class of selector engines, and if the story ended there (with jQuery as a DOM library) then jQuery wouldn't be listed on many resumes. By publishing `jQuery.prototype' to `$.fn', pushing the idea of "plugins", and by encouraging DOM operations as the main extension point in application design, jQuery made itself into something more. The brittleness of this approach is proven by how calling jQuery UI component methods requires an additional level of dispatch. This way of doing things has no legacy. It's considered an antipattern now, and a "mess of jQuery" is a known form of code debt. I don't think it's a matter of whether this style "fits your needs" anymore.
  - pcthrowaway 12y ago
    A "mess of" anything is a known form of code debt. Just because jQuery doesn't force you to use it properly doesn't make it unusable. jQuery, or parts of it, are still used by default in almost every SPA application framework, and some of the resulting applications are even well structured.
- 12y ago
jnbiche 12y ago
You're forgetting one of the driving forces behind jQuery: browser incompatibilities. Now, with IE on board with HTML5 (whatever the hell that is) and most browsers at least trying to be standards-compliant, it's easy to forget that without a compatibility layer, building a cross-browser Javascript application was literally impossible. Furthermore, jQuery offered a pretty nicely-engineered codebase and a very friendly and predictable API at a time when client-side JS was very unpredictable. I don't use jQuery much anymore, since it's often just as easy to use plain JS. Plus, I'm often compiling so I can use a ES6 compiler to make it even nicer. But I definitely leaned heavily on jQuery in the days prior to IE8-IE9 and client-side builds. And even disregarding all my arguments above, I don't think it's fair to call such a carefully-designed and maintained project an "abomination", even if you do disagree with some of its technical decisions.
- oinksoft 12y ago
  jQuery was far from the only popular cross-browser DOM library. We had a choice of jQuery, MooTools, YUI, Prototype, Dojo, Mochikit, and quite a few others, along with good presentation of standalone cross-browser techniques from sources like QuirksMode. jQuery mostly succeeded through its marketing to web designers which formed a critical mass of well-written extensions and hireable know-how, and a zeitgeist of jQuery as a baseline.

qznc 12y ago

Impostor syndrome?

pcthrowaway 12y ago

jQuery is beautiful and meticulously engineered (and also modularized) to a level far beyond other DOM manipulation/cross-browser compatibility/animation/promise/wart abstraction/whatever else libraries. It may not be the best at everything, and it's certainly not minimalist (though its components are now designed to be independent and customizable) but it is the meeting of many good practices and informed design across its many capabilities. It's the everything-and-the-kitchen-sink philosophy (with a focus on performance). > Given that all of the other libraries implemented a comparable selector engine This is not true; other libraries implement their own selector engines which, while (sometimes) smaller in size, are also less feature-rich. Sizzle (jQuery's independently developed selector engine) provides many additional selectors not currently available in the browser (such as nested pseudo-selectors: `:not(:has(div:first-child))`). If none of this appeals to you, you are welcome to use a different library. There are lots of other strong options. But just because jQuery doesn't fit your needs doesn't make it 'an abomination'

oinksoft 12y ago
You're right that Sizzle was the class of selector engines, and if the story ended there (with jQuery as a DOM library) then jQuery wouldn't be listed on many resumes. By publishing `jQuery.prototype' to `$.fn', pushing the idea of "plugins", and by encouraging DOM operations as the main extension point in application design, jQuery made itself into something more. The brittleness of this approach is proven by how calling jQuery UI component methods requires an additional level of dispatch. This way of doing things has no legacy. It's considered an antipattern now, and a "mess of jQuery" is a known form of code debt. I don't think it's a matter of whether this style "fits your needs" anymore.
- pcthrowaway 12y ago
  A "mess of" anything is a known form of code debt. Just because jQuery doesn't force you to use it properly doesn't make it unusable. jQuery, or parts of it, are still used by default in almost every SPA application framework, and some of the resulting applications are even well structured.
12y ago

jnbiche 12y ago

You're forgetting one of the driving forces behind jQuery: browser incompatibilities. Now, with IE on board with HTML5 (whatever the hell that is) and most browsers at least trying to be standards-compliant, it's easy to forget that without a compatibility layer, building a cross-browser Javascript application was literally impossible. Furthermore, jQuery offered a pretty nicely-engineered codebase and a very friendly and predictable API at a time when client-side JS was very unpredictable. I don't use jQuery much anymore, since it's often just as easy to use plain JS. Plus, I'm often compiling so I can use a ES6 compiler to make it even nicer. But I definitely leaned heavily on jQuery in the days prior to IE8-IE9 and client-side builds. And even disregarding all my arguments above, I don't think it's fair to call such a carefully-designed and maintained project an "abomination", even if you do disagree with some of its technical decisions.

oinksoft 12y ago
jQuery was far from the only popular cross-browser DOM library. We had a choice of jQuery, MooTools, YUI, Prototype, Dojo, Mochikit, and quite a few others, along with good presentation of standalone cross-browser techniques from sources like QuirksMode. jQuery mostly succeeded through its marketing to web designers which formed a critical mass of well-written extensions and hireable know-how, and a zeitgeist of jQuery as a baseline.