* The naming convention is terrible. 'canvasElement' sounds like it would be the canvas element, yes? No, it's the canvas jQuery object!
* Use of hard-to-read string concatenation.
* Use of .get(0) - use [0] instead.
And some non-jQuery objections:
* Unfortunate line continuation style that is hard to maintain (What if you change the length of the canvasElement variable name? You have to re-align it!) and falls apart in a proportional font.
* Inconsistent use of single vs. double quotes. I recommend single quotes for JS strings and double quotes for HTML attributes. Do it the other way around if you prefer, but at least pick one and stick with it!
* I'm reading the code out of context, but I'm guessing that CANVAS_WIDTH and CANVAS_HEIGHT are "constants". Why are they being used directly in the code like this? Shouldn't this code be wrapped up in a function that takes those as parameters?
Ignoring that last objection for the moment, I might write the jQuery version like this:
You're right, of course, that in this particular example jQuery has little or no advantage over direct DOM manipulation, but if they are going to offer a jQuery example, it ought to at least be a good one.
BTW the $ prefix on a variable containing a jQuery object is a very common practice in jQuery code. It's especially useful when you need both the jQuery object and the corresponding DOM element (assuming a single-element selector like '#foo'). Then you can use $ on the jQuery object and the same name without the $ for the DOM element:
That jQuery code is so horrible. What about if CANVAS_WIDTH is from an insecure source? Maybe someone sets it to include some of its own <script> tags or other tomfoolery.
your condescending tone aside, jQuery's API and vendor support is subject to change, especially in the coming months. last i heard, 50% usage also means 50% non-usage. you are also assuming that the target is a web browser, which is what jQuery is meant for. jQuery has no bearing on firefox extension programming, nodejs programming, or upcoming win8 RT and Firefox OS programming.
>your condescending tone aside, jQuery's API and vendor support is subject to change, especially in the coming months. last i heard, 50% usage also means 50% non-usage.
I'm afraid the points you make are not gonna help with my condescending tone.
50% usage? That's a HUGE success for a de-facto standard. There are even _official_ standards with much LESS use (SOAP comes to mind). So, the "50% non usage" part means absolutely nothing.
>you are also assuming that the target is a web browser, which is what jQuery is meant for. jQuery has no bearing on firefox extension programming, nodejs programming, or upcoming win8 RT and Firefox OS programming
Even if that was true, it would be irrelevant. Yes, a standard is only a standard is some SPECIFIC field. RS-232 is a standard, but has no bearing on, say, building construction. And those ANSI Screw size standards have no bearing at all in software: http://www.engineersedge.com/screw_threads_chart.htm
That doesn't make them any less standard.
That said, your examples are also false. jQuery can and IS used in nodejs AND in firefox extension programming. And presummably Firefox OS programming. Some examples:
Shouldn't the point of the "web platform" be that they make de-facto standards like JQuery obsolete? It seems to me that the examples and information on this site should be based on code that will work on all browsers without an intermediary between the code and the software these vendors (mostly) produce.
Original jQuery code:
'Native' code: Similar misgivings about the use of a jQuery plugin to read the keyboard later in the article.