Eloquent JavaScript Book

[Brian Adkins]

Is anyone familiar with the following online JavaScript "book" ?

http://eloquentjavascript.net/index.html

If so, would you recommend it?

 

[Martin Rinehart]

Is anyone familiar with the following online JavaScript "book" ?

http://eloquentjavascript.net/index.html

If so, would you recommend it?

I took a quick look. Looks very good.

 

[SAM]

Le 12/7/08 7:10 PM, Brian Adkins a écrit :

Is anyone familiar with the following online JavaScript "book" ?

No.
It seems very good and useful (with its console !)
With what that was coded ?
(with all this examples whom syntax is colorized)

http://eloquentjavascript.net/index.html

Colors that aren't black are to much clear for me.

I begin with chap.13

Accessoirement : ce n'est pas en Français

 

[Kenny]

Is anyone familiar with the following online JavaScript "book" ?

http://eloquentjavascript.net/index.html

If so, would you recommend it?

"it might become necessary for our rabbits to dance"

Highly recommended.

hth,kxo

 

[David Mark]

Is anyone familiar with the following online JavaScript "book" ?

http://eloquentjavascript.net/index.html

If so, would you recommend it?

Is anyone familiar with the following online JavaScript "book" ?

http://eloquentjavascript.net/index.html

If so, would you recommend it?

No.

An excerpt:

On Internet Explorer, setAttribute and getAttribute also work with
these adjusted names, instead of the original HTML names, which can be
confusing. On top of that the style attribute, which, along with
class, will be discussed later in this chapter, can not be set with
setAttribute on that browser.

A workaround would look something like this:

function setNodeAttribute(node, attribute, value) {
if (attribute == "class")
node.className = value;
else if (attribute == "checked")
node.defaultChecked = value;
else if (attribute == "for")
node.htmlFor = value;
else if (attribute == "style")
node.style.cssText = value;
else
node.setAttribute(attribute, value);
}

No it wouldn't. And this function forms the basis of other DOM
examples.

setNodeAttribute($("picture"), "style",
"border-width: 4px; border-style: solid;");

Yes, it recommends shortening gEBI to "$" to avoid crippling ones
fingers.

 

[RobG]

Is anyone familiar with the following online JavaScript "book" ?

http://eloquentjavascript.net/index.html

If so, would you recommend it?

Like many similar books, it has some good stuff but has not been
thoroughly reviewed and edited. For example, in Chapter 2 there is:

"The keyword function is always used when creating a new function.
When it is followed by a variable name, the resulting function will be
stored under this name"

Stored where? If a function statement has an optional name, the name
is avilable in different contexts in different browsers. The
intention may be to keep things simple, but the author should have
introduced function declarations, statements and expressions before
going further.

In Chapter 6, there is:

"Here we are defining new functions without using the function keyword
at all."

Doesn't that contradict the statement from Chapter 2? Is defining a
function different to creating one? Had the author introduced the
notions of function declarations, satements and expressions, they
could have been used elsewhere, instead unspecified terms like
"define" and "create" are used.

So no, I wouldn't recommend it, however it is a good start.

 

[dhtml]

Like many similar books, it has some good stuff but has not been
thoroughly reviewed and edited. For example, in Chapter 2 there is:

That's chapter 3.

http://eloquentjavascript.net/chapter3.html

"The keyword function is always used when creating a new function.
When it is followed by a variable name, the resulting function will be
stored under this name"

Stored where? If a function statement has an optional name, the name
is avilable in different contexts in different browsers. The
intention may be to keep things simple, but the author should have
introduced function declarations, statements and expressions before
going further.

A function statement is a JavaScript(TM) extension. This has been
discussed to death here.

To do discussion of Function justice, it would be necessary to first
differentiate Function Definition, FunctionDeclaration,
FunctionExpression, and FunctionStatement. The author does not seem to
have a clear understanding and distinction between these.

So no, I wouldn't recommend it, however it is a good start.

It is a online where it can be critiqued and then edited (Book errata is
not as effective). It seems fairly well organized. There are
click-and-run examples.

 

[Bruno Desthuilliers]

SAM a écrit :

Le 12/7/08 7:10 PM, Brian Adkins a écrit :

No.
It seems very good and useful (with its console !)
With what that was coded ?
(with all this examples whom syntax is colorized)


Colors that aren't black are to much clear for me.

I begin with chap.13

Accessoirement : ce n'est pas en Français

<OT>
Et accessoirement, c'est normal vu qu'on est sur comp.lang.javascript !-)
</OT>

 

[Thomas 'PointedEars' Lahn]

Is anyone familiar with the following online JavaScript "book" ?

http://eloquentjavascript.net/index.html

If so, would you recommend it?

Like many similar books, it has some good stuff but has not been
thoroughly reviewed and edited. For example, in Chapter 2 there is:

