Yehuda Katz

My comment above, just to be clear, only applies to *animating* table cells with slideUp or slideDown. That's because table cells can't get overflow: hidden and so can't animate smoothly.

What Bear said'll work great! Keep in mind, however, that animating table changes is still quite a bit of black magic, because table rows can't smoothly and reliably change size. If you want to change the size of a table row, you'll probably need to wrap all of the TRs in individual DIVs, give the DIVs overflow: hidden, and then shrink the divs.

something like $("tr.HLRow td").wrapInner("<div class='shrinky'>").find("div.shrinky").slideUp().parents("td:first").remove()

where you have the following in your CSS:
div.shrinky { overflow: hidden; }
[ January 21, 2008: Message edited by: Yehuda Katz ]

Congrats guys,

It was great hanging out this week and helping to answer questions. Who knows, maybe I'll stick around and post from time to time

FYI: jQuery just announced jQuery 1.2.2, which has a bunch of interesting new features. Check it out at jQuery 1.2.2: Second Birthday Present

This would be equivalent to adding a method to an existing class in Java. In effect, every time you do $("..."), you get an instance of the jQuery class.

By doing $.fn.foo = function() { ... }, you're adding a foo method to that class. jQuery itself and jQuery plugins are structured so that most methods return an instance of the jQuery class itself, so $("...").foo().bar().baz() will work (this is how "chaining", which is discussed in other threads, works).

This means that your code, assuming it's structured correctly, is indistinguishable for jQuery core code, and integrates into the chain with jQuery core code and other plugin code.

I agree with the above comments. jQuery's approach assumes that you at least tolerate JavaScript. It attempts to make that easier by making JavaScript fun (in, fact, a common first reaction to jQuery is "I've never had this much fun with JS before"), but jQuery is not really a drop-in-widget framework.

Using something like jMaki to abstract away the JS is possible, but then you pretty much lose all the pleasant benefits that come from writing JS code with jQuery.

Originally posted by Sapna Grover:
Does jQuery provide animation and effects support? Are there any extensions built on top of jQuery for the same?


Thanks
Sapna Grover

Yep! One of the four pillars of jQuery in Effects (they are DOM, Effects, Ajax, and Events).

jQuery proper comes with stuff like $("p").show(), $("p").show("slow"), $("p").fadeIn(), $("p").animate({left: "+=50px"}) and more.

jQuery Enchant, currently in the works and available via svn, adds $("p").animate({color: "#003333"}) and support for animating class modifications $("p").addClass("foo", "slow").

Cool, huh?

Oh, and as a side-note, I believe that the metric used by TIOBE is not quite fair.

Check out JavaScript's Google Trends:
http://www.google.com/trends?q=JavaScript&ctab=0&geo=all&date=all&sort=0

This matches TIOBE's declining popularity of JavaScript.

But take a look at JavaScript Libraries:
http://www.google.com/trends?q=jQuery%2C+Mootools%2C+Scriptaculous%2C+ExtJs&ctab=0&geo=all&date=all&sort=0

It seems as though the general search for JavaScript is declining, while searches for individual libraries are increasing.

Originally posted by Bear Bibeault:
Oh, if I could predict things like that I'd be playing the horses or stock market and be sipping a lovely beverage on my yacht.

Indeed. Things like ratings are an incredibly fickle metric, and it's hard to tell. That said, JS definitely has been attracting the interest of many more companies, and as the Software as a Service model continues to move forward, we're definitely going to see more use of JavaScript as a serious language in the Enterprise. We've already started to see it in a big way, but I suspect we've only seen the tip of a very large iceberg.

It's interesting to watch the developments around JS2 (ECMAScript 4), which add support for more traditional classes, interface, and typechecking to the language, as well as notions like packages, modules, and program units. This should help make JS more palatable on the server-side as well, which should help raise JavaScript's general profile.

jQuery was inspired by a number of things, including Dean Edwards' Base and the original Behaviours library that was written on top of Prototype. John is also friendly

Prototype's primary mission is to make JS more like Ruby; jQuery's primary mission is to make it easier to do DOM Scripting. See other threads from this week for more details.

There's a lot of jQuery's approach that has been adopted by Prototype. Most notably their revamped event system looks a lot like jQuery's event system. Then again, pretty much everyone has come on board with things like full CSS3 selectors and simplified events.

For an interesting historical perspective, check out John's initial post where he talked about the ideas that would eventually become jQuery: http://ejohn.org/blog/selectors-in-javascript/

HTML and CSS are core technologies of the web. Despite a number attempts to insulate you from those technologies, there is currently no real way to do non-trivial work without getting to know them. The good news is that both HTML and CSS are extremely easy languages to learn.

HTML is a markup language akin to XML with no programming features per s� (no control structures, no loops, etc.) CSS is style language that, for all its complexity, is also a relatively simple language. Its selector syntax is powerful mostly for its simplicity and its interaction with HTML. jQuery "leverages" CSS by allowing you to use the same selector syntax in JavaScript to bind behaviors to your elements.

