3 ms·
hey axod, I'm not sure what your previous exposure to jquery is but you really should try it if you haven't. I've used prototype and dojo over the years, but th
by geuis 18y ago
hey axod, I'm not sure what your previous exposure to jquery is but you really should try it if you haven't. I've used prototype and dojo over the years, but they don't hold a candle to jquery.
You are right in being suspect of speed issues. However, look at a common use of jQuery and compare it to straight JS.
$('a[href^="https"]').addClass('secureLink');
This one simple line selects all of the anchor tags on a page that are SSL links, then adds a custom css class to just those anchors. To write that in straight JS you would need roughly 7 lines, which includes an element match, looping through those, retrieving the href content of each one, doing a string match against the results, and adding a new attribute for the class.
At the end of it, the classic JS code isn't any more efficient and its a lot harder to write and read.
Additionally, since we've already selected the anchors with secure SSL links, we can do a lot more things with the jquery object without having to take the cost penalty of doing a new DOM lookup with getElementsByTagName and byId for subsequent operations. Lets chain some more operations:
$('a[href^="https"]').addClass('secureLink').appendTo( $('<div id="secureLinkDiv"/>'));
Now we're not only adding a custom class to the selection, we're moving all of our matching anchor elements to a new div that's being created on the fly called secureLinkDiv. This is very efficient because you're still operating on the initial object collection elements and you don't have to re-select the group for subsequent modifications.
In the rare cases where you can write straight JS that is more efficient than existing jQuery methods, regular JS mixes quite normally with jQuery. So you could use a selector like I did for the secure links, then iterate through that object and do your straight JS. Simple example:
$('a').each(function(i){
//reference each 'a' element by $(this) or with i
});
Writing javascript in jQuery has made it SO MUCH EASIER to code now that I can't say enough how remarkable the difference is. JS used to be a fun thing to mess with, and a tiresome chore when writing code for work. Now with jQuery my code is much leaner and runs better, its also fun to write again and opens up a lot of possibilities to easily create different effects that would have been hard to do before, simply because the code would have been too lengthy to efficiently write and then debug.
Give jQuery a try. Its worth it.
- axod 18y agoThanks for the response, I do admit I haven't really played with jquery in depth, just seen lots of code. However, it does seem like it is geared to "Find things in the dom" a fair amount. Whilst I can see that being handy for some websites, for webapps I can see less point - I know what's in the DOM, I put it there. If I need to do something with ssl links later, I'll just remember them all. In your example $('a[href^="https"]') I'd say it'd be a lot tidier and faster where possible to just give all https links a class and manipulate that class - sure, not as easy to do things like your 2nd example, which admittedly is kinda fun (Although seeing HTML in javascript strings always makes me feel very very sick). Several people seem to sell jquery etc on cross browser issues. But from my personal experience most of those issues are css layout issues - not js issues. Is that sort of thing covered in jquery?
- tptacek 18y agoMost UI code written in JS is a variant of "find something in the DOM and change it". Most JS frameworks are really UI frameworks. And in evolutionary terms, we are with JS where X11 was around the time when Xt came out; there's Motif if you want it, but I might just stick with Xt and wait for Gtk. What are the cross-browser issues you're thinking jQ won't handle for you?
- axod 18y agoThings like IE scrollbars covering the content, word-wrap weirdness, designMode idiocy.. Differences in how iframes are handled - Things like that. Not to mention all the IE6 rubbish like if you set left and right, it can't figure out width. "Most UI code written in JS is a variant of "find something in the DOM and change it"." I'd agree to a point, but I'd note that ideally you want to keep handy js references to what you have in the DOM so you don't have to find it again. And if you put it in the DOM, you don't ever have to find it, you just store it somewhere handy. Constantly performing search operations just isn't efficient.