"The keyword function is always used when creating a new function. [...]

Which is wrong to begin with, considering the Function() constructor and
factory.


PointedEars

 

[SAM]

Le 12/8/08 8:12 AM, dhtml a écrit :

RobG wrote:

To do discussion of Function justice, it would be necessary to first
differentiate Function Definition, FunctionDeclaration,
FunctionExpression, and FunctionStatement.

Web sources about all that ?
Thank you.

 

[RobG]

That's chapter 3.
Doh.




A function statement is a JavaScript(TM) extension. This has been
discussed to death here.

This is "comp.lang.javascript", the book is titled "Eloquent
JavaScript".
What's your point?

To do discussion of Function justice, it would be necessary to first
differentiate Function Definition, FunctionDeclaration,
FunctionExpression, and FunctionStatement.

Yes, seems you agree.

The author does not seem to
have a clear understanding and distinction between these.

Maybe, maybe not. It certainly isn't made clear in the text.

It is a online where it can be critiqued and then edited (Book errata is
not as effective).

I don't see anywhere at the link provided that the book can be
critiqued or edited. It should have been reviewed before being
published, there is no evidence that it was.

 

[SAM]

Le 12/8/08 1:38 PM, RobG a écrit :

I don't see anywhere at the link provided that the book can be
critiqued or edited. It should have been reviewed before being

"written March to July 2007,"

published, there is no evidence that it was.

"last modified on February 9th 2008."

and you have a link to mail to the author.

 

[Erwin Moller]

Brian Adkins schreef:

Is anyone familiar with the following online JavaScript "book" ?

http://eloquentjavascript.net/index.html

If so, would you recommend it?

Hi,

I skipped through a few chapters, and my first impression is that this
is a great startingpoint for newbies.
In the early chapters Marijn Haverbeke clearly puts some effort into
explaining concepts as bit/byte representation for number. I think that
is very good for starters.
He also has some educational talents because he build up his chapters in
a coherent way: bottom->up. I like that style.

One thing I am not impressed with is his codingstyle.
He ommits {}, like here in the for loop:

function power(base, exponent) {
var result = 1;
for (var count = 0; count < exponent; count++)
result *= base;
return result;
}

But I noticed more people leave the brackets out in their code, so this
might just be a very private irritation.

I'll surely look through it when I find more time.
(My DOM manipulation is in need of some polishing, so I'll check chapter
12 for sure.)

Thanks for the link!

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[beegee]

Brian Adkins schreef:


Hi,

I skipped through a few chapters, and my first impression is that this
is a great startingpoint for newbies.

I agree. It has a fun writing style that would keep me going through
the sometimes 'reference-like' subject matter. Not as fun as 'Why's
Poignant Guide to Ruby' but in the same vein.

I personally can't stand syntactic shortcuts like '$' in javascript so
I would not actually recommend this book to a newcomer. The last
thing the javascript community needs is thousands of people
obfuscating the language or the language's treatment of the DOM.
JQuery is bad enough.

I did like this though: "The most important thing to know about
regular expressions is that they exist, and can greatly enhance the
power of your string-mangling code. They are so cryptic that you'll
probably have to look up the details on them the first ten times you
want to make use of them."

Make that the first 1000 times.

Bob

 

[Kenny]

Brian Adkins schreef:



Hi,

I skipped through a few chapters, and my first impression is that this
is a great startingpoint for newbies.
In the early chapters Marijn Haverbeke clearly puts some effort into
explaining concepts as bit/byte representation for number. I think that
is very good for starters.
He also has some educational talents because he build up his chapters in
a coherent way: bottom->up. I like that style.

One thing I am not impressed with is his codingstyle.
He ommits {}, like here in the for loop:

function power(base, exponent) {
var result = 1;
for (var count = 0; count < exponent; count++)
result *= base;
return result;
}

But I noticed more people leave the brackets out in their code, so this
might just be a very private irritation.

I am coding single-liners without the braces. This crosses a line for me
when it comes to "noise":

for (var count = 0; count < exponent; count++) {
result *= base;
}

The absence of the braces really stands out, so there is little chance
I'll miss adding them when I extend a block esp. since automatic
indentation will likely back me up. Lispers live and breathe by
automatic indentation. Even if I were to miss, this is not COBOL in the
60s with sixty minute compiles and weak debugging: such a bug would not
take long to track down.

just my2.

kt

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>
, Mon, 8 Dec 2008 15:10:34, Erwin Moller <Since_humans_read_this_I_am_sp
(e-mail address removed)> posted:

function power(base, exponent) {
var result = 1;
for (var count = 0; count < exponent; count++)
result *= base;
return result;
}

I hope he includes the more efficient, and perhaps more accurate,
algorithm, which works by squaring and conditionally adding (and can be
shown both recursively and iteratively).

 