The bottom line is attempts to insulate you from the relatively simple languages of HTML and CSS leave you in a muddled state that is actually more complex, especially when things go wrong.

Bear makes a good point. It would be entirely feasible to use jQuery's Ajax support only while using Prototype's class support alongside it, because jQuery's components are very tightly namespaced:

jQuery.noConflict(); jQuery.getJSON(function(json) { alert(json.node) });

Keep in mind that if you want to use jQuery's global callbacks for Ajax (such as setting callback functions for *every* Ajax call), though, you'll need to use jQuery exclusively for making Ajax calls.

I agree with Bear 100% about the namespace issues.

There are basically two camps amongst the JavaScript libraries: those that try to avoid namespace collisions and and those that don't. The former camp includes jQuery, YUI, Dojo, Ext, and a few others. The latter camp includes Prototype and Mootools.

jQuery and the other libraries that try to avoid collisions go so far as to avoid extending standard classes (like Array, etc.) and use other tricks like proxying calls through a wrapper (Bear has discussed the jQuery wrapper at length in other threads). As a result, using jQuery even with a single library like Prototype should not cause collisions (we consider a report that jQuery and Prototype are not compatible to be a legitimate bug ticket).

On the other hand, using Prototype and Mootools together is a recipe for disaster, since they both define the same global classes and override native classes with the same methods. Mootools goes as far as to say in their FAQ (quite honestly), that "mootools is not trying to be conflict free. Therefore, do not expect this to be a bug or unwanted behavior--mootools will not try to become conflict free. Expect, to make a choice between mootools and the other frameworks."

There's nothing wrong with taking that attitude; not trying to be conflict free allows you to make some interesting tradeoffs in terms of expressiveness of the API. But since most libraries don't go that way, there isn't a huge risk of namespace collisions in most combinations.

With all that said, once you start using the libraries, you'll see that each of them takes their own approach to an API. For instance jQuery places a huge premium on its "get some elements; do something with them API" while Dojo uses a much more traditional modular approach.

So while there might be some benefit to coming up with a nice underlying "private" set of functions for things like document ready (there's really only one way to do it), there wouldn't be much benefit in trying to compromise the approaches of the libraries into a single API. I don't know a single library contributor who would be happy with the results of such an attempt.

How feasible is the industrial application of a website developed with JQuery

What's most interesting is that some companies with their own high-profile investment in JavaScript libraries have units that use jQuery. Specifically, the Google Code website uses jQuery (even though Google sponsors GWT) and the AOL Pinpoint Travel unit uses jQuery (even though AOL sponsors Dojo and is a member of the Dojo foundation).

Barack Obama for President uses jQuery (and their site get a *lot* of hits). As Bear said, Digg uses jQuery (and Digg is so big that sites that are just featured on Digg get the so-called "digg" effect, so imagine Digg itself). BBC, the largest broadcasting company in the world, uses jQuery.

Finally, jQuery is embedded in WordPress, Drupal, Trac, and SourceForge, which combined are on a *ton* of sites. Bottom line is that jQuery is in a ton of "industrial" websites.

Originally posted by Bear Bibeault:
I don't think this technique directly maps to the C or M of MVC, but it is an off-shoot of the principle of sequestering things logically and reaps many of the same benefits.

It's more similar to the separation of concerns that we see in HTML/CSS (which is accepted gospel at this point). Separating behavior from markup is the next, cleaner step after moving style out of markup.

And it has the same benefits of making your behaviors more maintainable (you can have a set of behaviors that are defined by selectors which work across your site, just like CSS).

Originally posted by Gregg Bolinger:
When I look at ext-js vs jquery one thing comes to mind; Choices.

If I go to google and lookup ext-js plugins I get a bunch of results for things like "wordpress ext-js plugin" and "integrating ext-js with N framework".

If I go to google and search for jquery plugins I get what seems like an endless list of components, widgets, utilities, etc that were built with jquery as the foundation.

I'd say a better comparison would be ext-js with YUI. Both of which are fine I am sure but when I want a specific UI control for my application I like the fact that with JQuery I have choices. With ext-js it appears that you are pretty stuck with what they provide although you can skin everything.

Ext JS would be worthwhile to consider if you were considering Flash or Flex. It's a full-stack framework that builds your page, including layout, components, etc. from minimal or no HTML. It has a ton of facilities for things like setting up data stores, complex (and I mean complex) layout handling, and more. It's also a very large library.

It is not, however, very suited for progressive enhancement techniques, in which a perfectly good web site (that can be sucked in by Google, screen readers, or users with old browsers) is enhanced with the use of DOM and Ajax techniques. jQuery, on the other hand, represents the epitome of those techniques.

On a related note, it is possible to use Ext JS with jQuery as its base. Ext JS was original built on top of YUI, and then went on to support jQuery and Prototype/Scriptaculous, and finally built its own base library. All four options are still supported in Ext 2.0.