Posted
by
Roblimo
on Thursday June 02, 2011 @11:36AM
from the knowledge-tools-for-everyday-life dept.

Michael J. Ross writes "Released during the early days of the Web, in 1995, JavaScript has come a long way: Initially a client-side scripting language typically (mis)used for decorative effects, it is now an essential part of countless major websites. Its increasing capabilities and popularity are due to several factors, including the development of libraries that resolve earlier stumbling blocks that held the language back (such as inconsistencies among the implementations in different vendors' browsers). JavaScript: The Definitive Guide, authored by David Flanagan, was first published just one year later, in 1996, with several significant updates made since then."
Read below for the rest of Michael's review

JavaScript: The Definitive Guide, 6th Edition

author

David Flanagan

pages

1100 pages

publisher

O'Reilly Media

rating

9/10

reviewer

Michael J. Ross

ISBN

978-0596805524

summary

The most comprehensive treatment of JavaScript yet published.

The book is now in its sixth edition, under the ISBN 978-0596805524, and was published on 10 May 2011 by O'Reilly Media (who kindly provided me with a review copy). At 1100 pages, it certainly feels heavier than its advertised 2.6 pounds — but that may only be a side effect of the thought of wading through over a thousand pages of technical explanations and example code. Yet one could argue that the size is justified, considering the amount of information the book conveys, and its obvious aim to be a comprehensive treatment of the language. The material is organized into four parts, including 22 chapters. On the publisher's Web page, visitors will find a brief description, the complete table of contents, a few consumer reviews, reported errata (seven as of this writing, and none confirmed), the example code used in the book, some free content (the first chapter), and links to purchase the print and e-book versions.

The book commences with a multipart introduction, which begins with the sentence "JavaScript is the programming language of the Web." Even though that statement is not true — since there are many other Web programming languages — it does hint at the importance of the language in the mind of the author, and his willingness to put so much effort into creating such a detailed monograph. The introduction is also the first point in the book where one sees the clear demarcation made by the author between core JavaScript (i.e., the language definition, regardless of its runtime environment) and client-side JavaScript (i.e., usage of the language within Web browsers, including the use of libraries). Both areas are covered in great detail in the first two parts of the book, in quasi-tutorial format, while the last two parts cover the same areas, but in a purely reference format.

Specifically, the first part of the book, "Core JavaScript," offers almost a dozen chapters that explicate the basics of the language: its lexical structure; types, values, and variables; expressions and operators; statements; objects; arrays; functions; classes and modules; regular expressions; JavaScript subsets and extensions; and server-side JavaScript. At almost 300 pages, this part alone could form its own volume. The manner in which the author dives into the technical details, and the amount of example code, immediately make it evident that the book is intended for readers who have experience programming, although not necessarily in JavaScript. In fact, some readers — especially newbie programmers — may become frustrated with those places in the narrative where the explanation is not entirely clear. For instance, on page 7, the "points array from above" refers not to any code on that page, but instead refers to an array defined two pages earlier. Fortunately, such stumbling blocks are infrequent. For experienced JavaScript programmers, these chapters could provide a comprehensive review. For readers new to JavaScript, the material may seem overly dry, but the illustrative code should be quite helpful.