[RobG]

Le 12/8/08 1:38 PM, RobG a écrit :


"written March to July 2007,"


"last modified on February 9th 2008."

The fact that the page has been modified since it was first published
doesn't mean it's been reviewed or even significantly altered.

and you have a link to mail to the author.

Where is the link to the comments and reviews that have already been
received? If I submit a review or comment, where is the commitment to
make it public or respond to it?

A review of a technical article infers a critique by one or more
independent authorities on its subject. Specific criticisms should be
addressed either by modifying the text or explaining why the author's
opinion differs from that of the reviewer or reviewers.

Providing a contact e-mail address hasn't fixed the many errors of
fact in the document. It is clearly a less than optimal alternative
to a formal review if the article has been on the web for 10 months
and still contains basic errors. For example, the section on HTML
refers to tags when it should refer to elements, and:

"...the [DOM] tree contains two types of elements: Tags ... and pieces
of simple text. The pieces of text, as we will see, work somewhat
different than the other elements."

If the author had explained the DOM as consisting of nodes, then it
would have been easier to explain the above using the different node
types. At the same time, the reader would have been introduced to
correct terminology and concepts without being told a text node is an
element. Further, the DOM provides an interface to determine the
NodeType so readers are a lot better off to have learned about nodes
and node types from the start, not "tags" or "text elements".

It is also extremely important that beginners are taught appropriate
terminology from the very beginning so that when they ask questions,
they make some kind of sense to persons other than those familiar with
the source of their learning.

 

[Kenny]

In comp.lang.javascript message <[email protected]>
, Mon, 8 Dec 2008 15:10:34, Erwin Moller <Since_humans_read_this_I_am_sp
(e-mail address removed)> posted:




I hope he includes the more efficient, and perhaps more accurate,
algorithm, which works by squaring and conditionally adding (and can be
shown both recursively and iteratively).

That would we in his other book, Eloquent Algorithms.

kt

 

[Kenny]

Le 12/8/08 1:38 PM, RobG a écrit :



"written March to July 2007,"



"last modified on February 9th 2008."

The fact that the page has been modified since it was first published
doesn't mean it's been reviewed or even significantly altered.

and you have a link to mail to the author.

Where is the link to the comments and reviews that have already been
received? If I submit a review or comment, where is the commitment to
make it public or respond to it?

A review of a technical article infers a critique by one or more
independent authorities on its subject. Specific criticisms should be
addressed either by modifying the text or explaining why the author's
opinion differs from that of the reviewer or reviewers.

Providing a contact e-mail address hasn't fixed the many errors of
fact in the document. It is clearly a less than optimal alternative
to a formal review if the article has been on the web for 10 months
and still contains basic errors. For example, the section on HTML
refers to tags when it should refer to elements, and:

"...the [DOM] tree contains two types of elements: Tags ... and pieces
of simple text. The pieces of text, as we will see, work somewhat
different than the other elements."

If the author had explained the DOM as consisting of nodes, then it
would have been easier to explain the above using the different node
types. At the same time, the reader would have been introduced to
correct terminology and concepts without being told a text node is an
element. Further, the DOM provides an interface to determine the
NodeType so readers are a lot better off to have learned about nodes
and node types from the start, not "tags" or "text elements".

It is also extremely important that beginners are taught appropriate
terminology from the very beginning so that when they ask questions,
they make some kind of sense to persons other than those familiar with
the source of their learning.

Maybe the author is stronger on Javascript (and writing and teaching)
than DOM.

kt

 

[Marijn]

Ah, Usenet, where neurotic nit-picking is the accepted form of
communication.

The date on the index page was inaccurate -- the other pages are
automatically generated, and had a date somewhere in October.

The fact that the page has been modified since it was first published
doesn't mean it's been reviewed or even significantly altered.

A lot of readers have sent me feedback and reported mistakes -- either
by mail or through the widget provided specifically for this purpose
on every single page of the tutorial (the face in the top-left
corner). The text has been update innumerable times. Sometimes even
the comments stealthily posted to Usenet groups reach me, thanks to
the magic of Google Alerts.

Where is the link to the comments and reviews that have already been
received?  If I submit a review or comment, where is the commitment to
make it public or respond to it?

There isn't. I tend to respond to every polite or useful comment. But
I'm not being paid for this, so there is no commitment.

"...the [DOM] tree contains two types of elements: Tags ... and pieces
of simple text. The pieces of text, as we will see, work somewhat
different than the other elements."

If the author had explained the DOM as consisting of nodes, then it
would have been easier to explain the above using the different node
types.

This is a good point. I've changed some sentences to not abuse the
term 'tag' when I mean 'node' or 'element'.

Cheers,
Marijn

(Hey Kenny.. fancy finding you here. Thanks for the moral support!)