I was hoping for an article on the deeper semiotic meaning of why programmers and which ones with what experiences were drawn to the ideas of jQuery when they were. That's an interesting topic for any programming language that achieves success and the micro intellectual developments that they represent, SQL v NoSQL for instance, and other pendulum swings.
Problem is those always erupt into flame wars, people don't like being deconstructed, I wish it wasn't so hard, self awareness is a good thing, even if the deconstruction is a leaky abstraction as generalizations are.
Yes, I too was deeply disappointed. I believe you could do an entire PhD dissertation of deconstruction of the semitoic meaning of why j is lower case in jQuery. Is it symbolic of humankind's struggle against our basic instinct to organically generate hierarchical structures to subvert understanding of true meaning?
jQuery popularized use of CSS selectors in clients, and probably had a role in browser vendors adding querySelectorAll.
implicit iteration (obviating for-loops) across a node-set, type-agnostic starting points (constructor accepts a snippet of HTML, a selector, a node or another jQuery object), and simple chaining (functions return 'this') enable concise code
on top of this it smooths out DOM API inconsistencies and quirks between browsers
A deconstruction would look more at things like subconscious signaling, cultural values and biological influences. For a funny play on the less interesting distractions that a lot of deconstructionists of the last century embarrassed themselves with see dugmartin's comment above, I was trying to lean away from that school by using the word semiotic, but dugmartin expertly nailed that too :)
There's another way to deconstruct jQuery, which is often overlooked by people.
jQuery's design, in large parts mirrors the needs http://en.wikipedia.org/wiki/Progressive_enhancement. Once you reached enlightenment / chose progressive enhancement as your client development methodology, all javascript code boils down to two phases:
- find the points in the document to enhance
- transform those DOM elements into javascript enabled awesomeness
I still long for the old http://docs.jquery.com from the 1.3.x days. The new site that actually serves all the material, api.jquery.com, feels like exactly that--an API reference--while the old format was much more browsable. Instead of just alphabetical lists of methods you got a fuller explanation of what each function did, and the methods in each section were organized by purpose with surrounding explanations, not as a sterile alphabetical list. A world of difference to the newcomer. Had the docs been the way they are now, I'm not sure I would have been so happy to read them and get started.
I've read your comment a couple times now but I'm struggling to think of an example that hasn't improved with the new layout. Not only does the new layout include a much more in-depth listing of properties and methods but it also has a much more dynamic categorization system. Perhaps you missed all the categories available on the sidebar of the site?
We studied how users were interacting with the jQuery documentation and overwhelmingly they were ignoring (and out-and-out confused by) the categorization and going straight to Google - because they wanted to find methods by name or functionality. For this reason we improved our search functionality and made the URLs super-intuitive (.html() is now just http://api.jquery.com/html, for example).
Note that the rest of the "old" documentation is still in place - this includes all the tutorials and other getting started guides - the only thing that was "moved" was the API documentation. Undeniably the browsability of the API docs has improved with this revision.
You're right in that the old docs had really bad searching. That's much improved in the new docs.
I might be different. I came to learn jQuery through the raw docs, not through tutorials, and found that the old docs' organization was more friendly for casual browsing & exploration, and the new is more amenable to API lookup ("I already know the name of the method").
(The CSS is very broken on the archive--) but you can see that you used to have it organized functionally, not alphabetically, which was great for me as a learner to see at a glance the different axes of capability for jQuery's selector engine, instead of a alphabetical mash of selector operators, some titled by the operator, others by a description. If I didn't already know CSS thoroughly, reading your selector operator list now would be very disorienting.
I have to say jQuery and its community is amazing, without it QuickFuse (http://quickfuseapps.com) would not have been possible. But one of its strengths was being able to be grokked so quickly by newcomers, and I was a bit disheartened to see the docs stray away from a introductory format more in favor of a reference format. It's a bit more intimidating to the newcomer to have to wade through categorical tagged lists of methods with brief descriptions, instead of a human-organized page on each aspect of the jQuery object that presents the methods in a sensible order.
Observation: there's alot of dead space in the middle and right of all the blocks. If there's nothing useful to put there, it might be worth considering a different, more compact graphic layout.
The InfoVis and ProtoVis libraries, among others, may have better layouts for this data:
Agreed about the amount of space used up when the blocks are closed, but once you've clicked a few to view the internal code, it's not such a big deal.
Perhaps someone else would like to take up the challenge of make the jQuery code navigable by treemap!?
Problem is those always erupt into flame wars, people don't like being deconstructed, I wish it wasn't so hard, self awareness is a good thing, even if the deconstruction is a leaky abstraction as generalizations are.
Then again, we do have Yegge ;-)