Slashdot Mirror


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

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.

109 comments

  1. Something's fishy here... by guybrush3pwood · · Score: 0

    If it's "The Definitive Guide", how can there be a 6th edition? I mean, a first edition would suffice if it was truly definitive...

    --
    Perhaps I'm trolling, perhaps I'm not.
    1. Re:Something's fishy here... by Anonymous Coward · · Score: 0

      Cause things change over time?

    2. Re:Something's fishy here... by somersault · · Score: 1

      Because while JavaScript may be generally the same, the libraries available have changed. jQuery is excellent. The DOM has probably changed a bit since 1995 too.

      --
      which is totally what she said
    3. Re:Something's fishy here... by Anonymous Coward · · Score: 0

      by definition Definitive is not change over timer.

    4. Re:Something's fishy here... by RazzleFrog · · Score: 1

      Because it is both authoritative and exhaustive but only at the moment it is written.

    5. Re:Something's fishy here... by Anonymous Coward · · Score: 0

      So, I'll ignore your complete and total failure of an attempt to form a sentence, and direct you towards the the accepted definitions of definitive as an adjective:

      definitive[dih-fin-i-tiv]
      –adjective
      1.most reliable or complete, as of a text, author, criticism, study, or the like: the definitive biography of Andrew Jackson.
      2.serving to define, fix, or specify definitely: to clarify with a definitive statement.
      3.having its fixed and final form; providing a solution or final answer; satisfying all criteria: the definitive treatment for an infection; a definitive answer to a dilemma.

      You seem to be hung up on definition three, which would not change over time. However, definition one obviously could.

    6. Re:Something's fishy here... by _0xd0ad · · Score: 1

      Cut him some slack... his definitive guide to the English language probably hasn't been updated in a while.

    7. Re:Something's fishy here... by elsurexiste · · Score: 1

      Sorry, my english is not good. Who is this man Coward? I see him all time, and always talks to him self.

      --
      I rarely respond to comments. Also, don't ask for clarifications: a brain and Google are faster, believe me!
    8. Re:Something's fishy here... by creat3d · · Score: 1

      Yet, somehow, his point came through...

      --
      Grammar nazis are to this community what excrements are to gold.
    9. Re:Something's fishy here... by nschubach · · Score: 1

      So he's one of those people that updates Wikipedia changing color to colour?

      (sorry!)

      --
      Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
    10. Re:Something's fishy here... by guybrush3pwood · · Score: 1

      Thank you, Mr. Serious Grammar Nazy. No, wait, I think that was me... I'm confused now. :S

      --
      Perhaps I'm trolling, perhaps I'm not.
    11. Re:Something's fishy here... by Anonymous Coward · · Score: 1

      jQuery and the DOM have no place in a book on javascript.

    12. Re:Something's fishy here... by grahamd0 · · Score: 1

      jQuery and the DOM have no place in a book on javascript.

      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.

    13. Re:Something's fishy here... by davidflanagan · · Score: 1

      If it's "The Definitive Guide", how can there be a 6th edition? I mean, a first edition would suffice if it was truly definitive...

      Mod the parent up. This is funny! :-) I wish I could have stopped after the first edition!

    14. Re:Something's fishy here... by JMJimmy · · Score: 1

      My kingdom for a Canadian/British programming languages just for that fact!

    15. Re:Something's fishy here... by Roachie · · Score: 1

      Yea, should it not be the "The Penultimate Guide". Prolly not a good title for moving copies out the door.

      --
      This sig is not paradoxical or ironic.
    16. Re:Something's fishy here... by Paul+Fernhout · · Score: 1

      One of Iain Banks sci-fi Culture Ships called itself "Ultimate Ship The Second". :-)
          http://en.wikipedia.org/wiki/List_of_ships_(The_Culture)

      --
      A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
  2. jQuery? Really? by Anonymous Coward · · Score: 0, Insightful

    In addition to jQuery coverage, does it also cover more mature, feature-rich, and better-architected JavaScript libraries like Dojo Toolkit (http://dojotoolkit.org/) or YUI (http://developer.yahoo.com/yui/), which should be used over the design travesty that is jQuery?

    Also, for server-side JavaScript, which one does it cover?

    1. Re:jQuery? Really? by Anonymous Coward · · Score: 0

      Design travesty? Would anyone care to elaborate on that?
      I've been using it for years and everything I wanted to do was easy and obvious...

    2. Re:jQuery? Really? by MadChicken · · Score: 2

      No.

      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.

      --
      SYS 64738 NO CARRIER
    3. Re:jQuery? Really? by davidflanagan · · Score: 1

      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-side JavaScript. Half covers Rhino and half covers Node. Just enough to give readers a taste of server-side programming. And the reference sections don't include reference material for Rhino or Node.

    4. Re:jQuery? Really? by marsu_k · · Score: 1

      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.

    5. Re:jQuery? Really? by shutdown+-p+now · · Score: 1

      jQuery is a de facto standard in client-side JS development today, whether you like it or not. Any general-purpose book about JS will have to reflect that fact.

  3. Best book on the subject by Yold · · Score: 5, Informative

    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.

    1. Re:Best book on the subject by Hazel+Bergeron · · Score: 0

      Am I the only one depressed by the number of people who think that knowing how to write software means knowing obscure details about specific programming languages? This is the sort of thing I'd care about when I was 15, wanting to demonstrate my smarts via elite knowledge of the internals/intricacies of, well, anything. Then I realised that actually it's all just marketing buzzword bullshit to sell the new unnecessary, bloated toy - either that or it's a theatrical gauntlet run (Perl, I'm looking at you) - and I'd be wasting my time to care about anything but generic principles and research.

      Javascript was an OK client-side scripting language for the web, if you absolutely felt the need to tart up your information without Flash. For everything else, there was and is already something better. As for the web, everything worth using on it works fine with Javascript off.

    2. Re:Best book on the subject by _0xd0ad · · Score: 1

      If it's not your cup of tea, that's fine; personally, his comment made me want to check the library's website and see if they have a recent edition.

    3. Re:Best book on the subject by Anonymous Coward · · Score: 0

      All of the questions he asked are specific questions I had about javascript, having started doing web development in the past year after 15 years of c/c++ systems development, and not understanding why code was written a certain way. It's quite fair to expect a senior developer to understand specifics about the inheritance and type implementations in the languages they're using.

    4. Re:Best book on the subject by Hazel+Bergeron · · Score: 1

      I'd say it's quite odd to define seniority in terms of understanding quirks of particular languages.

      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.

    5. Re:Best book on the subject by digsbo · · Score: 1

      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.

    6. Re:Best book on the subject by MillerHighLife21 · · Score: 2

      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 command line". If you have no interest in an interface, then you're absolutely right.

      And for the record, I detest using javascript unless I have to but you're comment is just plain wrong.

      --
      "Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
    7. Re:Best book on the subject by Anonymous Coward · · Score: 0

      You're absolutely right.
      Unfortunately most visitors of this web site don't want to hear this, because they are about 14 years old in mind.

      About rich applications in web:
      It was a good time, when people where only able to use html forms instead "fancy" javascript widget sets, because they where a common standard and not fucking with the users.

    8. Re:Best book on the subject by Anonymous Coward · · Score: 0

      Sorry, but you sound like an outdated dinosaur. It quantity, not quality, these days. That's why we have so much web stuff, and all of it sucks.

    9. Re:Best book on the subject by Hazel+Bergeron · · Score: 1

      HTML5 vs Flash is just Apple vs Adobe. I don't care for either, although if you are a "web developer" I guess eventually you'll have to get to grips with HTML5.

    10. Re:Best book on the subject by SgtKeeling · · Score: 1

      Mod parent up.

    11. Re:Best book on the subject by Art3x · · Score: 1

      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 Internet Explorer 6 and 7, would cause you to go mad.

      The book takes you step by step, from the basics to advanced, carefully pointing out the pitfalls in Internet Explorer at each step, so you clearly see what works, where, and why.

    12. Re:Best book on the subject by Anonymous Coward · · Score: 0

      Am I the only one depressed by the number of people who think that knowing how to write software means knowing obscure details about specific programming languages?

      Knowing how to write software means knowing (relatively) obscure details about the programming language you are using. If you're writing software using javascript then you'll need to understand how objects work and how scoping works, otherwise you'll probably write bad code and you won't understand why it works the way it does.

      If anything, I find it kinda depressing that you felt the need to ask that.

      Javascript was an OK client-side scripting language for the web, if you absolutely felt the need to tart up your information without Flash. For everything else, there was and is already something better. As for the web, everything worth using on it works fine with Javascript off.

      This was possibly true 10 years ago, but not any more. A lot of sites worth using rely on Javascript to provide the kind of rich interface that HTML alone can't do. That's not to say that all websites need JS, but some – e.g., google maps/mail/docs – do. The web has moved on and it's not just about presenting information statically.

    13. Re:Best book on the subject by Hazel+Bergeron · · Score: 1

      HTML works fine for information. The browser produces the UI according to the user's tastes.

    14. Re:Best book on the subject by Yold · · Score: 1

      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, but it works, barely. It certainly isn't something that is going to last for very long. God forbid you have to use this bridge.

      The engineer is you, and the bridge is the style of coding you are suggesting. These details are not "quirks".

    15. Re:Best book on the subject by Hazel+Bergeron · · Score: 1

      Tension and compression are generic engineering concepts, not at all like knowing the difference between writing "obj.property" and "obj['property']", when "obj = {}".

    16. Re:Best book on the subject by obarel · · Score: 1

      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.

      That's not to say that it's not important to understand how the language works, but knowing how to structure a large piece of software in a way that doesn't crumble under its own cleverness is much more important.

    17. Re:Best book on the subject by Yold · · Score: 2

      An object is a generic, fundamental aspect of JavaScript.

    18. Re:Best book on the subject by Hazel+Bergeron · · Score: 0

      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.

    19. Re:Best book on the subject by davidflanagan · · 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.

    20. Re:Best book on the subject by Anonymous Coward · · Score: 0

      Well dream on dreamers! Html5 is several years away, and always will be. Look at video, ria and games, on all of these html5 doesn't come close to competing with flash.

      Most devs i know aren't interested in going back to the days "this site is best viewed with..."

    21. Re:Best book on the subject by Yold · · Score: 2

      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.

    22. Re:Best book on the subject by Score+Whore · · Score: 1

      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, but your javascript versions are slower as the intrinsic methods are implemented in native code.

      Regardless of principles and your desire to be a researcher, it actually matters that you know all of the features of the language you are tasked to work with so you don't waste time reinventing the wheel poorly.

    23. Re:Best book on the subject by Anonymous Coward · · Score: 0

      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.

      MDC, Quirksmode, Crockford's site, Ajaxian... There are lots of great Javascript resources online. For questions, stackoverflow.

      the absolutely contradictory implementation of it by Internet Explorer 6 and 7

      Who even cares for those ancient nonstandard browsers? Even Microsoft has stopped supporting IE6. For IE6 users most of the current web is broken anyway, and they don't seem to care. IE7 is five years old and has a market share of 7% left, less in Europe. Old IEs are so nonstandard that they're just not worth the hassle. Write ECMAscript, not JScript.

    24. Re:Best book on the subject by Hazel+Bergeron · · Score: 0

      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.

      Also, I can appreciate that Javascript makes you angry, but chill.

    25. Re:Best book on the subject by Hazel+Bergeron · · Score: 1

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

      The difference should be one concise reference and a couple of weeks, or your chosen language is awful.

    26. Re:Best book on the subject by Drooling+Iguana · · Score: 1

      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 Rhino book to get a more complete understanding. Otherwise you'll just be wasting your time.

      --
      ... I'm addicted to placebos
    27. Re:Best book on the subject by Anonymous Coward · · Score: 0

      What is the difference between writing "obj.property" and "obj['property']", when "obj = {}"

      What do you mean by this? I'm fairly sure "obj.property" and "obj['property']" mean exactly the same thing. ECMA-262 5th edition specifically mentions that:
          The dot notation is explained by the following syntactic conversion:
              MemberExpression . IdentifierName
          is identical in its behaviour to
              MemberExpression [ <identifier-name-string> ]
          [...]
          where <identifier-name-string> is a string literal containing the same sequence of characters after processing of Unicode escape sequences as the IdentifierName.

      (see http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf)

    28. Re:Best book on the subject by _0xd0ad · · Score: 0

      The only difference I can think of is that IdentifierName cannot be (or begin with) a numeric literal, whereas <identifier-name-string> is a string and thus it isn't subject to this limitation.

      E.g.
      var obj = {};
      alert(obj.0); //generates a Javascript error
      alert(obj['0']); //returns undefined, no error

    29. Re:Best book on the subject by shutdown+-p+now · · Score: 1

      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.

    30. Re:Best book on the subject by Yold · · Score: 1
    31. Re:Best book on the subject by Yold · · Score: 1

      Prototypal inheritance

      http://en.wikipedia.org/wiki/Prototype-based_programming#Languages [wikipedia.org]

      Q.E.D.

    32. Re:Best book on the subject by eigenstates · · Score: 1

      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.

      --
      quis custodiet ipsos custodes
    33. Re:Best book on the subject by shutdown+-p+now · · Score: 1

      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 possible), where such cleanup is not necessary in the first place.

    34. Re:Best book on the subject by eigenstates · · Score: 1

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

      --
      quis custodiet ipsos custodes
    35. Re:Best book on the subject by shutdown+-p+now · · Score: 2

      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, 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" is a workaround that Mozilla provides, but it's a non-standard extension which only they currently support (albeit slated for inclusion in EcmaScript Harmony).

    36. Re:Best book on the subject by eigenstates · · Score: 1

      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.

      --
      quis custodiet ipsos custodes
    37. Re:Best book on the subject by shutdown+-p+now · · Score: 2

      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 fetch a[a.length].

      Now this by itself is not unexpected on common sense level, because, after all, "i" is declared outside the loop, so it makes sense that it's shared between all iterations (and hence all closures) - it works the same in e.g. C#. But common sense would also dictate that the fix would be:

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

      It works for C#. But in JS, "local_i" has exact same scope as "i", despite appearance to the contrary, and so this doesn't fix anything. The real workaround is to introduce a nested function scope:

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

      In Harmony, you would be able to use the second snippet instead, but replacing "var" with "let".

    38. Re:Best book on the subject by eigenstates · · Score: 1

      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/

      --
      quis custodiet ipsos custodes
    39. Re:Best book on the subject by shutdown+-p+now · · Score: 1

      Absolutely, feel free to share. All my Slashdot posts are under CC0 ~

      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, covering monads from C# perspective (complete with using LINQ as syntactic sugar for them). But it's rather less gentle in introducing the basic concepts. On the other hand, it uses real-world examples of non-IO monads (in particular, it demonstrates how Maybe and lazy sequences are both monads).

    40. Re:Best book on the subject by Maow · · Score: 1

      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/

    41. Re:Best book on the subject by Hazel+Bergeron · · Score: 1

      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.

    42. Re:Best book on the subject by spiralx · · Score: 1

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

    43. Re:Best book on the subject by Anonymous Coward · · Score: 0

      What's not to understand? 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.

      If anything, you should expect foo to complete and therefore i to be out-of-scope (undefined) when the function is executed asynchronously, unless its timeout limit triggers it after doSomethingAsync exits but before foo has completed.

    44. Re:Best book on the subject by Anonymous Coward · · Score: 0

      This debate was held in 1995. Your side lost. Sorry. Time to move on.

    45. Re:Best book on the subject by shutdown+-r+now · · Score: 1

      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 closure extends the lifetime of variables it captures has been the norm since, um, the very first Lisp 50 years ago?

    46. Re:Best book on the subject by Anonymous Coward · · Score: 0

      Offtopic...

      Really?

      A post about Javascript is offtopic in a topic about a book about Javascript.

      Really?

      In what universe?

      Mods on crack?

  4. 1100 Pages by theshowmecanuck · · Score: 0

    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.

    --
    -- I ignore anonymous replies to my comments and postings.
    1. Re:1100 Pages by RazzleFrog · · Score: 2

      The problem is the subset of pages that are useful differs from developer to developer.

    2. Re:1100 Pages by Anonymous Coward · · Score: 0

      You mean like the 'For Dummies' series of titles?

    3. Re:1100 Pages by theshowmecanuck · · Score: 1

      Yeah, I'm sure Kernighan and Ritchie wrote 'for dummies' books. Sorry, maybe they are the only thinner computer books that you are familiar with.

      --
      -- I ignore anonymous replies to my comments and postings.
    4. Re:1100 Pages by Roblimo · · Score: 1

      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.

    5. Re:1100 Pages by genghisjahn · · Score: 2

      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.

      --
      Sorry about the mess.
    6. Re:1100 Pages by MadChicken · · Score: 1

      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.

      --
      SYS 64738 NO CARRIER
    7. Re:1100 Pages by raddan · · Score: 2, Informative

      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 formalization of the design that had already happened, plus a few revisions for fixes and software engineering tricks learned along the way. Javascript has no such canonical implementation, and it definitely suffers from "design-by-committee"-ism, which means that even people involved in its development don't really know what the language's "vision" is.

      My advice is: pick a Javascript library (I like JQuery) and pretend that you're writing in that "language". Trying to deal with browser idiosyncrasies yourself is a very deep rabbit hole. Also-- it helps if you can adopt some code style conventions, especially if you are on a team with varying abilities, because Javascript can turn into a truly horrible mess if you aren't careful.

    8. Re:1100 Pages by guybrush3pwood · · Score: 1

      Read 40 pages a day and you are done in less than a month.

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

      --
      Perhaps I'm trolling, perhaps I'm not.
    9. Re:1100 Pages by TheCycoONE · · Score: 2

      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.

    10. Re:1100 Pages by davidflanagan · · Score: 2

      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 hour or two. Chapter 6, for example, covers objects (including ES5 extensions) comprehensively in 35 pages, and you'd probably come away after reading it feeling like you learned enough to make it worth your time.

    11. Re:1100 Pages by binary+paladin · · Score: 1

      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.

  5. Because JavaScript changed? by oneiros27 · · Score: 1

    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 had to wait for the page to be rendered before you could modify it, etc.)

    Much of that complexity's been dealt with by various JavaScript libraries, but then you have to explain what the ideosyncracies of the libraries are.

    --
    Build it, and they will come^Hplain.
  6. Visual Effects? by jellomizer · · Score: 1

    "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 do all sorts of gui you could make big bucks) Most serious sites kept that type of stuff down.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    1. Re:Visual Effects? by bberens · · Score: 1

      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.

      --
      Check out my lame java blog at www.javachopshop.com
  7. Definitive 6th edition by Henriok · · Score: 2

    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.

    --

    - Henrik

    - when the Shadows descend -
    1. Re:Definitive 6th edition by guybrush3pwood · · Score: 1

      The guys who replied to my first post beg to disagree with both of us, my friend...

      --
      Perhaps I'm trolling, perhaps I'm not.
  8. Comment Subject by Quiet_Desperation · · Score: 1

    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.

    1. Re:Comment Subject by H0p313ss · · Score: 1

      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.

      --
      XML is a known as a key material required to create SMD: Software of Mass Destruction
    2. Re:Comment Subject by Quiet_Desperation · · Score: 1

      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?

  9. Your lawn... by Kozz · · Score: 1

    ...I'm getting off of it.

    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"?)

    How's your buggy-whip business doing?

    --
    I only post comments when someone on the internet is wrong.
  10. jQuery is widely used for client-side Javascript by Webapprentice · · Score: 1

    If you can believe this metric, http://trends.builtwith.com/javascript, 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.

  11. Print is Obsolete by Anonymous Coward · · Score: 0

    Having a massive printed text like this is hardly useful compared to having it searchable and browsable online (or even offline).

    1. Re:Print is Obsolete by davidflanagan · · Score: 2

      O'Reilly offers the book for sale in a variety of DRM-free ebook formats if you prefer to read it that way: http://oreilly.com/catalog/9780596805531/

    2. Re:Print is Obsolete by MadChicken · · Score: 1

      I intend to get the $4.99 e-book upgrade, I think I want this in both formats.

      Regular books are still very useful, they free up a load of screen space and have excellent portability.

      --
      SYS 64738 NO CARRIER
  12. Thank God we have Coffeescript by Anonymous Coward · · Score: 1

    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.

    1. Re:Thank God we have Coffeescript by eigenstates · · Score: 1

      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.

      --
      quis custodiet ipsos custodes
  13. appreciation of powerful language features by Anonymous Coward · · Score: 0

    I agree that many languages and corporations overhype many langauge details as very important features, and that it is near impossible for outsiders to judge their importance.

    But, certain language features are good for specific applications. Several lines of Perl could do in text processing, in what would take over a page of Java code. Text processing is a major use of computers. Web pages are another. While Javascript is not a completely horrible programming language, it is the exclusive programming language for client side web programming, one of the biggest uses of the computer today. The programming language for the prestigious job of client side web programming should be insanely great. Javascript is far from insanely great. Javascript is not worthy of its prestigious position. I hope it will be replaced by something that is.

  14. Gluescript by mpol · · Score: 1

    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/ and it provides GUI programming, server side JavaScript, and maybe other things.
    I just found out its existence today. Just wondering about opinions.

    --

    Well, don't worry about that. We can get you back before you leave. (Dr. Who)
    1. Re:Gluescript by shutdown+-p+now · · Score: 1

      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?

  15. Not an issue by Anonymous Coward · · Score: 0

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

    Doesn't this guy know you shouldn't use tables for layout?

  16. javascript is not worthy of the client side by Anonymous Coward · · Score: 0

    While Javascript is not a completely horrible programming language, it is the exclusive programming language for client side web programming, one of the biggest uses of the computer today. The programming language for the prestigious job of client side web programming should be insanely great. Javascript is far from insanely great. Javascript is not worthy of its prestigious position. I hope it will be replaced by something that is.

  17. Good introduction. by Anonymous Coward · · Score: 0

    I'm reading it right now on my Kindle, it's a fantastic introduction with a lot of code examples to experiment with.

    1. Re:Good introduction. by davidflanagan · · Score: 1

      Thanks!

  18. 6th edition by Anonymous Coward · · Score: 0

    "JavaScript: The Definitive Guide, 6th Edition"

    You keep using the word `definitive.' I do not think it means what you think it means.

    Not after six editions anyway...

  19. David Flanagan by jawahar · · Score: 1

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