The "Write Less, Do More" tagline comes to mind. By standardising common, low-level tasks, jQuery allows the ambitious JavaScript developer to focus on functionality rather than reinventing the wheel in project after project.
On Aug 30, 11:58 pm, Erik Reppen <erik.rep...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
