I've given it (using jquery) some serious consideration. I haven't yet been in a situation where it'd produce better code or save time writing the code to use jquery. But, I keep it in mind.
Originally Posted by aj_nsc
But actually -- there is one effect that jquery might have helped with in retrospect. There's a fade effect on this page when a new post is made: http://www.thepointless.com/something ... I think jquery can do that. But, I enjoyed writing the fade. And it's a personal project site ... I'm more interested in playing with code there than I am "being productive" or "saving time."
All that jQuery does (for experienced developers) is save oodles and oodles and oodles of time.
...or save time writing the code to use jquery.
To say you've given jQuery some serious consideration, but haven't been in a situation where using it would save you time, then you're lying about one of those statements.
That's quite the accusation!
Originally Posted by aj_nsc
Bear in mind, I require the time-savings to outweigh any loss in execution efficiency, the necessary effect of using "swiss army functions." And don't forget the tendency, even for excellent developers, to drop best practices favor of shorter, "simpler" syntaxes.
Not a big deal for most applications. But, being a creature of habit, like the rest of mankind, I find it good to avoid using the shorthands, lest I become dependent on them in efficiency-critical solutions.
More importantly, don't assume anything I do requires jquery, or is even benefitted by jquery. I'm not one for sliding or fading tooltips, accordion navbars, etc. My needs are generally quite simple. Any my designs are simple. Both tendencies towards simplicity are deliberate.
That said, let's consider what I believe to be the single most useful method in jquery, and why it's often (but not always) better to avoid it. The $ method. When used with careful deliberation, it certainly saves a lot of typing, even for the basic and most commonly used scenario:
Much shorter, and arguably easier on the eyes. But, the 2nd line of code does WAY more than the first line -- advantageous in some cases, disadvantageous when you know what you're looking for. Based on a cursory read of the source, the 2nd line of code calls a method, which tests the given "object" first to see whether it's null, empty, or undefined, then to see whether it's already a DOM node, then to see whether it's "body" or something similar, then applies a series of matching and regular expressions to determine what to do with the string, determines that it's, in fact, an ID, finally calls getElementById(), wraps it, attaches some additional properties to, and returns something.
In the course of all this, the 2nd solution instantiates a minimum of 4 more local variables, performs at least 8 comparison, at least 1 fairly complex regular expression, and 3 additional method calls. And ... based on my 2nd look, there's even more that happens. I haven't studied the regex, but it appears as though our 2nd line above will fail the regex and call upon the find() to do what chould have been done to begin with:
Now let's consider something even more important than this ultimately roundabout means of grabbing a node: the tendency for developers to see a much simpler looking line of code and assume it's better to reuse that line of code than it is to cache the node, rather than to look it up again over and over and over ...
The developer who types document.getElementById(id) doesn't want to type it ever again. So, what do they do? They drop it in a local variable or a caching object, which is a very very very good thing to do! DOM calls are very very very expensive -- wrapping those DOM calls in a series of tests and methods increases the expense AND lures the developer into a false sense of efficiency. You start to think, "well, the jquery folks must know the most efficient way to do this. and the code is so small now. it must be better this way."
And that's not the case.
Now, I'm not suggesting we completely eschew $(). It's a second or two faster to type than the most basic alternative. And it's WAY faster to type than the series of loops necessary to fine an array of nodes by classname, for instance -- and then the subsequent series of loops necessary to deal with the resulting array.
But, I'm very familiar with the tendency to see the simplicity of $(id), and then to type it over and over in place of using it ONCE and caching the result. For most applications with low interactivity, it's not a notable concern. But, come time to develop a highly interactive application (web game, perhaps?), you'd best be well-accustomed to best practice -- something jquery allows us to to easily avoid, generally without a 2nd thought -- repeated DOM calls are bad enough for efficiency, wrapping them in layers on conditionals and other method calls can bring a real-time interactive application to its knees very quickly.
But, as Jeff alluded, the most notable examples of jquery use are amongst elite coders who know to cache the result of $() when it's needed more than once!
... That said, if ever I need to perform a lookup by CSS classname or develop an accordion style navbar, or am given a requirement for flying, fading tooltips, I'll be using jquery. But, after peering at the source and the API several times, I'm going to avoid it for anything less complicated.
It's probably fair to say that libraries like jQuery make good programmers better, and bad programmers worse.
Originally Posted by svidgen
Originally Posted by Jeff Mott
You're rambling argument again has little to do with whether jQuery is good or not and more about how people choose to use it poorly by doing this like:
Using jQuery does not make one a bad coder. If anything, people who don't know how to code start out using jQuery - and the beginners do use it poorly, for the most part - and, if they are excited at how easy programming is, they will continue to learn about programming and evolve their coding practices into much much better ones.
I am aware it was quite the accusation, but your ignorance of jQuery warranted it.
Oh please. I'm granting jquery plenty of merit. Don't defend it like it's your mother or naively suggest that defaulting to shortcuts is necessarily good.
... And I mean that in terms of your own, hand-written code too -- not just regarding jquery and other libraries. If you want to write your own, simplified $ method that simply wraps document.getElementById() to make your coding more bearable, you'd best not be using it in a loop! And you'd best still be caching the result!
Originally Posted by svidgen
Because when a new docytype comes out I write it once and never have to deal with it again. It's not like there's that much room for customization in a doctypes either. Also, if you aren't using templates and this means when you make a page you start off with a blank one and write everything out, it means you have more time than I do.
Originally Posted by pdiddles03
Back on topic, when you do a view source in Firefox the doctype is a redish color if it isn't the HTML 5 Doctype. When you highlight over the text, it says it is expecting the HTML 5 Doctype. HTML 5 might not be official, but it's the 800lb. gorilla in the room that's tough to ignore.
I believe we have been on topic. The conversation is evolving.
Originally Posted by spufi
I love this jquery discussion. Here I thought I was the odd ball for trying to avoid using it.
I am sure it has great stuff but usually when I am trying to do something I have never done before I like to learn how to do it myself, I like the challenge. And then once I have written the function, why use jquery for it in the future? And its better than jquery as it doesn't have the overhead.
As to the speed of development issue, don't you keep all your code. I have been programing for over 15 years (cough ... before jquery), I even have the first website a made, still (not that I would every use it). So if it comes to speed of implementing a new site if I use code from my collection it is faster than trying to get a generic library to work from jquery.
And back to the topic.
All the major browsers have been supporting the HTML5 doctype for a year now I would say its time to drop the XHTML doctype. But even on that note it looks like about 50% of users have browsers that are not compatible with HTML5 (IE8, IE7, Firfoxe 3.6, ect.), grr. People should have a year to upgrade after that they may find we don't write code for their browser. I would guess once Windows 8 hits later this year we will see much of that get resolved, but I don't see much reason not to start migrating to the HTML5 doctype now.
With the advent of HTML5, I've been wondering: is XHTML still relevant?
Last edited by _Krik_; 03-31-2012 at 09:24 PM.
Originally Posted by pdiddles03
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)