"Professional Javascript" review

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

The book is pretty big and I didn't have much time, so the coverage is
not as extensive as it could have been. However, it should serve as a
pretty good overview, highlighting pros and cons, and warning about some
of the errors/misconceptions I encountered.

--
kangax

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.

Javascript variables are untyped. Null is a primitive value in
javascript. It is best to think of it this way (reality) rather than
allude to concepts for other languages.

"Certain statements cause a temporary addition to the front of the
"scope chain that is later removed after code execution."

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?

Chapter 5 is about reference types — Object, Array, Date, RegExp, etc.

The terminology "reference types" is incorrect. Those are built-ins. The
Reference type is a specification mechanism.

Another misleading assertion was — "Though ECMA-262 doesn’t indicate a
way to access the Global object directly […]".

Plainly false. In global context:

var global = this;

(and can be used as in the following:

It’s not clear why Mr. Zakas didn’t provide and explain rather
ubiquitous way of accessing Global object from within any context —
(function(){ return this; })();
).

Unfortunately, it starts somewhat badly by making few erroneous
statements about function expressions

Yep.

The FAQ should really have a section on Functions.

when simulating private variables it uses undeclared assignment to
define variable as global one and does so on purpose! This is
especially bizarre,

and

Quite shockingly, an example of document.createElement specifics in IE
is presented with blatant and completely unnecessary browser sniff.

Not following his own advice, is he?

I wish there was more emphasis on the dangers and fragile nature of
browser sniffing in this part of the book.

You already know where Nicholas stands on browser detection, so that
should come as no surprise.
<URL:
http://www.nczonline.net/blog/2009/09/15/iframes-onload-and-documentdomain/#comment-3121

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).

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".

The book is pretty big and I didn't have much time, so the coverage is
not as extensive as it could have been. However, it should serve as a
pretty good overview, highlighting pros and cons, and warning about some
of the errors/misconceptions I encountered.

Your review is already quite long. Looks like "Professional JavaScript"

needs more work. Sometimes, less is more.

"7/10" is either something worth recommending or a C-. I'm not sure.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

kangax wrote:

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

The book is pretty big and I didn't have much time, so the coverage is
not as extensive as it could have been. However, it should serve as a
pretty good overview, highlighting pros and cons, and warning about some
of the errors/misconceptions I encountered.

typo:

localStorage.setItemt('clear', 'foo');

Should be:

localStorage.setItem('clear', 'foo');
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

kangax wrote:

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

The book is pretty big and I didn't have much time, so the coverage is
not as extensive as it could have been. However, it should serve as a
pretty good overview, highlighting pros and cons, and warning about some
of the errors/misconceptions I encountered.

Wrong wording:

I almost fully agree with everyone that’s being said here.

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

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".

I suppose he tried to explain what `null` is from more general perspective.

Javascript variables are untyped. Null is a primitive value in
javascript. It is best to think of it this way (reality) rather than
allude to concepts for other languages.

Agreed. I would avoid use of "pointer" too.

| "Certain statements cause a temporary addition to the front of the
| "scope chain that is later removed after code execution."

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:

"There is a deviation in the Internet Explorer (IE) implementation of
JavaScript, where the error caught in a catch statement is added to the
execution context’s variable object, making it accessible even outside
the catch block."

| Chapter 5 is about reference types — Object, Array, Date, RegExp, etc.

The terminology "reference types" is incorrect. Those are built-ins. The
Reference type is a specification mechanism.

Yep, those are all of Object type of course.

| Another misleading assertion was — "Though ECMA-262 doesn’t indicate a
| way to access the Global object directly […]".

Plainly false. In global context:

var global = this;

True.

(and can be used as in the following:
| It’s not clear why Mr. Zakas didn’t provide and explain rather
| ubiquitous way of accessing Global object from within any context —
| (function(){ return this; })();
).


| Unfortunately, it starts somewhat badly by making few erroneous
| statements about function expressions

Yep.

The FAQ should really have a section on Functions.

Or just a link to NFE article

| when simulating private variables it uses undeclared assignment to
| define variable as global one and does so on purpose! This is
| especially bizarre,

and

| Quite shockingly, an example of document.createElement specifics in IE
| is presented with blatant and completely unnecessary browser sniff.

Not following his own advice, is he?

Yes, it was weird to see that out-of-the-blue sniff.

| I wish there was more emphasis on the dangers and fragile nature of
| browser sniffing in this part of the book.

You already know where Nicholas stands on browser detection, so that
should come as no surprise.
URL:
http://www.nczonline.net/blog/2009/09/15/iframes-onload-and-documentdomain/#comment-3121

Unfortunately, yes.

| 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.

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.

| 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.

The book is pretty big and I didn't have much time, so the coverage is
not as extensive as it could have been. However, it should serve as a
pretty good overview, highlighting pros and cons, and warning about
some of the errors/misconceptions I encountered.

Your review is already quite long. Looks like "Professional JavaScript"
needs more work. Sometimes, less is more.

It does. Its foundation is good, but the book is definitely rough around
the edges and could use some polishing.

