Ask YC: Does anyone here use jQuery?
10 comments
The jquery plugins are young, and you can usually find answers to all these things in #jquery on freenode. I'm surprised they break your IE, because jquery is one of the few libraries that does some very extensive optimization for IE, unlike some of the other top dogs.
I think a common paradigm is to develop for firefox (because it's convenient to debug with firebug, etc.) and then test in IE and figure out where IE's issues are. You'll learn things that IE doesn't like and avoid them in the future. IE doesn't have some of Gecko's js features, like generators and array comprehensions, so don't touch those. Also, in IE, a trailing comma in an inline object declaration is a syntax error:
var x={0,}; //i find this syntax convenient, so that always pisses me off
The event object disappears if your event handler invokes something to be done on a fresh callstack, even if you still have a reference to the object itself:
function someHandler(e){ setTimeout(function(){alert(e);},0); } //only lost when called via event invocation, and i'm not sure how widespread this problem is
Some DOM properties/attributes may be different/present/absent, but if you use jquery that'll be abstracted away. The event model in IE is lame (level 2 stuff), allowing you to attach only one listener per event per object, but jquery abstracts that away as well. What else... IE is known for leaking memory because each DOM element is actually a COM object, and cyclical references between the js engine and COM are undetected. There's a young tool called sIEve (currently v0.0.8) that can help you detect what leaked. anything else you want to know?
I think a common paradigm is to develop for firefox (because it's convenient to debug with firebug, etc.) and then test in IE and figure out where IE's issues are. You'll learn things that IE doesn't like and avoid them in the future. IE doesn't have some of Gecko's js features, like generators and array comprehensions, so don't touch those. Also, in IE, a trailing comma in an inline object declaration is a syntax error:
var x={0,}; //i find this syntax convenient, so that always pisses me off
The event object disappears if your event handler invokes something to be done on a fresh callstack, even if you still have a reference to the object itself:
function someHandler(e){ setTimeout(function(){alert(e);},0); } //only lost when called via event invocation, and i'm not sure how widespread this problem is
Some DOM properties/attributes may be different/present/absent, but if you use jquery that'll be abstracted away. The event model in IE is lame (level 2 stuff), allowing you to attach only one listener per event per object, but jquery abstracts that away as well. What else... IE is known for leaking memory because each DOM element is actually a COM object, and cyclical references between the js engine and COM are undetected. There's a young tool called sIEve (currently v0.0.8) that can help you detect what leaked. anything else you want to know?
JQuery also fixes the memory leaks if you remember to call .empty() or .remove() on any dynamically created elements on unLoad(). It nulls out all event handlers and DOM references, recursively, breaking the cycles that make IE hang onto memory.
Also, plugins use $.data rather than directly attaching information to DOM elements, which was added to fix memory leak problems.
Also, plugins use $.data rather than directly attaching information to DOM elements, which was added to fix memory leak problems.
All excellent pointers... thanks for the insight.
I have to admit I'm a total js newbie. jQuery makes it seem easy to pick up, but I know that if I had to do much outside of it I'd be lost.
I'm actually really surprised how powerful it seems. All that passing around of functions as data makes it fun to work with.
I have to admit I'm a total js newbie. jQuery makes it seem easy to pick up, but I know that if I had to do much outside of it I'd be lost.
I'm actually really surprised how powerful it seems. All that passing around of functions as data makes it fun to work with.
i think that jQuery mostly abstracts away the redundancy, not so much the complexity. so, in short, you have nothing to be afraid of :)
I do, and didn't notice any IE issues (though our JQuery usage has gone up significantly since the last time I tested with IE...)
It's quite possible that UI has issues though - it's not really a 1.0-quality release, more like an alpha release that they put out in public. I had to write 3 patches for UI Slider to even work, and much necessary functionality is either undocumented or unimplemented. There's supposedly going to be a release in mid-December to fix some of the outstanding bugs.
I haven't really noticed IE issues in general - I use CSS and portable libraries like JQuery and code to standards, and just do a single pass before release to fix any outstanding IE issues. Last time I did a release, it took less than a day to fix everything.
It's quite possible that UI has issues though - it's not really a 1.0-quality release, more like an alpha release that they put out in public. I had to write 3 patches for UI Slider to even work, and much necessary functionality is either undocumented or unimplemented. There's supposedly going to be a release in mid-December to fix some of the outstanding bugs.
I haven't really noticed IE issues in general - I use CSS and portable libraries like JQuery and code to standards, and just do a single pass before release to fix any outstanding IE issues. Last time I did a release, it took less than a day to fix everything.
Yeah I just submitted two patches for the UI Dialog. I guess I'll just have to sit down some day on a windows machine and deal with IE, even if I hate it. I suspect it's in the UI code, like you said.
Hi,
For IE debugging you can use DebugBar (http://www.debugbar.com/) and Companion.JS (http://www.my-debugbar.com/wiki/CompanionJS/HomePage) that give dev tools for developers : DOM inspector, HTTP viewer, JS console, etc...
Hope this helps.
JFR http://www.debugbar.com
For IE debugging you can use DebugBar (http://www.debugbar.com/) and Companion.JS (http://www.my-debugbar.com/wiki/CompanionJS/HomePage) that give dev tools for developers : DOM inspector, HTTP viewer, JS console, etc...
Hope this helps.
JFR http://www.debugbar.com
I used jQuery once as a very quick drop-in to replace some inline js on an internal reporting site. It was fantastic.
The changeover doesn't work in IE, though. I haven't had time to look at the problem in detail, but we're using XSLT to display the report in the browser, and $(document).ready() isn't firing.
The changeover doesn't work in IE, though. I haven't had time to look at the problem in detail, but we're using XSLT to display the report in the browser, and $(document).ready() isn't firing.
Check your CSS.
When I first used jQuery it wasn't working as I had expected it to. The stylesheets were invalid and apparently causing problems. Since then I haven't run into any issues with IE or otherwise.
When I first used jQuery it wasn't working as I had expected it to. The stylesheets were invalid and apparently causing problems. Since then I haven't run into any issues with IE or otherwise.
I lover jQuery but like others, I only use the core libary - I've yet to dabble in the UI library.
extJS support jQuery (as well as others) and is by far the best UI library available.
extJS support jQuery (as well as others) and is by far the best UI library available.
I use jQuery (with thickbox and wymeditor plugins) it seems to work fine in IE, but safari is a mess for me.
That's funny, we're using jQuery to avoid IE-related problems.
we use jquery at http://www.tastestalkr.com and we haven't yet found any IE problems.
never had an IE-only jquery problem, but I only use the core lib.
Just including the js files for the dialog and tabs components makes IE7 give me an awesome 'Operation Aborted' error page, which pretty much prevents debugging. While I'd love to just pretend that my users will have Firefox/Safari/Opera, I suspect I can't be that optimistic.
So second part of the question... what strategies do you employ to get your sites to play well with all browsers? (Do you develop for one then bugfix on the others, or try and learn all the quirks ahead of time, or just avoid anything risky?)