and _$ and _jQuery :)
As for the Q, at it's core it's basically a very large collection of design patterns for eliminating tedious methods of working with the DOM and IE's lack of support for the W3C standard for said DOM through a highly compact and readable API based on CSS selector syntax. And the chaining. That's nice too if you don't overdo it. Not to mention some stupid-smooth animation that I really need to get around to reverse-engineering as I suspect there's some good stuff to learn there. Principles * It stays out of everybody's way if you want it to. It's easy to redefine a query match into something that can be easily worked with using standard JS-native methods and you can even ask it to step out certain other framework's ways by relinquishing the $ namespace temporarily. It does not abuse the prototype object to redefine how JS works. That was a very smart move. * Handle the obvious. JQ methods typically handle a wide variety of circumstances. If a method can be applied to everything in a set, it will be. If it only makes sense to return or mess with the first one, it will do that. Some things should always be explicit but it's silly to waste your time on things that don't need to be. I've never felt like I had to guess what was going to happen when I applied a method to a matched set. It's just implicitly obvious given the circumstances. * Trust the User? I'm not sure if Resig's a Python fan or that it was intentional but it's a powerful language that you can do some powerfully performance-killing stuff with if you're not careful. Throw some overly vague selectors followed by a .each() with the right function on a particularly large bowl of tag soup and you could have some serious slowdown on your hands on a more complex site. JQuery is easy to pick up but it doesn't limit itself with hand-holding or assumptions that you'll be using it to avoid learning anything about how JS works. * Keeps the core limited to the fundamentals. I think a pretty good job has been done with the avoidance of building overly specific functions into the core framework. It's not just a collection of somebody else's handy "kodez" that were stuffed into a text file with no regard for whether something was a building block or a prefab log cabin already painted purple. On a large modern site, you're likely to touch on everything eventually. That said, being able to break off specific categories into subcore modules would be a nice option for much smaller, lightweight sites. I don't always need Ajax or animation but I always want easy event handling, DOM traversal, and easy getting/ setting via the CSS selector approach. On Aug 28, 1:23 pm, lrbabe <lrb...@gmail.com> wrote: > jQuery and $, actually. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
