"Professional Javascript" review

On Nov 1, 3:37*pm, VK <schools_r... (AT) yahoo (DOT) com> wrote:

John G Harris wrote:
You're just upset that no-one wants to believe your complicated and
incoherent description instead of our simple and clear version.

------------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If that was a joke then a really good one - I admit it.

Isn't that always the way? People who refuse to read and learn get
frustrated and blame the messenger for unwanted epiphanies. Easier to
live in Fantasyland I guess.

kangax wrote:

Garrett Smith wrote:
kangax wrote:
Here's a review of "Professional Javascript" by Zakas
(http://thinkweb2.com/projects/prototype/professional-javascript-review/)


Review review:

From the review:
| "Logically, a null value is an empty object pointer"
Plainly false. Null is a primitive value. In java (not javascript)
Reference Variables can have the value null, and what is written above
is conceptually fine for programming in java, but the type of thinking
might be better off abandoned for javascript programming.

Which is why I wrote "Some things in this chapter sound questionable".

Yes, that was clear.

[snip]

There is a long standing bug in JScript (still in the latest in IE8)
where the parameter in a |catch| block does not result in augmented
scope for that block. Instead, the identifier is added to the containing
scope.

Is this not mentioned?

It is. Here's an excerpt:

Ah, good.

Yep.

The FAQ should really have a section on Functions.

Or just a link to NFE article

It explains functions thoroughly.

For FAQ, maybe a short section with 1-2 questions, though.

For example:

What is |(function(){ /*...*/ })()| ?

A link to the closure article, and NFE article.


[snip]

| It would be nice to see alternative example which would avoid run-time
| try-catch in favor of single load-time test

I see. The performance video "speed up your javascript" also has an
example doing the same thing (against advice in that same video).

YUI is doing it too.

Could have used a generalization inference.

By abstracting common properties of instances, a general formulation of
how other such instances will behave can be inferred.

Such as:
var CAN_SLICE = false;
try (
[].slice.call(document.childNodes);
CAN_SLICE = true;
} catch(ex) { }

One could argue that it's a safer approach (testing features at run
time) but I have yet to see an implementation where, say, one element
would have certain property/method and another element (of the same
type) — didn't.

Making an assertion about the specific object based on what it does

would be stronger than making an assertion about what something similar
does.

However, generalization inference should not be ruled unsafe; the
situation needs to be examined to determine if such inference is
suitable.

| There were moments when I didn’t share same vision as Mr. Zakas, such
| as the one where he recommends to use comments in places where there
| are large amounts of code; I believe in a different approach —
| breaking code into smaller, more understandable chunks, rather than
| adding comments on top.

Your review should recommend your influence on advice for writing such
"clean code".

Not sure what you mean here.

You mentioned the book "Clean Code" to me before. That book discusses
functions with a strong emphasis on small functions.

In video:
http://www.viddler.com/explore/RoyOsherove/videos/15/
(Jorge should appreciate that)

Reminds me of last visit to the local planetarium...

Anyway, past the intro, he talks a bit about functions. Basically, the
same thing you're talking about -- keeping them short.

I've found that when I want block scope, it's time to consider another
function.

Example:

function a(){
var a, b, c, d,

// statements.
// [...]
if(condition) {
var q, w, e, f;
}
}

Contrived, but what I would consider in refactoring, is to extract the
part in the if(condition), followed by the vars, an eligible candidate
for Extract Method.

[snip]

If someone is looking for a book, this is the one I would recommend (and
maybe Flanagan's too). However, nothing compares to reading specs, clj
archives and constant practice. At least, this is how I grokked most of
what I know about Javascript

Practice, discussion, testing, code reviews.

--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

Garrett Smith wrote:

kangax wrote:
Garrett Smith wrote:
[...]
The FAQ should really have a section on Functions.

Or just a link to NFE article


It explains functions thoroughly.

For FAQ, maybe a short section with 1-2 questions, though.

For example:

What is |(function(){ /*...*/ })()| ?

A link to the closure article, and NFE article.

That would make sense.

[...]

| It would be nice to see alternative example which would avoid run-time
| try-catch in favor of single load-time test

I see. The performance video "speed up your javascript" also has an
example doing the same thing (against advice in that same video).

YUI is doing it too.

Could have used a generalization inference.

By abstracting common properties of instances, a general formulation of
how other such instances will behave can be inferred.

Such as:
var CAN_SLICE = false;
try (
[].slice.call(document.childNodes);
CAN_SLICE = true;
} catch(ex) { }

Yep, that's what I was referring to. Unfortunately, nothing like that
was present in a book.

One could argue that it's a safer approach (testing features at run
time) but I have yet to see an implementation where, say, one element
would have certain property/method and another element (of the same
type) — didn't.

Making an assertion about the specific object based on what it does
would be stronger than making an assertion about what something similar
does.

Definitely.

However, generalization inference should not be ruled unsafe; the
situation needs to be examined to determine if such inference is
suitable.

And time shows that this inference is generally safe. We'll see how it
turns out to be in the future.

| There were moments when I didn’t share same vision as Mr. Zakas, such
| as the one where he recommends to use comments in places where there
| are large amounts of code; I believe in a different approach —
| breaking code into smaller, more understandable chunks, rather than
| adding comments on top.

Your review should recommend your influence on advice for writing such
"clean code".

Not sure what you mean here.


You mentioned the book "Clean Code" to me before. That book discusses
functions with a strong emphasis on small functions.

In video:
http://www.viddler.com/explore/RoyOsherove/videos/15/
(Jorge should appreciate that)

Reminds me of last visit to the local planetarium...

Anyway, past the intro, he talks a bit about functions. Basically, the
same thing you're talking about -- keeping them short.

Yes. Keeping them short is the key to success Easy to comprehend,
easy to maintain, easy to test, easy to refactor.

It adds more overhead, though. We all know how function calls can slow
scripts down, especially in older engines without optimizations.

I've found that when I want block scope, it's time to consider another
function.

Example:

function a(){
var a, b, c, d,

// statements.
// [...]
if(condition) {
var q, w, e, f;
}
}

Contrived, but what I would consider in refactoring, is to extract the
part in the if(condition), followed by the vars, an eligible candidate
for Extract Method.

Exactly.

[...]

--
kangax