Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Image

Book Review -- JavaScript: the Definitive Guide, 6th Edition 109

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.

Michael J. Ross is a freelance website developer and writer.

You can purchase JavaScript: The Definitive Guide, 6th Edition from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

*

This discussion has been archived. No new comments can be posted.

Book Review -- JavaScript: the Definitive Guide, 6th Edition

Comments Filter:
  • by Yold ( 473518 ) on Thursday June 02, 2011 @11:05AM (#36321328)

    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?

    Javascript gets a bad repuatation mostly because it is misunderstood.

    • by Art3x ( 973401 )

      Don't be intimidated by its size, most of it is simply reference material

      Yes, the book could be four:
      1. language walk-through
      2. browser API walk-through
      3. language reference
      4. browser API reference

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

      Yes, I read the last edition, after finding nothing online but ad-packed sites tossing around code snippets to copy and paste. There's nothing like what's for Python or even PHP online.

      Javascript gets a bad reputation mostly because it is misunderstood.

      Yes, I don't know how anyone comes to understand JavaScript by just reading online. The scarcity of good online documentation, combined with the absolutely contradictory implementation of it by Inter

    • Re: (Score:3, Informative)

      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.

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

      I read a previous edition of this book cover-to-cover a few years ago and came out knowing almost nothing about Javascript. The problem was that I went in knowing absolutely nothing about Javascript.

      The Rhino book is a reference, not a guide/tutorial. It's not there to guide you through writing your first Javascript script. Learn the basics of the language from another source, then read the Rhi

    • Javascript gets a bad repuatation mostly because it is misunderstood.

      Yes - if it were fully understood, it'd have horrible reputation. The scoping rules for "this" alone are a travesty worth a dozen dead kilokittens.

      • Here's an idea- don't be a lazy good-for-nothing and use 'this'. Try working with var self = this. You'll find your headache magically disappears because scope is clear.

        And I'll betcha a fin that little piece of advice is in the book. It's in Javascript: The Good Parts.
        • Cool; now what's the work around for the crazy insane scoping rules for "var"? Defining and immediately calling an anonymous function? That's one ugly and verbose hack.

          (and don't tell me it's "let", cuz only Mozilla understands that so far).

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

              Using "let" instead of "var" [mozilla.org] is a workaround that Mozilla provides, but it's a non-standard extension which on

              • 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.
                • The gotcha mainly comes when you're trying to prep a closure and stash it away for later (e.g. async callback) while inside the loop. You start with something like:

                  a = [...];

                  function foo() {
                  var i;
                  for (i = 0; i < a.length; ++i) {
                  doSomethingAsync(i, function(result) { a[i].finish(result); });
                  }
                  }

                  This doesn't work because all closures capture the same "i" scoped to "foo", which mutates within the loop. So by the time callbacks are invoked, they're all going to

                  • 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/
                    • Absolutely, feel free to share. All my Slashdot posts are under CC0 [creativecommons.org] ~

                      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.

                      One other I know of is this [msdn.com], covering monads

                    • by spiralx ( 97066 ) *

                      Cheers for the link, that was much easier to understand than anything else I've read on monads.

    • by Maow ( 620678 )

      You've made an extremely cogent case for reading this book.

      Thank you, and congratulations to David Flanagan (the book's author, who himself posts a reply to your comment) for his work.

      I wish him much success...

      Now I'm off to go look up the answers to the questions you've posed while I'm still motivated by the shame of not having a clue.

      Maybe you could post the answers in reply to your post: someone will likely benefit from it.
      --
      Salon Kill File: Better letter reading on Salon.com.
      http://salon.maow.net/ [maow.net]

  • 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.
    • The problem is the subset of pages that are useful differs from developer to developer.

    • by Roblimo ( 357 )

      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.
      • Read 40 pages a day and you are done in less than a month.

        Or... I could play Angry Birds for an hour, instead!

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

    • Hint: if the book says "Definitive" in it's title, it's probably going to be big.

      You're probably either looking for "Javascript: The Good Parts" or a moderate weight-training program.

    • Re: (Score:3, Informative)

      by raddan ( 519638 ) *
      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.

  • "Initially a client-side scripting language typically (mis)used for decorative effects"

    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

    • by bberens ( 965711 )
      If you are an *expert* in Javascript you can still make big bucks. You generally will have to be willing to move to California or New York though.
  • by Henriok ( 6762 ) on Thursday June 02, 2011 @11:37AM (#36321714)
    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.
  • typically (mis)used

    Oh, stuff it. Some day you purists will learn that the street finds its own uses for things, and that it's OK to do so.

    • Way to quote out of context

      Initially a client-side scripting language typically (mis)used for decorative effects,

      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.

      And stay off my lawn.

      • Those of you who are too young or too ignorant to remember those heady days before AJAX should keep your mouths shut.

        Please... I first used this thing when some of my professors at the time were still calling it ARPANet. Had to go to the computer lab in college because even public dialup was still years away.

        And stay off my lawn.

        Hey! I *am* the lawn.

        Wait... what?

  • by Anonymous Coward

    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.

  • 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?

  • I know David Flanagan when he was in Divine Inc.
    Brilliant guy.

Help fight continental drift.

Working...