Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Roblimo posted more than 3 years ago | from the knowledge-tools-for-everyday-life dept.

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

cancel ×

109 comments

Sorry! There are no comments related to the filter you selected.

Something's fishy here... (0)

guybrush3pwood (1579937) | more than 3 years ago | (#36321006)

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

Re:Something's fishy here... (0)

Anonymous Coward | more than 3 years ago | (#36321084)

Cause things change over time?

Re:Something's fishy here... (0)

Anonymous Coward | more than 3 years ago | (#36321182)

by definition Definitive is not change over timer.

Re:Something's fishy here... (0)

Anonymous Coward | more than 3 years ago | (#36321230)

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.

Re:Something's fishy here... (1)

_0xd0ad (1974778) | more than 3 years ago | (#36321282)

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

Re:Something's fishy here... (1)

nschubach (922175) | more than 3 years ago | (#36321544)

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

(sorry!)

Re:Something's fishy here... (1)

JMJimmy (2036122) | more than 3 years ago | (#36323484)

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

Re:Something's fishy here... (1)

elsurexiste (1758620) | more than 3 years ago | (#36321308)

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

Re:Something's fishy here... (1)

creat3d (1489345) | more than 3 years ago | (#36321500)

Yet, somehow, his point came through...

Re:Something's fishy here... (1)

guybrush3pwood (1579937) | more than 3 years ago | (#36321828)

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

Re:Something's fishy here... (1)

somersault (912633) | more than 3 years ago | (#36321174)

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.

Re:Something's fishy here... (1)

Anonymous Coward | more than 3 years ago | (#36322006)

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

Re:Something's fishy here... (1)

grahamd0 (1129971) | more than 3 years ago | (#36322428)

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.

Re:Something's fishy here... (1)

RazzleFrog (537054) | more than 3 years ago | (#36321216)

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

Because JavaScript changed? (1)

oneiros27 (46144) | more than 3 years ago | (#36321520)

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.

Re:Something's fishy here... (1)

davidflanagan (645311) | more than 3 years ago | (#36322970)

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!

Re:Something's fishy here... (1)

Roachie (2180772) | more than 3 years ago | (#36323668)

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

jQuery? Really? (0, Insightful)

Anonymous Coward | more than 3 years ago | (#36321250)

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 [wikipedia.org] one does it cover?

Re:jQuery? Really? (0)

Anonymous Coward | more than 3 years ago | (#36321666)

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

Re:jQuery? Really? (2)

MadChicken (36468) | more than 3 years ago | (#36321708)

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.

jQuery is widely used for client-side Javascript (1)

Webapprentice (608832) | more than 3 years ago | (#36322710)

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.

Re:jQuery? Really? (1)

davidflanagan (645311) | more than 3 years ago | (#36323020)

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.

Re:jQuery? Really? (1)

marsu_k (701360) | more than 3 years ago | (#36324928)

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.

Re:jQuery? Really? (1)

shutdown -p now (807394) | more than 3 years ago | (#36325516)

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.

Best book on the subject (5, Informative)

Yold (473518) | more than 3 years ago | (#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.

Re:Best book on the subject (0)

Hazel Bergeron (2015538) | more than 3 years ago | (#36321462)

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.

Re:Best book on the subject (1)

_0xd0ad (1974778) | more than 3 years ago | (#36321510)

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.

Re:Best book on the subject (0)

Anonymous Coward | more than 3 years ago | (#36321604)

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.

Re:Best book on the subject (1)

Hazel Bergeron (2015538) | more than 3 years ago | (#36321634)

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.

Re:Best book on the subject (0)

Anonymous Coward | more than 3 years ago | (#36321874)

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.

Re:Best book on the subject (1)

Yold (473518) | more than 3 years ago | (#36322434)

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

Re:Best book on the subject (1)

Hazel Bergeron (2015538) | more than 3 years ago | (#36322656)

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

Re:Best book on the subject (2)

Yold (473518) | more than 3 years ago | (#36322884)

An object is a generic, fundamental aspect of JavaScript.

Re:Best book on the subject (0)

Hazel Bergeron (2015538) | more than 3 years ago | (#36323050)

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.

Re:Best book on the subject (2)

Yold (473518) | more than 3 years ago | (#36323514)

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.

Re:Best book on the subject (0)

Hazel Bergeron (2015538) | more than 3 years ago | (#36324358)

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.

Re:Best book on the subject (1)

obarel (670863) | more than 3 years ago | (#36322666)

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.

Re:Best book on the subject (1)

digsbo (1292334) | more than 3 years ago | (#36321646)

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.

Re:Best book on the subject (1)

Hazel Bergeron (2015538) | more than 3 years ago | (#36321878)

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.

Re:Best book on the subject (0)

Anonymous Coward | more than 3 years ago | (#36323236)

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

Re:Best book on the subject (2)

MillerHighLife21 (876240) | more than 3 years ago | (#36321772)

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.

Re:Best book on the subject (1)

SgtKeeling (717065) | more than 3 years ago | (#36321912)

Mod parent up.

Re:Best book on the subject (1)

Hazel Bergeron (2015538) | more than 3 years ago | (#36322086)

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

Re:Best book on the subject (0)

Anonymous Coward | more than 3 years ago | (#36321824)

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.

Your lawn... (1)

Kozz (7764) | more than 3 years ago | (#36321930)

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

Re:Best book on the subject (0)

Anonymous Coward | more than 3 years ago | (#36322048)

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.

appreciation of powerful language features (0)

Anonymous Coward | more than 3 years ago | (#36323256)

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.

Re:Best book on the subject (1)

Score Whore (32328) | more than 3 years ago | (#36323888)

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.

Re:Best book on the subject (1)

Hazel Bergeron (2015538) | more than 3 years ago | (#36324388)

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.

Re:Best book on the subject (1)

Art3x (973401) | more than 3 years ago | (#36322014)

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.

Re:Best book on the subject (0)

Anonymous Coward | more than 3 years ago | (#36324138)

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.

Re:Best book on the subject (3, Informative)

davidflanagan (645311) | more than 3 years ago | (#36323082)

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.

Re:Best book on the subject (1)

Drooling Iguana (61479) | more than 3 years ago | (#36324450)

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.

Re:Best book on the subject (0)

Anonymous Coward | more than 3 years ago | (#36324790)

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)

Re:Best book on the subject (0)

_0xd0ad (1974778) | more than 3 years ago | (#36324966)

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

Re:Best book on the subject (1)

shutdown -p now (807394) | more than 3 years ago | (#36325538)

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.

Re:Best book on the subject (1)

eigenstates (1364441) | more than 3 years ago | (#36325782)

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.

Re:Best book on the subject (1)

shutdown -p now (807394) | more than 3 years ago | (#36325854)

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.

Re:Best book on the subject (1)

eigenstates (1364441) | more than 3 years ago | (#36325992)

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.

Re:Best book on the subject (2)

shutdown -p now (807394) | more than 3 years ago | (#36326074)

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 only they currently support (albeit slated for inclusion [ecmascript.org] in EcmaScript Harmony).

Re:Best book on the subject (1)

eigenstates (1364441) | more than 3 years ago | (#36326154)

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.

Re:Best book on the subject (2)

shutdown -p now (807394) | more than 3 years ago | (#36326242)

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

Re:Best book on the subject (1)

eigenstates (1364441) | more than 3 years ago | (#36326380)

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/

Re:Best book on the subject (1)

shutdown -p now (807394) | more than 3 years ago | (#36326612)

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

Javascript in my pants (0)

slashpot (11017) | more than 3 years ago | (#36321378)

I have Javascript in my pants.

1100 Pages (0)

theshowmecanuck (703852) | more than 3 years ago | (#36321382)

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.

Re:1100 Pages (2)

RazzleFrog (537054) | more than 3 years ago | (#36321450)

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

Re:1100 Pages (0)

Anonymous Coward | more than 3 years ago | (#36321468)

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

Re:1100 Pages (1)

theshowmecanuck (703852) | more than 3 years ago | (#36321508)

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.

Re:1100 Pages (1)

Roblimo (357) | more than 3 years ago | (#36321538)

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.

Re:1100 Pages (2)

genghisjahn (1344927) | more than 3 years ago | (#36321602)

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.

Re:1100 Pages (1)

guybrush3pwood (1579937) | more than 3 years ago | (#36321902)

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

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

Re:1100 Pages (2)

TheCycoONE (913189) | more than 3 years ago | (#36322068)

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.

Re:1100 Pages (1)

MadChicken (36468) | more than 3 years ago | (#36321746)

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:1100 Pages (2, Informative)

raddan (519638) | more than 3 years ago | (#36321836)

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.

Re:1100 Pages (2)

davidflanagan (645311) | more than 3 years ago | (#36323188)

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.

Re:1100 Pages (1)

binary paladin (684759) | more than 3 years ago | (#36325340)

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.

Visual Effects? (1)

jellomizer (103300) | more than 3 years ago | (#36321684)

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

Re:Visual Effects? (1)

bberens (965711) | more than 3 years ago | (#36322504)

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.

Definitive 6th edition (2)

Henriok (6762) | more than 3 years ago | (#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.

Re:Definitive 6th edition (1)

guybrush3pwood (1579937) | more than 3 years ago | (#36321914)

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

Comment Subject (1)

Quiet_Desperation (858215) | more than 3 years ago | (#36321798)

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.

Re:Comment Subject (1)

H0p313ss (811249) | more than 3 years ago | (#36324254)

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.

What? (-1)

Anonymous Coward | more than 3 years ago | (#36322652)

TLDR;

Print is Obsolete (0)

Anonymous Coward | more than 3 years ago | (#36323038)

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

Re:Print is Obsolete (2)

davidflanagan (645311) | more than 3 years ago | (#36323230)

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/ [oreilly.com]

Re:Print is Obsolete (1)

MadChicken (36468) | more than 3 years ago | (#36327742)

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.

Thank God we have Coffeescript (1)

Anonymous Coward | more than 3 years ago | (#36323206)

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.

Re:Thank God we have Coffeescript (-1)

Anonymous Coward | more than 3 years ago | (#36324688)

No. Fuck you. I like C-like syntax. Python syntax sucks. I repeat, fuck you.

Re:Thank God we have Coffeescript (1)

eigenstates (1364441) | more than 3 years ago | (#36325846)

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.

Gluescript (1)

mpol (719243) | more than 3 years ago | (#36323316)

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.

Re:Gluescript (1)

shutdown -p now (807394) | more than 3 years ago | (#36325562)

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?

Not an issue (0)

Anonymous Coward | more than 3 years ago | (#36323344)

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

javascript is not worthy of the client side (0)

Anonymous Coward | more than 3 years ago | (#36323408)

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.

Good introduction. (0)

Anonymous Coward | more than 3 years ago | (#36323472)

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

Re:Good introduction. (1)

davidflanagan (645311) | more than 3 years ago | (#36323510)

Thanks!

6th edition (0)

Anonymous Coward | more than 3 years ago | (#36323876)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>