More importantly, though, it needs to get away from the mindset of
supporting few modern browsers and, instead, employ a more defensive
approach to cross-browser scripting.

"7/10" is either something worth recommending or a C-. I'm not sure.

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

--
kangax

Garrett Smith wrote:

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

The book is pretty big and I didn't have much time, so the coverage is
not as extensive as it could have been. However, it should serve as a
pretty good overview, highlighting pros and cons, and warning about
some of the errors/misconceptions I encountered.

typo:

localStorage.setItemt('clear', 'foo');

Should be:

localStorage.setItem('clear', 'foo');

Thank you. Fixed.

--
kangax

Garrett Smith wrote:

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

The book is pretty big and I didn't have much time, so the coverage is
not as extensive as it could have been. However, it should serve as a
pretty good overview, highlighting pros and cons, and warning about
some of the errors/misconceptions I encountered.


Wrong wording:
| I almost fully agree with everyone that’s being said here.

s/everyone/everything

Fixed too. Thanks.

--
kangax

Garrett Smith wrote:

Javascript variables are untyped.

That's a wrong statement, you must be thinking of VBScript where
indeed all variables independently on the current value are of the
same Variant type. JavaScript is a *loosely typed* language, that
means that each variable is of some certain type but this type can be
changed to another one at runtime.

Null is a primitive value in javascript.

Another wrong statement: null in JavaScript is an object with the only
property null:
window.alert(typeof null) // 'object'
This way by assigning null to an object reference, we are
dereferencing the said object. If it is the last existing reference
then the relevant scavenger will be marked as garbage collection
available on the next GC check. Not sure what is so alien here in
comparison with other languages.

| Another misleading assertion was — "Though ECMA-262 doesn’t indicate a
| way to access the Global object directly […]".

Plainly false. In global context:

var global = this;

Plainly false: in global context [this] refers to the window host
object, not to Global. Let's do not mix "syntax sugar" added atop in
some engine implementations with the actual mechanics, it might be
dangerous.

VK <schools_ring (AT) yahoo (DOT) com> writes:

Garrett Smith wrote:
Javascript variables are untyped.

That's a wrong statement, you must be thinking of VBScript where
indeed all variables independently on the current value are of the
same Variant type. JavaScript is a *loosely typed* language, that
means that each variable is of some certain type but this type can be
changed to another one at runtime.

Variables can have types in JavaScript 2.0, but not in ECMAScript so
far. Values have types. Variables have a value, but not an inherent
type.

Null is a primitive value in javascript.

Another wrong statement: null in JavaScript is an object with the only
property null:
window.alert(typeof null) // 'object'

No, null is a primitive (i.e., non-object) value.
Notice the specification of the typeof operator needs a special case
for null, because it is not an object (ECMA 262 section 11.4.3).

This way by assigning null to an object reference, we are
dereferencing the said object.

You can't assign a value to a value (object references are values),
and I don't think "dereferencing" means what you think it means.

If it is the last existing reference
then the relevant scavenger will be marked as garbage collection
available on the next GC check. Not sure what is so alien here in
comparison with other languages.

True, if you overwrite a variable holding an object reference with
null, that might make the object eligable for garbage collection, but
the same happens if you assign a number to the variable. Nothing
non-primitive about null in that case.

| Another misleading assertion was — "Though ECMA-262 doesn’t indicate a
| way to access the Global object directly […]".

Plainly false. In global context:

var global = this;

Plainly false: in global context [this] refers to the window host
object, not to Global.

What makes you think they are different?

In a browser setting, the global object and the "this" value is
actually not necessarily the same object, but ECMA-262 says nothing
about browsers.
It does say that the "this" value for code executed in a Global
Context is the global object. If browsers differ, it's because they
are not completely ECMA-262 compliant (with good reason, usually
security related).

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

On Oct 31, 1:17*pm, VK <schools_r... (AT) yahoo (DOT) com> wrote:

Garrett Smith wrote:
Javascript variables are untyped.

That's a wrong statement, you must be thinking of VBScript where
indeed all variables independently on the current value are of the
same Variant type. JavaScript is a *loosely typed* language, that
means that each variable is of some certain type but this type can be
changed to another one at runtime.

I doubt anyone is thinking of VBScript at this juncture. And you
aren't thinking at all (as usual).

Null is a primitive value in javascript.

Another wrong statement: null in JavaScript is an object with the only
property null:

Wrong.

*window.alert(typeof null) // 'object'

That doesn't demonstrate your assertion.

This way by assigning null to an object reference, we are
dereferencing the said object. If it is the last existing reference
then the relevant scavenger will be marked as garbage collection
available on the next GC check. Not sure what is so alien here in
comparison with other languages.

You are the alien here.

| Another misleading assertion was — "Though ECMA-262 doesn’t indicate a
| way to access the Global object directly […]".

Plainly false. In global context:

var global = this;

Plainly false: in global context [this] refers to the window host
object, not to Global.

You can't learn browser scripting by observation and guesswork.

Let's do not mix "syntax sugar" added atop in
some engine implementations with the actual mechanics, it might be
dangerous.

A little bit of knowledge is a dangerous thing.