JQuery Code Smells | Hacker News Reader

JQuery Code Smells

james.padolsey.com

13 pointssmanek26 comments

> Prefixxing all jQuery objects with $

So don't do it. It's not required.

> Concatenating a bunch of things together to make a selector

This is semi-valid and using the jQuery.filter() function helps a bit. Overall though, it's not a huge problem, IMHO. Just put together the selector incrementally. Likely you need bits of that selector elsewhere anyways.

> Going over the top with chaining

I've written some complex code using jQuery and none of it had a chain as long as your example. Still don't see how this is jQuery's fault.

> Not caching collections

Then cache them. How is jQuery preventing you from doing this?

> HTML

This is just runs faster. When performance is critical, I find it acceptable to do this.

You've misunderstood the intent of the post. It's mostly my fault -- I shouldn't have named it "jQuery code smells". The point of the post was to list jQuery code snippets that exhibit "code smells", -- you seem to be under the impression that I think that jQuery itself, smells. And that couldn't be further from the truth.

Simple editorial fix: Add quotes to the title to clarify that you're referring to the noun, "jQuery 'Code Smells'", rather than making the statement that "jQuery Code is Smelly".

Actually, I was under the impression that you were putting the blame for sub-par code on jQuery, not on the people using it. I agree that most of these practices a at least a bit odd, but thankfully jQuery does not force any of them upon you.

> you seem to be under the impression that I think that jQuery itself, smells.

That's exactly what I thought ... until I read the article. Your intent seems pretty clear to me; but if a lot of people are misunderstanding you, that's a good sign you need to change the message to address the widespread confusion.

The article is not complaining about jQuery. A "code smell" is something in the code that is not necessarily bad in itself, but may indicate that the code's author is inexperienced or unskilled. Such code may contain subtler errors.

The author is pointing out coding practices that cause him to suspect that others' jQuery code may not be very good.

Agreed with regard to the HTML point. There are a bunch of things that can be done with string concatenation that can improve performance significantly. It may not be pretty to have HTML strings embedded in the JavaScript, but sometimes it is necessary to achieve acceptable performance.

  1. Use a slow js library framework abstraction layer! yay!
  2. Speed it back up a bit by using ugly messes of html strings

kind of silly complaints. all of them are situational and based entirely upon the coding style and preference of the individual.

What did you expect? It's a personal blog. Your comment is also based on your opinion and is representative of your preferences. And also, they're not complaints; through the post I'm trying to inform others of what are generally, bad practices. Sure, they're not all agreed upon as bad practices, but that's what the comments are for. Have you read all the comments? As the author of the post, I've found other's opinions to be invaluable to me -- maybe you should post an opinion that confronts the post's shortcomings, instead of just saying that it's "silly"...

if you want people to read your article with a discerning eye on the topic of what you think should or shouldn't be jquery best practices, you should probably mention that somewhere in the title or intro paragraphs. and maybe offer more than a sentence of explanation on the examples

right now it reads like "jquery code is ugly. here's some examples of how ugly it is". and people are simply pointing out that the ugliness is purely self-inflicted. the code examples don't need/have to be written as such. you can classify them as stylistic choices. so its more like "my jquery code is ugly" or "i found these ugly snippets online".

just my $0.02.

As an inexperienced jQuery user I expected more from the article. I have nothing against the author having issues with style but don't call them code smells.

Wikipedias definition of code smell:

"In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem."

I don't see the deeper problems with the smells the article brings up and if there are any the article could've done a better job explaining them.

I agree with you. I should have done a better job. I didn't expect it to be a popular post.

The sorts of issues I see with jquery are ones of gross inefficiency.

People use $ within loops without a second thought. Why wouldn't they.

It makes for quite ugly inefficient code IMHO. Having said that, it does fill a niche for people who don't want to sit down and learn javascript.

Yeah I hear you. But to be fair, if anyone uses jQuery to do a select that requires a lot of dom parsing in a loop, is jQuery really to blame? Even I avoid that and I'm not a real programmer or anything..

Anywho, my major use of jQuery is for dom parsing and manipulation. It's just so darn comfy! I still need to know javascript for all the rest of the stuff the app is supposed to do though.

I agree with the sentiment but the article is a bit over the top. Generally, I only recommend jQuery for small scope websites because it promotes what I consider to be poor code quality. Chaining may enable faster development, but it isn't worth sacrificing readability to get there.

I don't see how prefixing names with $ is a "smell". It's just a convenient way to differentiate jQuery objects quickly. sort of like "strVar" or "intVar".

Because it's dishonest, and makes for bad code.

$('body') looks to the uninitiated to be a simple variable. Maybe they come from the PHP world, so they think "Ah! that's just the variable body from the DOM, ok great.

When in reality, $ is the name of a mammoth function that could take ages to execute. It'll also execute every time.

  for (var i=0;i<1000;i++) {
    $('silly').doSomthing();
  }

This is horrible horrible code. It's calling the function $ 1000 times. Why?

I think you kind of missed something. The $ by itself in a variable name doesn't do anything. It's simply a notation to keep your DOM elements (and other variables / objects) separated from your jQuery wrapped elements.

$myDiv = $('#myDiv');

Now I know every time that $myDiv is already wrapped in jQ and I won't make the mistake of wrapping it again $($myDiv) in my code.

Yes, I know. My point is that most people won't know/bother doing

$myDiv = $('myDiv');

They'll simply use $('myDiv') all over the place which will be horrible.

so, the complaint is that people who don't understand jquery use it incorrectly/inefficiently?

meh. If you like it use it. Personally I find that code ugly, inefficient and error prone.

I'm a little confused here. First, let me echo my sibling comment by saying that, yes, $ is a function, but no, the name "$var" will not execute the $ function. To me it's a method of notation, as the sibling also said.

But you seem to understand that point, so I'm confused why you said what you said.

You're saying using $ as notation might confuse people new to jQuery and presumably javascript, who might not realize that $ is a function. You're saying that they would or might therefore conflate $var with $('selector'), leading to inefficient code?

So, I should abandon a concise convention because a tiny subset of the programmer population might misinterpret a detail of my code, causing them to implement superficially similar code in an inefficient way? Is this a problem you run into a lot?

I'm saying that using $ to name a function, isn't a good idea.

It looks cheap to use, but it's not. That's my point.

Same reason I hate those things in C# is it? where you can get some code to run each time a variable is read/written to.

Properties.

Properties make for some mighty clean code though.

I guess you have a particular bias toward protecting systems from crap programmers, which may serve you well in your environment. In my environment being concise wins because no one is an amateur.

Not really. I'm a sole developer at the moment, so I value efficient easy to read code. Mainly a matter of taste though I expect.

Reply on news.ycombinator.com