Earlier quoted context omitted.
What's even more hilarious is the code in his "My Library". I'm far too much of a generalist to consider myself a JavaScript expert. However, even I can pick out a number of items in his lib that shouldn't have been handled the way they are: - He declares $ in a global context without first checking for its existence; - He uses RegExp objects constantly -- in 50 different places in his full "mylib.js" -- including in…
There's a tradeoff between download time and execution speed there, and download time usually wins. I wrote the camelCaser in Google Websearch (basing it off Closure), and I used a simple regexp without memoization. You can burn a lot of cycles in the time it takes to download a hundred bytes over 56.6k, and often a camelCaser is used in situations like an animation loop where speed doesn't matter as long as you come…
- minifying and gzipping the javascript files is considered standard practice now, and the code I posted as-is is actually shorter than David Marks' case [* I lied! It's not, by 100 chars. Even shortening the object references kept it a bit longer. I don't think this defeats the rest of my points though.]. It could further be shortened, a lot -- to the point that for all practical purposes it's as small as a non-memoizing version.
- I tend to use a camelCaser in much more than simple animation loops -- any time for example that the style attributes for any element are referenced. i.e., it qualifies as an inner-most function.
- Although it's true that in animation loops you just have to beat the frame rate, let's keep in mind that there are a wide variety of processors and systems in use, and not everyone is using the latest dual-core Intel system with 3 gigs of RAM.
As a point of personal style, I much prefer to take the shortest, fastest, least-resource-intensive path for any given task, even if it's not strictly necessary to do so. As an end-user, I'm disgusted beyond description with the mindset that has become so prevalent among programmers, where efficiency is something that should be solved in hardware. It's absolutely frustrating that there are sites where the programmers have made so many concessions to speed in the name of rapid development that I can't even get the site to load in a few seconds on a 1.5 ghz G4.
So, yes, you're right, but I think the bit from David Marks' code is still naive and still does not make best use of the language:
camelize = function(name) {
var m = name.match(reCamel);
return (m)?([m[1], m[2].toUpperCase(), m[3]].join('')):name;
};