About Yehuda Katz

I've been doing web design since the mid-to-late '90s, and been doing computers since my formative years. I've recently gotten into Rails and jQuery (Rails first, jQuery second). I'm in the process of developing a Rails drop-in to use jQuery instead of Prototype as the default Rails Javascript library. That entails replacing a ton of helper functions (and eventually looking at RJS), and I've barely scratched the surface. If anyone's interested, I could totally use the help. I'm also working on a hush-hush wiki called Anarki (more on that as the project develops). In my professional life, I'm working for a large non-profit in Borough Park, NY, and doing a bunch of freelancing for a Manhattan startup. I'm also doing a Google Summer of Code project this summer, working for the Oregon Virtual School District.

jQuery in Action (Get 30% Off!)

Posted on by

Hey guys,

As many of you already know, I have been working on jQuery in Action, a book on jQuery for Manning Publishers.

Almost the entire book is available on MEAP (Manning Early Access Program), and it's going to be published in December of this year.

The book itself is pretty awesome. It tries to give you the information you need with a useful narrative, including motivation for certain parts of jQuery. One of the greatest things about the book, in my humble opinion, are the labs, which allow you to test out parts of jQuery without having to throw together an entire test case. For instance, there's a selector lab, which lets you see, visually, which elements will be selected by a given jQuery selector, and a drag/drop lab, which lets you test drag options via radio buttons and then see the results in action quickly.

It's currently the only book out that covers jQuery 1.2, as well as the important parts of jQuery UI (including stuff like the undocumented callback object that you get in the draggable/droppable primitives). Toward the end of the book, you get full-chapter examples (my favorite is the Ajax chapter, which covers building an Ajaxified store selling boots ;) ), and focuses heavily on jQuery best practices and Unobtrusive Scripting.

The book itself is very much in the spirit of jQuery: short and to the point, while covering the important background material necessary to fully understand the topics at hand (especially non-trivial topics like event binding and Ajax).

Without further ado, you can purchase the book (you'll get the prerelease stuff now and the complete book when it's released in December) at Manning's Site. If you use the coupon code JQM30 before the end of October, you will also receive a 30% discount.

Visual jQuery Magazine: Part Deux

Posted on by

Those of you who have been around for a while know that in September of last year I published the first issue of the Visual jQuery Magazine. In October, the magazine was also released in French.

The mag had interviews with important jQuery community members (like creator John Resig, plugin editor Dave Cardwell, etc.), articles on jQuery features and implementations, and even a piece or two on alternate Javascript libraries, complete with quality graphics and original art.

The positive response was incredible, and people really seemed to like it. Unfortunately, though I’d initially planned on making the magazine a monthly publication, things fell to the wayside as my schedule got progressively more hectic. Since Issue 1 I’ve found a new job (new then; about eight or nine months old now), moved across the country (NY to CA), and gotten a huge chunk of the way through writing my first book (stay tuned for details!). Clearly, things have been busy.

The lack of Issue 2 has been bugging me since Issue 1, and I’ve decided it’s time to make it happen (this, I admit, is also largely in part to my good friend Rey Bango’s recently renewed effort to push jQuery forward). Thankfully, the magazine’s lead designer and the team of French developers/translators have all expressed an interest in helping make Issue 2 happen, which makes this goal a lot more tangible.

Issue 1 was an experiment, and it went really well. Since it was a first though, it was very much “the Yehuda show.” I’d like Issue 2 to be more of a collaboration of contributors; there are a lot of jQuery topics to explore, and a lot of team member and users with fascinating tales to tell.