The ten chapters that compose the second part of the book, "Client-Side JavaScript," show how to work with the language within a Web browser. This includes learning how to embed JavaScript code in HTML files; differences among browsers and the versions thereof; the security of JavaScript code; the Window object; how to access and manage the elements within the Document Object Model (DOM); scripting CSS styles; events, and methods of handling them; scripting HTTP, and its use in Ajax (reflected in this edition's subtitle, "Activate Your Web Pages"); the jQuery library; techniques for storing data on the user's computer; how to use JavaScript to dynamically create and manipulate graphics, audio, and video content, as well as charts and drawings; and, lastly, the use of several HTML5 APIs. Speaking of that last topic, probably the most significant changes in this edition, versus the previous one, is the coverage of ECMAScript 5, as well as the new objects and methods introduced with HTML5. Naturally, some of these enhancements do not work in any version of Internet Explorer but the most recent, so the author discusses workarounds, if available.

As noted earlier, the third and fourth parts of the book constitute the purely reference material, with the first part focusing on core JavaScript, and the latter on the client-side aspects of the language. Every chapter is organized into a series of entries, each devoted to a particular class or object, ordered alphabetically. For each entry, the reader is given a brief synopsis, description, and in some cases example code and references to other entries. Each class entry also includes information on its properties and methods, where applicable. Each single method entry includes information on its arguments and any return value. The book concludes with what is arguably the longest and possibly most valuable index I have ever seen in a computer book.

There are only a few immediately-evident weaknesses of this book: Firstly, there are some phrases that may be clear to the author, but likely will prove baffling to the typical reader — e.g., "nonlinear cross-reference problem" (page 8) and "the jQuery gives a synopsis of each method" (page 523). Secondly, some of the example HTML code could have been written better, such as the use of an HTML table for defining the layout of a simple form, with labels and fields (page 13). Finally, despite the claims of the marketing copy that this title is suitable as both "an example-driven programmer's guide or a complete desk reference," it would serve better as the latter, and not as a tutorial for learning the language. Clearly, the more comfortable one feels with computer programming — especially JavaScript itself — the more that one could get out of this book.

On the other hand, there are far more pluses than minuses. One of the real strengths of the book is how the author does not hesitate to use (sometimes lengthy) blocks of code, with explanatory comments for almost every line, to clarify the language — as opposed to paragraphs of text, which could have easily doubled the length of the first two parts (which comprise roughly the first two thirds of the book). Also, in conjunction with the narrative and code fragments, the author makes effective use of figures whenever needed — particularly in Chapter 21, in demonstrating how to work with graphics and multimedia content.

Evolving with the language itself, and again brought up to date, JavaScript: The Definitive Guide still retains its crown as the ultimate reference resource for JavaScript programmers.

jQuery? No, certainly not. DOM? Of course it has a place. The vast majority of people using javascript are doing DOM manipulation of some sort, and it would be a gross oversight not to include at least an explanation of it, if not a comprehensive reference.

You have to deal with not just ECMA Script changing, but also the different implementations of it (JavaScript, JScipt, ActionScript, etc.) and then there's the issue of how it behaves in HTML3 vs. HTML4 vs. XHTML vs. HTML5.

I've got an older version, but there were a lot of useful sections about the dfferent implementations in each browser, and how to deal with something as simple as getting a script to fire before the user does stuff. (as Netscape and IE handled things differently, and for some things, you

But if you need a reference, you should have one that includes jQuery, given how widespread it is, don't you think? There are only 43 pages that cover jQuery directly, so it's only a quick intro anyway.

If you can believe this metric, http://trends.builtwith.com/javascript [builtwith.com], jQuery is used in over 40% of the top websites. It has a strong developer community and is well-documented for the most part.

The book does not devote too many pages on jQuery, but it makes a few mentions.

Dojo and YUI are too big to cover in one chapter. I mention them, but do not cover them.
jQuery is small enough to cover comprehensively in this book. And it is probably more popular than the larger alternatives, so I covered it. Many readers will find that chapter quite helpful. Those who don't want to use jQuery can skip the chapter. I don't use jQuery elsewhere in the book. (The jQuery material is also available in standalone form as jQuery Pocket Reference.)
There is just one chapter on server-si

Somewhat offtopic, but kudos for the book (although I've only read the 5th edition, but I suppose the fundamentals are the same). Javascript is very much a misunderstood language, and material on it seems mostly to be either incomplete, outdated or downright wrong, especially on the web but in book form also. Your book is the only one I personally reccommend.

It's sad how few web programmers have read this text. Don't be intimidated by its size, most of it is simply reference material, and not part of the tutorial chapters. If you read this book cover-to-cover (well, except for the hefty reference pages), you will be a JavaScript expert.

If you are a web programmer, and you can't answer any of the following questions, consider reading this book.

1.) What does the "new" keyword actually DO in javascript (hint: if you don't say about.prototype you are wrong).

2.) How would you implement a hash in Javascript? Related questions, how are Arrays and Objects different and similar? What is the shorthand notation for them? What does hasOwnProperty do? What is the difference between writing "obj.property" and "obj['property']", when "obj = {}" ?

3.) Explain how scope works in Javascript. How does this relate to closures?

Imagine a mathematics PhD programme which examines you on Mathematica pattern matching. Or an undergrad entrance test which measures your proficiency with a TI-89. It's stuff anyone could learn by just reading a sufficiently detailed reference, but demonstration of the knowledge determines almost nothing else.

To correct your weak analogy, imagine an Engineer is building a bridge, and he doesn't understand tension and compression. "Bah", he says "It's stuff anyone could learn by just reading a sufficiently detailed reference". "Fuck it", he says, "I'll just use a bunch of solid rocks!". So he goes and piles together rocks to make a bridge. It takes him 5 times longer to build the rock bridge (instead of a suspension bridge), and he suffers many failures along the way. In the end the bridge is pretty shitty,

Are you really that incapable of understanding the difference between the concrete and the abstract? In what way is understanding some peculiar syntax quirk of Javascript the same as understanding what an object is?

My question is rhetorical, as I'm well aware of this problem with today's programmer.

