3 ms·

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 o

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 cases where a simple indexOf would be better, and, best yet, he doesn't bother to cache them in any of the dozen or so cases that I examined. Wasn't that one of his criticisms of someone else's code? - His treatment of camelCase is truly embarrassing, relying on an ugly RegExp every time it's called. Try something like this instead: _camelCases = {width:'width', height:'height'}; _camelCaser = function (p) { return typeof _camelCases[p] != 'undefined' ? _camelCases[p] : _camelCases[p] = p.replace(/\-(.)/g, function(x, y){return y.toUpperCase()}); } There, now you only need to camelCase the property for anything once. JavaScript's object handling makes caching this kind of stuff soooo easy. And, if you do have to have a camelCasing function, try to do it with as little overhead as possible -- use the tools that JavaScript gives you, instead of capturing the string parts in a match and then .join()ing them and all that other nonsense. His library doesn't demonstrate any of the kind of specialized language knowledge that he accuses other library developers of lacking, and it has at least some of the same weaknesses that he criticizes others' works for.

nostrademons 17y ago
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 in under the frame rate.
- thaumaturgy 17y ago
  I don't really disagree with you, however: - 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; };
  - thaumaturgy 17y ago
    Actually, I take some of it back! You had a good point about total size of the code being downloaded, so I went back and tried to see if I could shrink mine a bit without pulling any dirty tricks -- when I realized that a chunk of his code is 'hidden' in the reference to the regular expression object he's created elsewhere. With that added, and matching my code style to his, my version is less than 20 characters longer than his -- and that's without doing anything sneaky. But, maybe there just isn't a big difference in speed? So, I set up a quick test. Again, I wanted to be fair, so I could understand what was going on. The two tests are identical, I didn't advantage mine in any way or disadvantage his. The results? Given a list of 11 valid CSS properties to "camelize", some with dashes and some without, my code can camelize the set 20 times over in 1 to 2 milliseconds. The non-memoizing version can camelize the set 20 times over in ... 1034 to 1212 milliseconds. That's a significant difference, IMO. Tested on Firefox 3.5/Mac. ...all that said, thanks for reminding me about function size and download speed. I try to keep my own library at under 1000 source lines of code, but there are definitely some areas where I can sacrifice a few lines to lose a chunk of text. (Like, wrapping "typeof object != 'undefined'" into an "undef(object)" function.)
    - cloverfield 17y ago
      You missed the point. Well, several points. My Library was written years ago and the idea was to support "ancient" browsers like Safari 2 as well as all future browsers. As the fairly torturous test page still works in IE8 (all modes), Safari 4 and Chrome it would seem a rousing success. In the meantime, jQuery has been virtually rewritten to get rid of the browser sniffing. Guess where they got the ideas (and figure they botched their implementation). Yes, memorizing camelized styles would be more efficient, but then the library doesn't deal with hyphenated ones in the first place. It's used in exactly two places and neither has anything to do with styles. Instead, it deals with (very rarely encountered) hyphenated _attributes_ (you should have guessed, or God forbid read the code you were criticizing). And aren't you just picking one (tiny) bit that you can sort of relate to and mouthing off without any real clue about what you are talking about? <whine>And why didn't _you_ report it to the author to be constructive, build a community, etc. What an awful jerk!</whine> BTW, your version will blow up in Safari 2 due to the function passed to replace. Good luck with that!

nostrademons 17y ago

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 in under the frame rate.

thaumaturgy 17y ago
I don't really disagree with you, however: - 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; };
- thaumaturgy 17y ago
  Actually, I take some of it back! You had a good point about total size of the code being downloaded, so I went back and tried to see if I could shrink mine a bit without pulling any dirty tricks -- when I realized that a chunk of his code is 'hidden' in the reference to the regular expression object he's created elsewhere. With that added, and matching my code style to his, my version is less than 20 characters longer than his -- and that's without doing anything sneaky. But, maybe there just isn't a big difference in speed? So, I set up a quick test. Again, I wanted to be fair, so I could understand what was going on. The two tests are identical, I didn't advantage mine in any way or disadvantage his. The results? Given a list of 11 valid CSS properties to "camelize", some with dashes and some without, my code can camelize the set 20 times over in 1 to 2 milliseconds. The non-memoizing version can camelize the set 20 times over in ... 1034 to 1212 milliseconds. That's a significant difference, IMO. Tested on Firefox 3.5/Mac. ...all that said, thanks for reminding me about function size and download speed. I try to keep my own library at under 1000 source lines of code, but there are definitely some areas where I can sacrifice a few lines to lose a chunk of text. (Like, wrapping "typeof object != 'undefined'" into an "undef(object)" function.)
  - cloverfield 17y ago
    You missed the point. Well, several points. My Library was written years ago and the idea was to support "ancient" browsers like Safari 2 as well as all future browsers. As the fairly torturous test page still works in IE8 (all modes), Safari 4 and Chrome it would seem a rousing success. In the meantime, jQuery has been virtually rewritten to get rid of the browser sniffing. Guess where they got the ideas (and figure they botched their implementation). Yes, memorizing camelized styles would be more efficient, but then the library doesn't deal with hyphenated ones in the first place. It's used in exactly two places and neither has anything to do with styles. Instead, it deals with (very rarely encountered) hyphenated _attributes_ (you should have guessed, or God forbid read the code you were criticizing). And aren't you just picking one (tiny) bit that you can sort of relate to and mouthing off without any real clue about what you are talking about? <whine>And why didn't _you_ report it to the author to be constructive, build a community, etc. What an awful jerk!</whine> BTW, your version will blow up in Safari 2 due to the function passed to replace. Good luck with that!