As such, I’m putting the word out there. I’m looking for contributions for Issue 2 of Visual jQuery Magazine. Articles can vary in length extensively, from brief three paragraph shorts, to three page features. They can be tutorials, feature articles, interviews and lots of other things I’m sure you’ll all think of. Just a few brief (and somewhat flexible) guidelines:

  • The article must be in magazine or newspaper format (if, in fact, your submission is a piece of writing — illustrations will also be considered). I’m extremely lax on this, but it should be something you could see being in a magazine.
  • The article must be about a topic that is timely and pertinent to the jQuery community, with broad appeal.
  • The article must not be an advertisement (but it may, obviously, feature a plugin you have written if it has broad appeal).
  • The article must be factually correct.
  • The magazine staff will edit your article for grammar, space, and style. You will receive an edited copy prior to publication for approval.
  • The magazine staff will add graphics and other visual elements as appropriate.
  • Please email a proposal or brief description of your submission before spending a chunk of time working on it; that way we can avoid running out of space and ensure that everything print-worthy gets in. Email submissions and letters to the editor to editor AT visualjquery DOT com.

    As I said from the beginning of this project, I think that the magazine has real potential to open up the jQuery world to new users, and hope that by pushing the envelope of community-produced content, we can keep jQuery moving forward in it’s current positive direction. I, for one, I’m really excited about it.

    I will also be accepted advertisements, with all proceeds to go to the jQuery project. If you’re interested, please email me!

    New Command-Line jQuery Tool

    Posted on by

    Update: I have completely refactored jcheat and added substantial new functionality, including a ton of filters that can be used in any combination. Do a gem update and run jcheat -h for full usage details.

    I released a new tool, jquery-cheat, that allows you to get information about the jQuery API directly from the command-line. You can get the description of a function, a list of functions in each module, search the list of all function descriptions for a string, get a list of all functions whose name match a string, and some other cool tricks.

    Some examples:

    # jcheat desc clearForm
    Name:         clearForm()
    Description:  Clears the form data.
    Details:      Clears the form data.  Takes the following actions on the
                  form's input fields:  - input text fields will have their
                  'value' property set to the empty string  - select elements
                  will have their 'selectedIndex' property set to -1  - checkbox
                  and radio inputs will have their 'checked' property set to
                  false  - inputs of type submit, button, reset, and hidden will
                  *not* be effected  - button elements will *not* be effected
    Returns:      jQuery
    |                                   EXAMPLES                                   |
    | Description |
    Clears all forms on the page.
    | Code |
    # jcheat namelike $.ajax
    $.ajaxTimeout(time) in Ajax
    $.ajaxSetup(settings) in Ajax
    $.ajax(properties) in Ajax
    # jcheat like clear field
    clearForm() in Plugins/Form
    clearFields() in Plugins/Form

    You can grab the tool by doing:

    gem install jquery-cheat -y

    The -y is so that it automatically includes hpricot, a required dependency.

    jQuery Session at RailsConf

    Posted on by

    RailsConf 2007

    I’m happy to announce that my proposal for a Birds of a Feather session about “jQuery on Rails” at RailsConf has been accepted!

    If you’re at RailsConf, please come by room c125 on Thursday night at 9:30pm and join in the discussion. I’ll be chatting about my ongoing work on jQuery on Rails, and should have some code to demo if anyone would be interested.

    If you’re interested in hearing about how others have solved problems regarding the integration of jQuery with Rails, or just want to share something cool you’ve done, swing on by. See you there!

    More Details

    Yehuda has just posted more details on how jQuery on Rails works:

    Since I last publicly discussed jQuery on Rails, I’ve gone down a lot of avenues, and written a lot of code, and came to some conclusions:

    • jQuery and Unobtrusive JavaScript are fundamentally incompatible with an attempt to describe behavior inside markup, as Rails does via “JavaScript helpers.”
    • Attempts to fix the problem, specifically UJS for Rails, still require that you include your JS behaviors in your views, which are then marshalled into JavaScript files on the fly (and cached as appropriate). If you wanted to include the same JS behavior in multiple pages, you’d need to create custom helpers and call out to them.
    • jQuery is already the perfect mechanism for unobtrusive JavaScript, baked right into the library
    • The biggest problem faced by jQuery developers is not simplicity (which, again, you get for free in the library), but difficulty in including the correct jQuery “modules” in the Rails views that require them.

    The most common problem with using jQuery with Rails in an app of moderate or higher complexity is the trade-off between including everything in a single application.js (which can lead to serious slowdowns in larger apps) and having multiple, modular files (which are a serious pain to include correctly as needed).

    This is a problem for jQuery users who want to use Rails more than Rails users who are used to Prototype helpers and want to be able to use the jQuery library as a drop-in replacement. In the first release of jQuery on Rails, I will be targeting jQuery developers who want to work with Rails. In other words, jQuery on Rails is for you if you know jQuery or are willing to use jQuery.

    This release of jQuery is not for you if you don’t want to learn jQuery, and want to program purely in Ruby. There will be a future release that will include some features for pure-Ruby developers, but I maintain that Unobtrusive JavaScript is fundamentally incompatible with that mode of thinking.

    With all that said, what does jQuery on Rails actually do?

    First up, it’s a Rails plugin, which you activate by adding <%= include_jquery %> in your application.rhtml. When your server is started, it’ll parse all of your JavaScript files, and identify selectors in those files. When include_jquery is called in your layout, it’ll get the rendered HTML and use Hpricot (which shares syntax with jQuery) to determine whether any instances of the selectors identified on server startup are present.

    The JavaScript files that have selectors that are also present in your HTML will be loaded, and run as expected.

    So in short:

    • Create your JavaScript files, using selectors as usual
    • Use include_jquery in your layout
    • You’re done

    The jQuery IRC Channel

    Posted on by

    In addition to jQuery’s great Mailing List and Documentation, there’s another place where users can seek help about jQuery problems: We have a very active jQuery IRC channel.

    Even though it’s never really been publicly announced, the channel currently averages over 50 simultaneous users, including some friendly jQuery bots! Hosted on irc.freenode.net, #jquery always has users who are online and willing to answer your questions (of which, they are often answered within minutes of their being asked).

    Here’s the information that you will need in order to connect to the channel:
    Server: irc.freenode.net
    Room: #jquery

    jQuery team members, especially John Resig (nick: JohnResig), Joern Zaefferer (nick: JoernZaefferer), and Yehuda Katz (nick: wycats) are frequently in attendance, helping experienced and new users alike with both complex and trivial problems.

    The IRC Channel is best if you need quick help with any of the following:

    • JavaScript
    • jQuery Syntax
    • Problem Solving
    • Strange bugs

    If your problem is more in-depth, we may ask you to post to the mailing list, or the bug tracker, so that we can help you in a more-suitable environment.

    Additionally, we recently started logging the channel, so you can now look back through to find answers to your old problems: jQuery IRC channel Log

    Visual jQuery Magazine Released

    Posted on by

    Issue 1 CoverThe first issue of the brand-new Visual jQuery magazine has been released. It is available for download in PDF format.

    The purpose of the Visual jQuery Magazine is to provide information about jQuery for beginners and advanced developers, interviews with interesting members of the jQuery community, and details on how to maximize your use of the framework through plugins and other tips.

    The first issue includes:

    • An editorial comment about the magazine
    • Winning on Philosophy: Why jQuery’s Approach Works
    • The Man Behind the Magic: An interview with John Resig
    • jQuery Tutorial: An introduction to the jQuery object
    • Plugins for rich application development.
    • Meet Dave Cardwell, the developer of jqBrowser and jqMaxMin
    • A cool back-page ad (trust me, you want to take a look)

    Issue 2 will feature more of the same jQuery goodness:

    • Meet Klaus Hartl, the developer of jQuery tabs who works on Plazes
    • jQuery Tutorial: An introduction to jQuery’s AJAX functionality
    • Plugins useful for visual effects
    • Letters from our readers

    So run, don’t walk, and download the magazine today!

    Update: Please digg the magazine or add it to your other social bookmarking sites like delicious.

    Taking jQuery Documentation to the Next Level

    Posted on by

    jQuery 1.0 solidified a lot of the framework, but it also introduced some neat structural changes.

    First up, the framework now builds via make files, so anybody can check out jQuery from subversion and compile either the packed or unpacked jquery.js for use in their website.

    Second of all, jQuery now includes built-in testing, and the make file can build the test suite, which the user can then run in his favorite browser to make sure that the latest checked in version is up to snuff. There aren’t a whole lot of test cases written so far, but that should change moving forward (primarily because it’s so easy to add them).

    Most important for me, however, has been the inclusion of inline documentation. Beginning with version 1.0 of jQuery, the documentation of the framework is included in the source files themselves, and John Resig, jQuery’s maintainer, has written a parser that will spit out an XML version of the documentation as part of the makefile (a simple make docs will build the documentation).

    Visual jQuery

    In the run-up to 1.0, I converted the old Visual jQuery site from a Rails-based solution, that required manual entry of functions, into a site that loads the documentation on the fly as it’s committed to the trunk.

    For the less-technical, that means that Visual jQuery will now be updated pretty much as soon as jQuery is updated. Lots of people have found the visual documentation convenient and easy to use, and the new version strives to continue that ease of use.

    Thanks to John, the file that his parser spits out is very well optimized for sites like Visual jQuery. He has really made good documentation a priority this time around. And from my perspective, a major part of what sets jQuery apart from the competition is its emphasis on providing readable, good documentation. I’m happy to say that jQuery has made the right choice here. Within the next couple of days, John will have fully documented all jQuery functions (there are a few still to go), and the visual documentation will fully represent the jQuery API.

    Visual jQuery Magazine

    The Magazine

    With that, I have a couple of announcements.

    1. Visual jQuery is going to get a major new feature sometime in the next week of two. Specifically, users will have the ability to filter functions (by name and description) through a live-search box. That capability will make it easier to find specific functions.
    2. Visual jQuery is launching a monthly online magazine. It will be released in PDF format, and will be available free of charge. The first issue will include an interview with John Resig, our first in a series of articles about the newest and greatest jQuery plugins, and a visual look at the jQuery Object, the centerpiece of the entire jQuery framework. The Magazine will be released the third Wednesday of every month, so Issue 1 of the Magazine, the September 2006 issue, will be released on September 20.

    As always, check out VisualjQuery.com for the latest Visual jQuery Documentation and further announcements about the Magazine.

    Why jQuery’s Philosophy is Better

    Posted on by

    There have been a whole bunch of posts on this blog about the differences in code size between jQuery and Prototype. The basic premise of those posts (which I agree with) is that because of the way jQuery code is structured, all sorts of typical Javascript design patterns are rendered shorter and simpler in the framework when compared with Prototype.

    For the longest time, I was a confessed Prototype junkie. I discovered the framework when I started doing Rails work, and for Rails developers, there is very little alternative. Prototype, in all its ugliness, is baked into Rails, and it’s very difficult to give up the productivity gains Rails provides by coding Javascript by hand. Going further on a tangent, that’s why I started working on jQuery on Rails, which aims to allow Rails developers to use jQuery as a drop-in replacement for Prototype.

    But back to the purpose of this post, there’s something more fundamentally different about jQuery’s programming sense than just its code size. In fact, the difference in sensibilities is very similar to the difference in sensibilities between Java and Ruby, so it’s ironic that the Rails community has embraced Prototype so completely.

    Let’s take a look at some code comparisons. First up, adding some arbitrary HTML after a particular node.

    In Prototype:

    new Insertion.After('myId', 'Arbitrary HTML');

    In jQuery:

    $('#myId').after('Arbitrary HTML');

    Now, we haven’t done much by way of reducing code clutter (although jQuery’s is cleaner), but there is a fundamental difference in the way that Prototype and jQuery each approach the problem.

    Prototype creates a series of monolithic classes that each encapsulate some functionality. Developers then pass in an id, and some other parameters, and the class does what it’s supposed to do. Very much like the Java way of encapsulating functionality (like the Math class, for instance). NOTE: That’s not to say that Java couldn’t do things this way.

    jQuery approaches the problem in a fundamentally different way. It sees sets of HTML nodes as objects to pass messages to (more like the traditional Ruby way). So instead of having a separate class that adds text after an HTML node, jQuery glues the functionality onto the jQuery object, which is returned by the $ function. By contrast, Prototype’s $ function returns a vanilla DOM node.

    Prototype attempted to achieve similar functionality with its $$ method added in the latest RC of the framework, but there’s a fundamental difference. While Prototype’s $$ returns an array of DOM Elements, jQuery’s $ is the fundamental underpinning of the entire framework. Virtually all jQuery functions bind to the jQuery object, which is returned by the $ method.
    The benefits of the jQuery way are highly visible:

    • Chainability. Because jQuery objects have functionality glued onto them, they return other jQuery objects, which the developer can then pass additional messages to. The trivial example on the jQuery website is $(“p.surprise”).addClass(“ohmy”).show(“slow”);
    • Use of CSS selectors and XPath operators. Because jQuery passes messages to objects, it can (and has) implement additional selector functionality into the $ method. The methods that are glued onto jQuery objects just see an array-like object that holds a series of DOM elements. It doesn’t care how we got them. So plugin developers can add additional parsers into the $ method, or glue additional functions onto the jQuery object rather easily.
    • Which brings us to plugin development. The jQuery way is very conducive to plugin development. It’s quite easy to add functionality that takes advantage of the jQuery object, and jQuery plugins are usually much shorter than their counterparts. jQuery Plugins
    • Automatic looping. jQuery methods are required to automatically loop through all DOM elements in the array, and apply the desired method. So $(expression).after(‘some HTML’) transparently adds the HTML after every single element returned by the expression. $(‘p’).after(‘some HTML’) will add ‘some HTML’ after every <p> on the page, for instance. Personally, I find the elimination of iteration in my code (in most cases) to be one of the top practical, day-to-day benefits of using jQuery.
    • Builds on itself. As jQuery has matured, it’s become easier to build plugins on top of the existing architecture. Because all jQuery functions automatically loop, using existing jQuery functions means that annoying iteration is all but gone.

    There’s more, but the thread that runs through all of the benefits comes out of the very meticulous way that John Resig has made the jQuery object/array accept passed messages, rather than build various monolithic functionality blocks, each of which must be built from scratch.

    Some other examples:
    AJAX Updater in Prototype:

    new Ajax.Updater('placeholder', url, { method: 'get', parameters: par });

    AJAX Updater In jQuery:

    $('#placeholder').load(url + par);

    Note: This example doesn’t deal with the obvious iteration benefits we get if we wanted to load the response into every <p> object, for instance.

    Adding a class to an element in Prototype:

    Element.addClassName('element', 'className');

    Adding a class to an element in jQuery:


    Adding a class to a group of elements in Prototype:

    $$('.element').each(function(node) {
    Element.addClassName(node, 'className');

    Adding a class to a group of elements in jQuery:


    That last one is the clearest example of the difference in methodology. Because jQuery is passing messages to jQuery objects, the code is barely changed. jQuery doesn’t care that we’re now adding a class to a group of objects instead of one object; the underlying code is the same (add the class to the set of elements in the object). Prototype, on the other hand, requires an iterator.

    And as your code becomes more complex, jQuery’s scales easily, while nested loops become the norm in frameworks like Prototype.

    [UPDATE] An astute reader (Mislav) pointed out that Prototype does indeed do just a bit of what jQuery does. Prototype seems to bind the Element class to DOM Elements, allowing things like $(‘myElement’).hide(), and such. However, it only applies to the Element module, and seems to only work on single DOM elements. Binding the Elements module is cool, but it’s more an afterthought than the way jQuery makes it a fundamental design decision.