BECAUSE JAVASCRIPT OBJECTS ARE PECULIAR. The difference between those two syntaxes is VITAL to understanding WHY they are peculiar. JavaScript's objects don't function like objects in other languages, especially at the conceptual (abstract) level.

It's VITAL to understanding a PECULIAR quirk of Javascript? Explain carefully what's so magically special and conceptually unique about Javascript objects in your opinion. I'll be happy to disabuse you of your misconceptions.

What is wrong with you? There are dozens of language which implement objects via prototypes, many of which are older than Javascript (and probably older than you) - you've even provided a (Wikipedia.. eugh) link to support this. Understanding the syntax above doesn't mean you understand prototypes; understanding prototypes doesn't mean you understand the syntax above. But going from the general understanding to the specific is a matter of seconds.

My Greek teacher used to say: "with a dictionary and a grammar book you can translate anything. Knowing a language means you have to learn by heart nouns and verbs, there's no other way."

However, I have to say that knowing obscure details about programming languages is not the same as using them. Readable, maintainable and straight-forward code that can be understood and changed even under pressure is more valuable than an "optimisation" hack that uses some clever and surprising trick of the language.

Now that I've logged in, I would like to add to my previous post. If you are paying attention to what the current trends are, Flash is dying quickly, and javascript/HTML5 is coming on strong. If you're doing web stuff, and you don't know this, you should reconsider what you're putting your time into learning.

I suppose that depends on your definition of what's worth using. If you're looking at the web as nothing more than submit form, browse table, load from database...yea, no javascript is fine.

If you want anything with a decent user interface that will work on multiple devices and not require people to visit 20 different pages to do something that could be simple...well, then you need javascript.

Saying everything works fine with javascript off is right up there with saying "we might as well all just use the c

Seriously, you may have noticed that this is a book review targeted towards Javascript developers. The GP was discussing that topic to stimulate thought and conversation amongst like-minded individuals. Is that what you call "demonstrating smarts via elite knowledge"? Perhaps you're reacting negatively because you don't have adequate familiarity with the language. (Honestly, "tart up"?)

It's one thing to be able to say "I know the general principles of programming." It's something quite different to say "I am a C/Java/Javascript/Perl developer." Consider the situation where someone who is quite advanced in the the principles of programming, understands algorithms, etc. and they are writing up some javascript and they proceed to implement their own array manipulation methods ignoring that sort, slice, split, concat, etc. are all there for the taking. You've not only wasted a bunch of time,

If you read this book cover-to-cover (well, except for the hefty reference pages), you will be a JavaScript expert.

Thanks! That was my goal when writing it. It is about language mastery. Not so that you can answer quizzes about obscure corner cases, but so that you can program more effectively. Its like adding tools to your toolbox, and keeping them sharp.

In truth, there's a lot of stuff that looks like it's going to be fixed in Harmony - including both bits mentioned above. Which goes to show that most people actually agree that those are problems. But until sanity prevails, I'll stick to other languages (insofar as pos

Crazy rules for var? Like every child object of the object in which var is declared has access to that variable? Doesn't sound like too much mayhem if you use closure. And for scoped code like interfaces I quite like the 'require' pattern. var Foo = require(foo.js); Where foo.js: require.exports = {random assortment of scoped objects}I don't see these as cleanup problems, just ability to write clean code to begin with.

Although I am not sure I am getting to the root of your issue. The problem isn't really cl

Crazy rules for var? Like every child object of the object in which var is declared has access to that variable?

No, the fact that it's always function-scoped rather than block-scoped [docstore.mik.ua], while the syntax still permits you to write it inside a block. This breaks the established rule for all C-family languages out there - in every other case, either in-block declarations are scoped to the block (C99, C++, C#, Java, D,...), or else you can only declare variables at the outermost block in function body (classic C).

Ahh gotcha. Have never actually run in to that being a problem. I guess that's from know that is one of the quirks is helpful and allows me to code with that in mind. Now, I am just beginning work on a pure JS application. Perhaps it will come up there. Lots of fingers in this pie.

This is probably the clearest explanation I have seen of this problem in ever. Yes, in ever. It makes it look just as nice as it can which is ugly as hell. If I may hang on to it to share?

Also, I was looking around the other day for 'promise' type stuff in JS and found this:http://blog.jcoglan.com/2011/03/05/translation-from-haskell-to-javascript-of-selected-portions-of-the-best-introduction-to-monads-ive-ever-read/

And yes, it's a very good explanation of monads. The usual problem these days is that people come to know about them through Haskell, and the first place where they see them in Haskell is the IO monad, and so the association becomes very strong on unconscious level, and hard to untangle (which is absolutely necessary to really understand what they do). This tutorial does a very good job at that.

