Looks like the performance improvements are aided by the new native methods in the latest browsers. I wonder at what point they will stop supporting older browsers like IE6.

Here is the article on different JavaScript trim methods: http://blog.stevenlevithan.com/archives/faster-trim-javascri...

- data attribute support- now I can ditch my third party plugin. but i am curious- does this mean all current .data usage will now be tied to attributes? there were scenarios I was explicitly using data instead of dataset (for attributes)

- just started getting on board event based response systems (global listeners, overriding events, etc) as a way to help extensibility and minimize dependencies ... and I think the namespaces will help me organize a bit better. i suppose I will see at the time.

Event namespaces have actually been in jQuery for quite a few years now - we're just exposing that extra property now on the event object.

thank you kindly for such a wonderful tool (referring to the framework itself, of course).

http://en.wikipedia.org/wiki/Inner-platform_effect

Since JQuery was introduced, the time I spend on fixing cross-browser issues with my JavaScript has reduced by 90%.

I wish there were something like JQuery for cross-browser CSS.

Take a look at Compass http://compass-style.org/ - a framework for SASS (a CSS preprocessor).

It has a few major benefits over plain CSS, one of which is that it implements a lot of common things across browsers where possible (round borders, inline-block, etc).

I work on websites which have a lot of custom JQuery code and there is no way I can deliver them using hand-coded JavaScript in the required turn-around time.

Obviously YMMV.

    $('div').css('color', 'red') v.s. document.getElementsByTagName('div').style.color = 'red'

    $(el).replaceWith(otherEl) v.s. el.parentNode.replaceChild(el, otherEl)

    $(el).wrapInner(otherEl) v.s. something-too-horrible-to-contemplate

    $.ajax('/foo/bar/', function(data) { $(el).html(data); }) v.s (from memory, may be incorrect):

    var xhr = new XMLHttpRequest();
    xhr.open('GET', '/foo/bar/');
    xhr.onreadystatechange = function(ev) {
       if (ev.readyState == 4) {
           el.innerHTML = xhr.responseText;
       }
    }
    xhr.send(null); // !?
    
    ( the jQuery example can be shortened even 
      further to $(el).load('/foo/bar'); )

Compare conventional DOM code:

    var d = document.getElementById('elm');
    d.style.color = 'red';
    d.onclick = function() {}

    $('#elm').color('red').click(function(){});

    var d = $('#elm').get(0);
    // debug code
    $(d).color('red')
    // debug code
    $(d).click(function(){});

Example:

  jQuery.fn.debug = function(){ 
    if (console && console.log) 
      console.log(this); 
    return this; 
  };
  ...
  $('#elm').debug().color('red').debug().click(function(){}).debug();

Even so, you should be using a real debugger anyway at this point, not printf debugging. Stepping through tight code like that and observing some watches is very easy in a client-side debugger.

Any time you need to access DOM elements or do anything rudimentary JQuery just gets in the way because you can't even make use of local variables and for-loops without resulting in spaghetti code.

Yes it does. JQuery calls it "new wave JavaScript", but really it's just an anti-pattern. JQuery forces you to select all elements using $() before being able to use any of the methods. And you have to call $().get(0) to get the selected element out. It is this unnecessary process that gets very tiresome. Let's see if this makes it more clear:

  $('#elm').color('red');
  /* do some stuff here */
  $('#elm').text('new text');

  var d = $('#elm').get(0);
  $(d).color('red');
  /* do some stuff here */
  $(d).text('new text');

  var d = document.getElmentById('elm');
  d.style.color = 'red';
  /* do some stuff here */
  d.innerHTML = 'new text';

  var d = $('#elm');
  d.color('red');
  // do some stuff here.
  d.text('new text');

  var $d = $('#elm');
  $d.color('red');
  $d.text('new text');

But for various reasons I've switched to jQuery half a year ago, and I've never looked back. I can't say that the $() stuff is that much of an issue: it's clearly documented, easy to use, and I find the general DOM methods to be so useless that I'm only using the Prototype/jQuery methods 90% of the time anyway.

Your claim that it's an anti-pattern is way exaggerated.

    var el = $('#el')[0];

I know that I should, and if you know a "real" debugger that works under IE7 (and preferably IE6) that is more powerful than print debugging I'd love to hear about it.

An file browser inside Firefox may seem nonsensical at first, but if you consider cross-platformness and distribution then it actually makes sense. Writing and distributing a cross-platform desktop app is a complete pain even when using things like wxWidgets and QT. The HAL bashing seems to be based on few facts and only on the biased notion that it's redundant. HAL has brought many usability benefits the past few years. Unlike udev it is not Linux-only. Querying HAL is also a lot easier than querying udev or the favorite /proc or /sys directory of the day. HAL is not being phased out in order to go back to raw udev, it's being phased out in favor of DeviceKit which is like HAL 2.

I also generally disagree with many of the design decisions in the jQuery API.

I think it's interesting that MooTools has been around for about the same amount of time, covers the same functionality, covers more functionality, and IMO better designed ...

Yet it's not nearly as popular. C'est la vie.

http://perfectionkills.com/whats-wrong-with-extending-the-do...

Well...they still are...just not as much.

I found that it worth to reimplement CouchDB interface in PHP just to be able to reuse same Evently widgets in PHP part of my application.