Comment by nothrabannosir | Hacker News Reader

Comment by nothrabannosir | Hacker News Reader

What surprises me is the lack of comments in the original file. This leads to e.g.:

    this._get(i).$$tmpFunc = f;
    this._get(i).$$tmpFunc(i);
    this._get(i).$$tmpFunc = null;

with the comment (from now):

So this may look crazy — it certainly does to me! Why not just do: f.call(this._get(i))? If I remember correctly, and I just did some double-checking and I think this is the case, but IE 5 didn’t support .call()! The original version of jQuery event worked back to IE 5… I can hardly believe.

I personally hate coming across snippets of code like this (usually from myself ): ). What do I do here? Can I just replace this with .call? Why did he not do .call? Performance? Or just MSIE5 (if I ever figure that out in the first place).

All my respect to mr. Resig, of course! What an almost legendary piece of software. Just interesting to see that this commentless programming is something of all pedigrees.

And a note to people saying "learn from this," please also learn that without the original author and rapgenius, we would never have understood that part. Or at least I wouldn't.

Also with all my respects to mr. Resig, but this is not really code to learn from. It's full of bad habits and it's hard to read. Poorly named, mostly uncommented and pretty hacky.

Not really judging, it was just a bunch of handy hacks he had for personal use.

Another reason it's hard to follow is of course: writing a CSS selector is not a trivial task, and that with all the browser quirks workarounds. I'm sure getting it working properly wasn't a walk in the park.

That said, he often talks about how he wanted to make the code look "cute" by making it as compact as possible and to save weight. Although weigh matters a lot in the web, the source code is a terrible place to optimize. Instead, write readable code, with sensible names, and then compact it with tools.

I completely agree. I tried to make a bunch of notes on the (poor) code quality, inline. This is mostly an attempt at archaeology, if you will. Naturally the current release (or even 1.0 release) of jQuery is substantially better code in every respect.

> and then compact it with tools.

Did we have minification tools back then?

Jepp: http://www.crockford.com/javascript/jsmin.html

    this is not really code to learn from

I used to work with someone who could look over my shoulder, read and evaluate my code, and then tell me where my bug was within seconds. He knew the code better than I did, and I'd written it! I asked him about this mad skill of his and he directed me to easily the worst programme I've ever read in my entire life. [1]

It was a block of unformatted, uncommented, dangerously typecast old-style C, with meaningless single letter names for variables and functions.

So I read it. It took a lot of study and I didn't cheat and run it through a pretty printer. I never really got to the point where I grokked it but my ability to read other code has improved a lot.

So whilst I agree that it's important to write code in the way you describe, I think it's well worth reading code that takes you out of your comfort zone from time to time.

[1] http://keiapl.org/rhui/remember.htm

Absolutely agreed - comments are so important! Seemingly when I was working on jQuery alone and without much feedback I was totally fine just having no comments. I noticed that in the subsequent releases of the code that the number of comments quickly rose - likely as people started to use the library I felt bad that the code was so poorly explained!

I still have 0.3 in my code base, and there are some gems like:

     // Arrrrghhhhhhhh!!
     // I overwrote the event plugin's .load
     // this won't happen again, I hope -John

BTW, do you know what happened to Dean Edwards. He was doing some really interesting work around the same time as you.

Reply on news.ycombinator.com