XHTML -- Still Relevant?

Quote:

---

Originally Posted by aj_nsc

Try it and you might change your mind. I was the same way once when it came to jQuery and then I was blown away one day when I tried it and realized how much faster it makes working with dynamic UIs in the browser.

If you don't like it, then come up with something better.

---

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.

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

Quote:

---

...or save time writing the code to use jquery.

---

All that jQuery does (for experienced developers) is save oodles and oodles and oodles of time.

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.

Quote:

---

Originally Posted by aj_nsc

All that jQuery does (for experienced developers) is save oodles and oodles and oodles of time.

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!

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:


This:

PHP Code:

---

document.getElementById('some_id') 


---

Becomes this:

PHP Code:

---

$('some_id'); 


---

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:

PHP Code:

---

document.getElementById('some_id') 


---

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.

Quote:

---

Originally Posted by svidgen

jquery is used by folks who are not amateurs. These folks know whether it's more efficient to include library X or to reinvent a few parts. They know code should be maintainable and easy to read. And they could very well re-write all of jquery if they needed to. They understand some of the inefficiencies and pitfalls behind certain effects, they understand that nothing is magic; something is happening behind the scenes.

The same is not true of amateurs. Amateurs should not get in the habit of including libraries to accomplish things they do not understand. Amateurs should, on the contrary, be spared the indoctrination and rather be encouraged to produce good, clean, maintainable code before they're directed to any helper libraries.

---

It's probably fair to say that libraries like jQuery make good programmers better, and bad programmers worse.

Quote:

---

Originally Posted by Jeff Mott

It's probably fair to say that libraries like jQuery make good programmers better, and bad programmers worse.

---

Upvote.

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:

Code:

---

$('#someID').on('click',function(e) {
 $('#someID').addClass('someclass');
 $('#someID').animate({someproperty:somevalue});
});

---

Do not confuse the 2. If you're a bad developer, you're going to write bad code, whether it's bad jQuery or bad native JavaScript.

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.

Quote:

---

Originally Posted by svidgen

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!

Quote:

---

Originally Posted by pdiddles03

Why use a template when I can type it out by hand myself and make it exactly the way i want.

---

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.

The fact is, if you really want to become a real pro, you need to know javascript fluently Only knowing jquery makes you an amateur. The people on google who use jquery or any other site that does that is a major site are usually fluent in javascript and also use jquery.

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.

Quote:

---

Originally Posted by spufi

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.

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.

I get a lot of work from people who are trying to use a jquery library and can't get some particular functionality to work, that wasn't part of the library to start with. And guess what I usually end up resorting to raw javascript. I find third party anything to be problematic. Question, how much time is saved if you build a site with a third party library and then later you're asked to add in functionality, that the third party library was never intended to do? You maybe forced to start over, and there's all your time saved right out the door. Question, what if something breaks do to language changes? I guarantee the client will not accept an "I can't find the problem". Or to fix it, if it should take several days to rewriting a large section of code, than isn't yours, they may not accept that you will need to bill them for your time, now your working for free, or lost a client. I am speaking more generically about third party libraries, than jquery, but these are issues that can arise even with it.

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.

Jquery is javascript if they can write the code why shouldn't I, and I will probably save myself some hassle.

And back to the topic.

Quote:

---

With the advent of HTML5, I've been wondering: is XHTML still relevant?

---

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.

Quote:

---

Originally Posted by pdiddles03

I believe we have been on topic. The conversation is evolving.

---

The topic is the XHTML Doctype. jQuery is merely a side item. I don't consider it or CSS3 as "big things." CSS3 is just the latest standard just like HTML 5 is going to be. jQuery is merely rewritten JavaScript. I find more use in Ajax to be honest since it adds something that wasn't there before versus merely redefining what we could already do.