jQuery 1.4.3 Released | Hacker News Reader

jQuery 1.4.3 Released

blog.jquery.com

103 pointssant0sk135 comments

Kudos!

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...

One of the big benefits off jquery or similar libraries is that they isolate you from the browser DOM differences. I happen to like getting IE6 support for free and I hope they don't stop supporting it for at least a few years.

John Resig stated that IE6 at this point is not causing any major pain points in developing jQuery. In fact he said he'd rather drop support for IE7 since that browser actually introduced two bugs that were not there in IE6. To me the performance gap between the IE family and the other browsers is what's driving the adoption of the alternative better browsers at this point. I'd rather be able to tell people that if they upgrade they'll have a better experience, than to have to tell them that they have no choice but to ditch IE.

things I am most excited about

- 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.

Data is not tied to attributed explicitly. It only pulls I the values on first call and then never again.

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.

wow, thanks john. and may i say, good choice on that implementation of data. :p

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

Am I in a minority when it comes to disliking jQuery ? It's like the ultimate Inner Platform

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

I take it as a sign that you don't work with HTML/CSS at all. For those of us who do, JQuery saves a lot of time and effort when working on websites that needs to be working exactly the same in all the web browsers.

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.

"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).

You're not very good at reading signs. I've been building websites by hand since 1995.

My Bad.

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.

Sure, jQuery creates a replica of the underlying system (the browser DOM), but it's a better replica in every way. Even if you ignore cross-browser compatibility, compare the following:

    $('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'); )

jQuery makes the DOM better.

The inner platform arises out of how the JQuery ($) function/object and all the methods behave.

Compare conventional DOM code:

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

To JQuery code:

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

Now what if you want to add debug statements between the style and event statements? Using JQuery you have to "undo" the inner platform in order to get access to the actual element object:

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

All of a sudden what made JQuery concise starts getting in the way.

You could do this by adding your own .debug() function. In some ways this would add an advantage, because you would be making your debug code reusable.

Example:

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

That seems like an unfairly contrived example.

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.

I wasn't talking about debugging techniques. It doesn't matter at all what you do between those statements.

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.

Fundamentally, jQuery is just a JavaScript API to normalize the DOM. It doesn't force you to program or organize your code in a certain way (i.e. Spaghetti coding). I'm honestly curious to see a legitimate example of what you mean.

"It doesn't force you to program or organize your code in a certain way"

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');

To simplify that (and not require a redundante DOM call) you'd use a local variable to store a reference to the element:

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

I argue that this is unnecessary when you could just write conventional code instead:

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

The way the $() function operates just doesn't sit well with all coders, regardless of how solid JQuery is in other respects.

That isn't necessary. This does the same thing:

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

Some use the convention that jQuery objects should be prefixed with $, so:

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

I do this, and like it, despite my classic aversion to both Systems Hungarian and GW-BASIC.

A few years ago I might have agreed with your statement. It was the reason why I used Prototype instead of jQuery: prototype extends the HTMLElement classes directly instead of requiring a wrapper object like jQuery does.

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.

It boils down to philosophy. Not all developers like the $() function. And it's not even specific to JQuery anymore, most libraries are doing this now. And for old school JavaScript developers, the "ninja-javascript" just doesn't sit right.

If you want to access the underlying DOM element (which I very rarely find myself needing to do when working with jQuery - the $-enhanced version provides methods for everything I might want to do with it) a shorter idiom than .get(0) is this:

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

you should be using a real debugger anyway

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.

No, it's not contrived - it's what people actually do. It seems perfectly reasonable to me.

'console.log(a_jquery_object)' works just fine. Firebug displays it as an array, allowing me to peek inside its elements. I don't know why one would need to get the underlying element before passing it to the debug-printer. I do this all the time and it has never bothered me once.

Oh dear, I seem to have mixed up the threads here. Kindly disregard...

That's where I'm coming from. But I guess it's just years of beind used to doing JS by hand.

That entire Wikipedia article looks like it's written by a Unix longbeard who hates anything but the most simple technologies even when there are good reasons to target the inner platform. The articles not only bashes Firefox but also HAL and fails to make mention of any counter arguments.

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.

For simple tasks jQuery is ok, for anything more than that I find it absolutely tedious (I usually pair with Underscore.js if I have to use it).

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.

I believe MooTools still makes extensions to built-in DOM classes, which other libraries avoid - even Prototype is moving away from that technique, and they were the first to popularise it.

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

I really don't think that applies, but I'm upvoting your comment because it's interesting and links to a concept that I haven't heard named before.

jQuery is somewhat guilty of doing this. I specifically am thinking of methods like $.each and $.trim. But at the same time I have just learned to think of it all as an adapter pattern. I'd rather have $.each work in all browsers than to have to check for whether forEach is available.

Yes, you are in a minority. Aside from simply promulgating best-practices of JavaScript usage, jQuery (and similar tools like prototype) have done tremendous good in moving the rich web forward: No longer were countless teams dealing with the same cross-browser nuances that ends up occupying the majority of most project time.

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

jQuery is good framework. jQuery + event driven programming - is excellent. jQuery + event driven programming + CouchDB + couchapp + Evently + Pathbinder - is astonishing. :-)

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.

Reply on news.ycombinator.com