Declaring a function in Javascript doesn't magically bring all the variables referred to within it into a local function scope at the time the function is defined.

I'm sorry, but I have no idea what this means. The issue here is why the scope of variable "local_i" - which syntactically belongs to the body of the for-loop - is not the body of that loop, but rather the entire function "foo". This has absolutely nothing to do with a closure inside that body, except for the fact that it is a convenient real-world scenario where this matters in a very noticeable way.

If anything, you should expect foo to complete and therefore i to be out-of-scope (undefined) when the function is executed asynchronously

I wouldn't expect this from any high-level programming language (i.e. not C++) which has closures. That a cl

Can someone write a computer book that doesn't either require weight training in order to hold the book (stuff your kindle up your ass I hate them), or six years to read? Most of the time the amount of useful information in these books only constitutes a small subset of the pages. Do these people think quantity makes quality? These authors should take a lesson from Kernighan and Ritchie.

Publishers love those books because they're more visible on retail shelves than thinner ones. I fought the "let's keep it brief, do no padding" battle with publishers a couple of times, and lost. Publishing is a crazy business, busily committing suicide as we speak.

At 20 pags a day you could read this cover to cover in less than two months. Weigh that against having the knoweledge in your head for much longer. You won't remember everything, of course, but you will know a lot more about javascript than you did before. Read 40 pages a day and you are done in less than a month.

Based on the 5th edition, which I read a few years ago - about half the book is a 'reference' which makes for pretty dull and unproductive reading easily replaced by web sites like w3schools and quirksmode. Part 1 on core JavaScript on the other hand is well worth the reading and greatly enhanced my understanding of the language. I would recommend the book just based on that part.

The size of the book (I have the last edition) really is an indication of the fragmentation in Javascript implementations. In the edition I have, the authors spend an inordinate amount of time enumerating compatibility issues from one web browser to another. The K&R C book deals only with the core language and standard library, and it had the advantage at the time of having been written by the language designers/compiler writers themselves on the canonical platform (UNIX). ANSI C really was just a fo

My Ruby book is explicitly modelled after K&R. The JavaScript book is also, though not quite so obviously. If you just look at the first 300 pages, the comparison would be more apt. Try to imagine K&R expanded to cover all of the major libraries that C developers have to use today. That would come out at over 1100 pages, too.

After you get through the first 5 chapters, you can kind of pick and choose what to read. Most chapters are 30-50 pages, and you should be able to work through them in an ho

I really do not understand the point of huge library references in books anymore, particularly if the language is a VERY web centric language. Who in the hell is programming JS without an internet connection? I mean really, does ANYONE use a book for reference like that anymore?

The Ruby book you reference, I presume is "The Ruby Programming Language" and yeah, it's very good.

I remember using it back in the old days for client side input validations. As in the Pre-Ajax days if you were to submit a form and then get the page back with errors over a 14.4k modem took a while. Having Javascript as the first line of defense really help speed things up.

The visual effects were used as mostly toys to show off your skills as a web developer (back in the 90's if you were a good web developer that can d

I like the fact that the definitive guide is in its 6th edition.
It's just like the Windows Ultimate Edition.. it won't need any updates or upgrades. Ever again.
Or the movie Final Destination.. which got four sequels. Awesome.

15 years ago most of the javascript was useless and mostly pointless, now it is an essential ingredient of the medium. There was a sea-change in 2000, 2001. Those of you who are too young or too ignorant to remember those heady days before AJAX should keep your mouths shut.

Javascript is verbose, has annoying quirks and an ugly c-like syntax that hides the underlying elegance of its functional capabilities and object model.But now we have Coffeescript, a source to source "transpiler" offering a beautiful, pleasant to write and read syntax inspired in Python and Ruby.The more I play with it, the more I love it.

Dunno if I would have worded it quite that way. Probably would have left out the fucks. I probably would have gone on to say that both Ruby and Python syntax are absurd to look at and decipher if you are blessed with the gift of understanding C-like syntax. The notion that white space is syntactically crucial is ridiculous.

Nah, the Ruby/Python quirks are as numerous and odd as JS so it appears that the thesis of the parent's statement is mostly invalid.

All you mostly read about JavaScript is in the browser. There are however project that take JavaScript beyond the browser.Are there any people who have experience with a project like Gluescript? It's on http://gluescript.sourceforge.net/ [sourceforge.net] and it provides GUI programming, server side JavaScript, and maybe other things.I just found out its existence today. Just wondering about opinions.

The reason why JavaScript is used inside the browser is because you don't really get a choice - it's the only scripting language universally supported by all browsers.

Outside the browser, we - thankfully! - have much better designed languages, such as Python, Ruby, Lua etc - which offer all features of JS (and then some), but without all the annoying quirks. So why bother?