7 ms·

jQuery 1.4.3 Released

103 points by sant0sk1 16y ago

niyazpk 16y ago
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-javascript http://blog.stevenlevithan.com/archives/faster-trim-javascri...
- redstripe 16y ago
  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.
- IgorPartola 16y ago
  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.
konad 16y ago
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 http://en.wikipedia.org/wiki/Inner-platform_effect
- ergo98 16y ago
  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.
- niyazpk 16y ago
  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.
  - konad 16y ago
    You're not very good at reading signs. I've been building websites by hand since 1995.
    - niyazpk 16y ago
      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.
  - johnthedebs 16y ago
    "I wish there were something like JQuery for cross-browser CSS." Take a look at Compass http://compass-style.org/ 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).
- simonw 16y ago
  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.
  - dstein 16y ago
    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.
    - konad 16y ago
      That's where I'm coming from. But I guess it's just years of beind used to doing JS by hand.
    - Encosia 16y ago
      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.
- IgorPartola 16y ago
  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.
- swannodette 16y ago
  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.
  - simonw 16y ago
    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-dom/ http://perfectionkills.com/whats-wrong-with-extending-the-do...
- FooBarWidget 16y ago
  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.
- alanh 16y ago
  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.
catshirt 16y ago
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.
- jeresig 16y ago
  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.
  - catshirt 16y ago
    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).
vlisivka 16y ago
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.

103 points by sant0sk1 16y ago

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-javascript http://blog.stevenlevithan.com/archives/faster-trim-javascri...

redstripe 16y ago
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.
IgorPartola 16y ago
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.

konad 16y ago

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 http://en.wikipedia.org/wiki/Inner-platform_effect

ergo98 16y ago
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.
niyazpk 16y ago
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.
- konad 16y ago
  You're not very good at reading signs. I've been building websites by hand since 1995.
  - niyazpk 16y ago
    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.
- johnthedebs 16y ago
  "I wish there were something like JQuery for cross-browser CSS." Take a look at Compass http://compass-style.org/ 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).
simonw 16y ago
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.
- dstein 16y ago
  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.
  - konad 16y ago
    That's where I'm coming from. But I guess it's just years of beind used to doing JS by hand.
  - Encosia 16y ago
    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.
IgorPartola 16y ago
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.
swannodette 16y ago
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.
- simonw 16y ago
  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-dom/ http://perfectionkills.com/whats-wrong-with-extending-the-do...
FooBarWidget 16y ago
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.
alanh 16y ago
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.

catshirt 16y ago

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.

jeresig 16y ago
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.
- catshirt 16y ago
  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).

vlisivka 16y ago

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.