Might be an interesting exercise. Can you do that and let us know if it makes any performance difference?

There is no discernible performance difference, but there is a behavioral difference—this is just asking for unnecessary potential bugs.

agreed, this is not valid.

I would estimate a performance increase of roughly 0.01%. But thats not the point - Its about good programming practice. Think about your clients - There is a high probability of them learning something new when they see this.

Take your code seriously. Yes there is a risk of breaking functionality, but with about 5 minutes time and care you could change this without any risk.

Think about the clients please.

What part of "good programming practice" dictates that prefixing the increment operator is uniformly superior to postfixing it, except "where it makes sense"? With over are currently 94 instances of "++" in jQuery Core, I am fairly certain that going through, determining where it might be "appropriate," changing them all, and testing would take more than 5 minutes.

You can rest assured that we do take the code seriously, which is why with millions of users and installs, we can't just make a frivolous change like this in the name of unidentified clients "learning something new." It's also unclear who the "clients" in question here are, but most of the clients I work with in my day job are aware of the principle that "If it ain't broke, don't fix it," which applies here.

understood. will not comment any further.

i would like to point out however that the prefix increment operator is superior to postfixing, especially when incrementing objects of non primary type.

besides the fact that it is more efficient to prefix, given the fact that you have millions of users, its your moral obligation and responsibility to provide the absolute best solution in terms of functionality and semantics.

Replying to [comment:6 info@…]:

understood. will not comment any further. i would like to point out however that the prefix increment operator is superior to postfixing, especially when incrementing objects of non primary type.

The prefix and postfix increment operators are nearly identical, differing only in which side the operand value is derived from and which value is returned. Prefix operand is the UnaryExpression, postfix is LeftHandSideExpression. Prefix returns the new value, postfix returns the old value.

In the case of for loops, since incrementing generally occurs in what is referred to as the second optional expression, there is no behavioural difference as the incrementing expression is still evaluated to completion before continuing to the next iteration.

besides the fact that it is more efficient to prefix,

You keep saying this, but have yet to provide any proof.

given the fact that you have millions of users, its your moral obligation and responsibility to provide the absolute best solution in terms of functionality and semantics.

Knock off the soapboxing and bring facts to the table or don't post at all.

For proof: My apologies, I thought you already knew why it is more efficient. Thats why I didn't provide any proof.

When using obj++ a copy is made of the object before incrementation to be used in the expression. Then the object is incremented.

With prefix, no copy call is invoked.

So again, for primary types there is a very small performance increase. However, for objects such as iterators in c++, there is a notable difference.

In summary, for your incrementations in loops, the performance increase wont be noticable.. but when people learn that it should be used over postfix, then they start using it for user defined object incrementation which is why I am stressing this.

I also wanted to commend all of you on a beautiful product.

Replying to [comment:8 info@…]:

For proof: My apologies, I thought you already knew why it is more efficient. Thats why I didn't provide any proof. When using obj++ a copy is made of the object before incrementation to be used in the expression. Then the object is incremented. With prefix, no copy call is invoked.

This is not correct at all. Both operations create a copy and increment the copy by 1. Prefix returns the incremented value and postfix returns unincremented value.

So again, for primary types there is a very small performance increase. However, for objects such as iterators in c++, there is a notable difference. In summary, for your incrementations in loops, the performance increase wont be noticable.. but when people learn that it should be used over postfix, then they start using it for user defined object incrementation which is why I am stressing this. I also wanted to commend all of you on a beautiful product.

If you are correct, I should go back to my University and tell my prof he's wrong.

But I have a feeling he is right cause he's an amazing computer scientist..

Here's some proof (results found by using google searches)

1) Javascript specific:

http://jsperf.com/prefix-or-postfix-increment

2) http://www.parashift.com/c++-faq-lite/increment-pre-post-speed.html

++i is sometimes faster than, and is never slower than, i++.

3) http://stackoverflow.com/questions/3181211/prefix-postfix-increment-operators

It is typical that a postfix operator will be worse on performance because you have to create another copy before doing the increment (and this is why I've gotten in the habit of always using prefix unless I need something else).

With return-by-reference, you're returning an l-value reference to the current object. The compiler would typically implement this by returning the address of the current object. This means that returning the object is as simple as returning a number.

The biggest thing I dislike about the industry I work in is I am exposed to Egocentric programmers.

Wait, what?

Chrome http://i.imgur.com/o9dso.png

IE9 http://i.imgur.com/N7kkX.png

Firefox http://i.imgur.com/HvSKe.png

Safari http://i.imgur.com/bp7Fo.png

Postincrement wins on every run, and wins big on Chrome.

Well then, I was wrong!

I'm not egocentric, I just know how to read the spec.

http://es5.github.com/x11.html#x11.3.1

http://es5.github.com/x11.html#x11.4.4

I'll await your apology.

I apologize for not looking into the matter thoroughly before posting a ticket. Most of all, I apologize for wasting your time.

But I cannot apologize for some of the statements in my argument.

Just to clarify a bit, the unnamed professor referenced here likely knew what he was talking about and may even be right. However the second I saw a reference to C++ it becomes obvious what the problem is. Assuming your professor did not study javascript in particular, that's just the problem.

I've you've learned programming it is very likely that you don't have a clue on how JavaScript works or what its strengths and weaknesses are. It looks very familiar due to its syntax, but don't be fooled. It is in no way related to Java (according to some references, the name "javascript" is in fact a joke/prank against Sun Microsystems who owns the trademark on "Java". And Netscape (who introduced LiveScript which became JavaScript) didn't get along with Sun very well).

Other than that, Java and JavaScript has absolutely no relation.

Basically anything you know about programming languages, forget about it and start writing javascript the way javascript works, its can be tough to let go of old habits, but they no longer apply in the land of javascript. Even if things appear to apply and the result is satisfying, it may very well be a coincidence.

very nicely put. Thanks for submitting

Haha, you argued with me when I gave you purely technical, spec based arguments—but when someone responds with a largely incorrect story, you thank them?

\\o/

I retract my previous apology for wasting your time. You seem to be enjoying this.