Book Review: Eloquent JavaScript: a Modern Introduction To Programming 107
Michael Ross writes "Of all the computer programming languages, JavaScript may be enjoying the most unprecedented renaissance ever. Once derided as a toy language suitable only for spawning bothersome popups in browser windows, JavaScript is rapidly developing into a first-choice web technology on both the client side and the server side. One way to get started learning this ubiquitous language is the book Eloquent JavaScript: A Modern Introduction to Programming." Read below for the rest of Michael's review.
Written by Marijn Haverbeke, the book was published by No Starch Press on 3 February 2011, under the ISBN 978-1593272821. On the publisher's page for the book, visitors will find the table of contents and some reviews. (My thanks to the publisher for a review copy.) The author's book website offers much more, including HTML versions of the book (whose content differ from the print edition), errata (applicable only to the first printing of the paper edition), and an interactive code sandbox where you can run the examples (or at least some of them).
| Eloquent JavaScript: A Modern Introduction to Programming | |
| author | Marijn Haverbeke |
| pages | 224 |
| publisher | No Starch Press |
| rating | 9/10 |
| reviewer | Michael Ross |
| ISBN | 978-1593272821 |
| summary | A concise and lighthearted tutorial on this popular web programming language. |
At a slender 224 pages, this volume might at first glance appear inadequate for covering such a sizable and rich language as JavaScript — and yet the table of contents suggests otherwise, with a dozen chapters covering language basics, functions, objects, arrays, error handling, functional programming, object-oriented programming, modularity, regular expressions, web programming, the DOM, browser events, and HTTP requests. In addition, readers may be reminded of how much information Kernighan and Ritchie were able to pack into the 228 pages of the first edition of their classic The C Programming Language.
Following a pleasant introduction, the first three chapters present the basics of JavaScript. In the first one, the author presents the language's fundamental grammar, specifically: values, data types, arithmetic operators, expressions, variables, control statements, the JavaScript environment, and program structure. The material assumes no prior knowledge of computer programming or even data representation.
In the second chapter, the author does a thorough job of explicating all aspects of functions, including definition form and order, variable scope, arguments, the call stack, closure, and other topics. The subsequent chapter addresses an area important to any programming language, namely, data structures — which in JavaScript are of two varieties, objects and arrays. The author illustrates some best practices, such as modularizing code.
Most programming books underemphasize or even completely neglect the critical topic of error handling, and thus it is encouraging to see the author of this book address it, as early as Chapter 4. He focuses on exception handling, and also touches upon the value of unit testing (incorrectly termed "automated testing"). The subsequent chapter describes functional programming, which is not to be confused with procedural programming, but rather refers to combining functions in order to achieve higher levels of abstraction in one's code, thereby reducing its size and better exposing its functionality amidst the syntactical clutter. One apparent technical flaw is the claim that, in HTML documents, the special characters <, >, and & always must be replaced by their entity values, even when surrounded by whitespace characters (page 78). (Incidentally, any book that mentions the KGS Go Server can't be all bad.)
Object orientation is the subject of the sixth chapter, the longest in the book. Despite the author's efforts, this material will likely prove to be the most challenging to readers, given the numerous idiosyncrasies of JavaScript's objects and their built-in methods. The next chapter explores a related topic, modularity, which unfortunately is not supported natively by JavaScript; the author presents some ideas to work around this limitation.
Of all the data processing performed by web sites and apps, a significant portion of it is text manipulation, where the use of regular expressions can be extremely valuable, despite the potential pitfalls. This is tersely covered in Chapter 8, which, in my opinion, should instead be located far earlier in the book, after the discussion on strings. The next chapter is a fast-paced examination of just some of the key aspects of client-side scripting using JavaScript. The only confusing portion is the reference to "the document tag" (page 155), with no explanation as to what that is. The last three chapters continue the discussion of in-browser programming, focusing on the Document Object Model (DOM), browser events, and HTTP requests. Some of the material feels dated, but it is a decent survey of relevant information.
The narrative is well written, aside from the use of long dashes when semicolons are called for and the occasional strange phrasing, such as "two backslashes follow each other" (page 12). Also, the book contains several erratum, most of them a simple mismatch of singular and plural forms: "The example show" (page 11), "executing a statements" (20), "is a special kind of objects" (46), "special type of objects is" (68), "with is em" (89; should read "is em"), "than of an" (90; should read "than an"), "new type of objects" (123), "used as to map" (146), "on [the] current field" (185), and "touched on [in] Chapter 9" (190).
The author wisely makes use of numerous examples, which are of two types: Most if not all of the fundamental concepts are illustrated with pithy examples — particularly in the first half. In Chapters 3, 5, 6, and 11, the author utilizes extended, fictional examples. Some readers may argue that these longer ones are excessively so — especially the terrarium — but there are many nuggets to be found in those pages. In fact, the book overall is largely free of fluff.
In terms of technical information, the book does not attempt to cover all the details of the language itself. Readers will appreciate that the author does not shrink from pointing out the weaknesses in JavaScript, as well as explaining the problems they may cause. One blemish is that many of the small sections of code contain a mixture of complete lines of code as well as standalone expressions (in bold), and usually those expressions are terminated with semicolons, giving them the appearance of lines of code. No doubt some readers will be confused by this convention.
From a production standpoint, the text is quite readable, except for the quite annoying and obvious problem that the font to indicate in-line source code looks almost identical to the non-code text font. There are few diagrams and even fewer screenshots, but that poses no difficulties.
At times this book is even fun to read, partly because of the use of non-silly humor, especially in the two examples of the eccentric (and cat-centric) aunt, and an unsocial reclusive programmer (imagine that).
If you choose to start your JavaScript journey with this book, it can quickly teach you a lot of technical information (relative to its size), and also programming wisdom.
Michael Ross is a freelance web developer and writer.
You can purchase Eloquent JavaScript: A Modern Introduction to Programming from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.
Re: (Score:2)
No, Chii. That's Javascript.
Accidentally apropos Freudian slip? (Score:5, Funny)
Read blow for the rest of Michael's review.
No matter how eloquent it is, Java(ECMA)Script still blows.
Re: (Score:2)
"Read blow for the rest of Michael's review."
I interpreted it as "Michael's review is blow, thou have been warned!"
Re: (Score:2)
Read blow for the rest of Michael's review.
No matter how eloquent it is, Java(ECMA)Script still blows.
Laugh (or cry) all you want - it's taken over the web, and will take over the world. EMCAScript is getting better every year, it's got functional features, prototyping a la Self, is extensible as hell and has the most deployed interpreters/VMs (and JITs) in the world. With NodeJS and BackboneJS it's going to take a chunk out of server-side programming as well.
Yeah, JS is shit, just like HTML. It's also the lingua-franca of the modern web (along with HTML, of course) and it's growing faster than C or Java
Read blow? (Score:2)
Wasn't that a movie with Johnny Depp about cocaine smuggling or something?
I mean, I suppose to could have been based on a book by the same name, but I have no idea what that has to with Javascript.
Oh dear. (Score:4, Insightful)
JavaScript is rapidly developing into a first-choice web technology on both the client side and the server side
"Technology". It's just another interpreted language with a 'C' like syntax. It only caught on because of marketing (it had 'Java' in its name) and that was the only client side language at the time.
Yeah, it's great to have one language for front and back, but JavaScript?
I don't want to live on this planet anymore.
Re:Oh dear. (Score:5, Informative)
What do you mean by "it was the only client side language at the time"?
It's still the only choice.
What exactly is javascript helping to do there? (Score:1)
... the only client side language ...
So have I got this straight, does that mean it's the only way webpage owners can download loads of code on to my computer and run it, when all I did was click to view their page?
When exactly did they get the right to do that?
-wb-
Re: (Score:2, Insightful)
When exactly did they get the right to do that?
You gave them that right by running a program configured to request said code and run it whenever you click a link. If you order a PB&J sandwich and don't tell them to hold the peanut butter because you have a peanut allergy, that is not a case of peanuts being force upon you. Just as you could tell people giving you food not to give you anything with peanuts in it, you could set your browser (or pick a different one) so as to not request that code.
Re: (Score:2)
If you order a PB&J sandwich and don't tell them to hold the peanut butter because you have a peanut allergy, that is not a case of peanuts being force upon you. Just as you could tell people giving you food not to give you anything with peanuts in it, you could set your browser (or pick a different one) so as to not request that code.
To bring your analogy into present-day, everything on the menu has peanuts in it. You can order water, but peanut oil might have accidentally gotten onto the glass.
There are precious few websites anymore that work completely with JavaScript disabled.
Re: (Score:2)
Re: (Score:3)
Almost but not quite: I've been working with CoffeeScript which "compiles" to JavaScript and combined with JQuery its actually nice to work with....as long as one remembers to be exacting in commenting method parameter and return types. Exacting...
Re: (Score:2)
Re: (Score:2)
Yeah, I believe that was the second time Java didn't catch on, right after it failed the first time in embedded systems and before it failed the third time in desktop applications.
Re: (Score:2)
Strange definition.
Re: Oh dear. (Score:2)
The number of systems with Java enabled in the browser is rapidly declining.
You really can't depend on Java being available in a client when developing a web application these days, especially if you're also targetting mobile devices (and with the popularity of iPads these days, you probably are).
Re: (Score:1)
The number of systems with Java enabled in the browser is rapidly declining.
This is sad. I guess I'll have to port to HTML5 my super cool Java boids applets from 1998.
Re:Oh dear. (Score:5, Funny)
Please frame your complaints in the form of pros/cons or valid attacks on the language instead of cheap rhetoric with no citations.
Pros: None.
Cons: JavaScript sucks donkey balls.
Re: (Score:2)
Goat balls too, or so I hear.
Re: (Score:1)
Re: (Score:2)
Pro: Deployed everywhere, so you can use it.
Con: Deployed everywhere, so we're stuck with it.
Re: (Score:3)
No. Around here we frame our posts in the form of car analogies.
Do try to keep up.
Big difference here . . . (Score:5, Insightful)
In addition, readers may be reminded of how much information Kernighan and Ritchie were able to pack into the 228 pages of the first edition of their classic The C Programming Language.
Yeah, but C doesn't have nearly the amount of junk as Javascript. One of these languages you can comfortably make a cheat-sheet notecard carrying a comprehensive overview of the language, as well as some of the common libraries. The other has the words 'java' and 'script' in it.
Re: (Score:1)
Re:Big difference here . . . (Score:5, Interesting)
It's so easy to stray into undefined behavior with C. The language is full of gotchas. Sure, the tip of the iceberg could fit on a notecard or two, but the messy details sure as hell won't. They have whole FAQs for that: http://c-faq.com/ [c-faq.com].
Re: (Score:2)
Re: (Score:2)
I'm sorry, I wasn't aware that the fact that JS also has some gotchas (many of which are not really gotchas at all, or only happen because of trying to break the language intentionally) means that C and C++ don't have any gotchas. C has a gotcha where a pointer to a freed object can lead to writing over other objects and only seeing the damage appear way later in unrelated parts of the program. There are few gotchas in JavaScript as pernicious as just that one. The JS gotchas in your page are all fairly loc
Re: (Score:2)
C has a gotcha where a pointer to a freed object can lead to writing over other objects and only seeing the damage appear way later in unrelated parts of the program.
Yeah, and in Javascript you can try to insert an object into another object, overwriting an object that was there originally, and only seeing the damage appear way later in unrelated parts of the program.
In practice neither of these cases happen very often.
If you're really having trouble, try writing a function like this, and never use free():
void myFree(void **ptr) {
free(*ptr);
*ptr = NULL;
}
Problem solved.
Re: (Score:1)
Re: (Score:2)
Yeah, but C doesn't have nearly the amount of junk as Javascript. One of these languages you can comfortably make a cheat-sheet notecard carrying a comprehensive overview of the language, as well as some of the common libraries.
And then you would still be in a position of reinventing things which people do all the time which are provided by Javascript.
C is cool, C is great, C is wonderful, C does not serve all purposes and it probably never will. But never say never.
Re: (Score:2)
One of these languages you can comfortably make a cheat-sheet notecard carrying a comprehensive overview of the language, as well as some of the common libraries.
I view this as a bad thing, based on the number of broken CS-101 data structure implementations that I've seen in my lifetime.
Standard, battle-tested libraries for standard programming tasks are a godsend.
Compatibility? (Score:1)
The fun part about Javascript is the browsers incompatibilities.
Wait, did I say fun part? I meant the most horrible and annoying part.
Enjoy your 200 KB javascript libraries to code without going insane, you jackasses.
Signed,
a C programmer using microcontrollers.
Re: (Score:2)
Re: (Score:1)
Make that three browsers because as a user if it doesn't work in Chrome you try it in FireFox, and if it doesn't work in FireFox you try it in IE.
JavaScript in browsers must be a job-creating stimulus or something, because we get paid to play Whack-A-Mole with browser compatibility.
Sure, it pays the bills, but at the cost of gray hair and sunken hollow bloodshot eyes.
Re: (Score:2)
The point is everything but the physical disk space. The added time it takes to process, compile, and run, added to the rest of the website. Especially when it comes to mobile platforms.
Re: (Score:1)
Re: (Score:1)
They understand, they just choose to ignore that uncomfortable fact. See, bashing popular languages makes them feel smart and important. Repeating the most common complaints, right or wrong, is easy and they're not likely to get called out if they're wrong. Even if they do, they're very likely to get the "its' a common misconception" response. No big deal.
Finding and articulating actual problems is very difficult -- and they risk real criticism if they're wrong. They know better than to risk their ego!
Renaissance of a toy language: still a toy. (Score:2, Insightful)
Seeking eloquence in javascript is much like finding elegance in PHP, or expressiveness in COBOL, or clarity in BASIC. All of them are widely used, hugely popular in their day and with us still. None of them are really any good in any objective sense beyond massive doses of AOL. But mere popularity really doesn't embody anything but wide use. Not quality, not usefulness, not maintainability, not robustness, nothing but the bare fact that many people try to use it. If there's anything to be inferred from thi
we had losers like you back in the 90s (Score:1)
meanwhile the web keeps moving forward. JavaScript has its place just like any technology and can be similarly misused.
Re: (Score:2, Informative)
I think the main benefit of Javascript, and perhaps the reason behind ubiquity, is how forgiving it is. It's fun and easy to learn because, instead of failing to compile and generating 52 errors, Javascript will happily print out numbers like strings and add words to numbers, cheerfully hide global variables with local ones without complaint, and do all manner of weird, often unwanted behaviors, while still *kinda working*, at least enough to get you to keep screwing with it. If Ruby shipped in browsers and
Re:Renaissance of a toy language: still a toy. (Score:4, Insightful)
C has scope rules that hide global variables when local ones are declared in scope also. C can also do all manner of weird and often unwanted things.
The main difference is that C can't be programmed by the monkeys who usually slap web pages together...it's just too exacting, while Javascript can. Famously, you can shoot yourself in both the foot and the face at the same time in C. Javascript doesn't even have a trigger let alone any ammo in the chamber.
Re: (Score:2)
>I think the main benefit of Javascript,..
No. It's because it's the only client side option in browsers.
Re: (Score:2)
Re: Renaissance of a toy language: still a toy. (Score:2, Interesting)
are you joking? javascript, when used the way it was meant to be used - as an object-oriented language with protoypal inheritance - is *extremely* elegant. yes, there are some messy parts and a severe lack of decent string and array functions, but the language itself is incredibly flexible and powerful. especially when using a framework (currently i'm fond of angularjs), it's a pleasure to write javascript for the web. quickly becoming one of my favorite languages.
i don't know any GOOD web developers who do
Re: (Score:2)
Can you extend this argument to JS+DOM?
No, you can't because DOM is not a thing of beauty.
Re: (Score:2)
Coming soon from No Starch Press (Score:1)
Relaxing Employee Performance Reviews and Easy 1000-ft Gain Backpack Hikes.
Irony much? (Score:1)
Er, the plural of erratum is errata.
Re: (Score:2)
the plural of erratum is errata
Or erratums.
Just because we imported the word from Latin 400+ years ago, is no reason to keep using the Latin style pluralization. In the spirit of being even more pretentious by recommending a less pretentious style, there is a general trend to consider it correct to use, or even preferable to use, English style pluralization for words that English imported from Latin and Greek. May it be so for many milleniums.
http://www.memidex.com/erratums [memidex.com]
Security (Score:1)
Most programming books underemphasize or even completely neglect the critical topic of error handling, and thus it is encouraging to see the author of this book address it
Most programming books underemphasize or even completely neglect the critical topic of security, and thus it is discouraging to see the author of this book fail to address it,
I'm a fan of javascript (Score:2, Funny)
And I'm doubly a fan knowing that so many of you whiners hate it. Makes me feel like I must be doing something right.
Word, testify! (Score:2)
That's pretty much how I feel about PHP.
I see what you did there. (Score:2)
A sentence with a 'single errata' contains a mismatch between Latin and English singular and plural forms also too (moreover in addition).
Re: (Score:2)
Re: (Score:2)
I actually read that book, or tried to. As an intro to programming any language it sucked. Hard.
I completely agree with you for this! I have read the whole book to see how it is written. There are so many points that the author did NOT thoroughly describe or even misleads.
Before I go into the book, I want to talk about an issue that JavaScript introduces and I did not realize the changes -- variable scope. It used to be that the keyword 'var' is to declare a variable and the variable will live through out its scope. Not anymore, except between functions! Everything now becomes global and you do not
Can't wait for the sequel... (Score:2)
"Top 500 Oxymoronic Book Titles"
Eloquent Javascript, indeed...
Re: (Score:2)
"REAL web JS" abstracts the work-arounds and goofy tweaks into a library, so the application programmers can write clean code.
First Choice? (Score:2)
JavaScript is rapidly developing into a first-choice web technology on both the client side and the server side.
I call bullshit!
Anti-JavaScript Rant (Score:5, Interesting)
It's only used on the client-side because developers have no other choice, practically speaking. It's the only client-side language supported in most browsers. It's only client-side competitor, Flash scripting, is being killed by Apple and Google. (Java applets always sucked too much to be considered a valid competitor.)
And people want to use it on the server-side because they want to leverage their existing client-side programming knowledge, NOT necessarily because JavaScript is the best language for the job. (Although, it is fairly well-suited for small and medium custom applications.)
I really like dynamic languages and have nothing against them when used for the appropriate task. However, large complex graphics/GUI libraries are NOT the right place for a scripting language. Past a certain size and complexity, it's time for the "anal" features of compiled and type-heavy languages.
It's time we blow up JS+DOM and do HTTP-friendly GUI's right. The industry has been trying for 15 years to get JS+DOM right, and it still blows almost as much as the DLL-Hell of early desktop GUI's. The only saving grace is that we can install 3 different browsers such that it will probably work in at least one. But this triple dripple is simply an insane workaround to insanity.
Let's get the right language for systems programming, and the right GUI primitives that take care of much of the grunt-work of GUI-ness such that the client language doesn't have to carry most of the load.
Blow it up and do it right! If you can't get it right in 15 years, you likely won't get it right in a thousand, or at least I don't want to wait that fucking long.
I also suggest having a standardized single rendering engine rather than Apple making one, Microsoft another, Google yet another, Mozilla yet another, etc. Standards are too vague and difficult to write clearly in English, so let the lone implementation determine subtle specifics instead of each vender doing it slightly different such that something breaks on one or the other because something is 0.000001 pixels further left than the testing platform.
Let's stop beating a dead jsHorse.
Re: (Score:2)
Blow it up and do it right! If you can't get it right in 15 years, you likely won't get it right in a thousand
I don't know much about java or script or javascript but I like what you said. For past 15 years there has been various scripting stuff comes and goes. Some browsers will work, then they won't then later the same browser can display a webpage. Standards are vague ( and we all know what standards are, ability to choose from several).
SchrodingerScript (Score:1)
Yes. Where is this grand Wonderland of yours where it all just works (or at least breaks consistently). I wanna go there now!
Current browsers are powered by drunk Schrodinger cats on treadmills.
Or do you think GUI's in general are a hard problem to get right on a mass scale? Most GUI idioms have been around for 20+ years , so it's not like it's a moving target (although portables are stirring things a bit).
Re: (Score:2)
(although portables are stirring things a bit)
Not that hugely. They only really change a few things, of which the most notable ones are the lack of a continuously present pointer and the different set of events. If your GUI doesn't depend on tracking unclicked mouse motion, you can probably transition relatively easily.
Re: (Score:2)
It's time we blow up JS+DOM and do HTTP-friendly GUI's right.
If you want an historical example of people trying this, go look at ADA. You will see what kinds of challenges will come up, and maybe you'll think of ways to overcome them.
Re: (Score:2)
No other choice? Take a look at NodeJS [nodejs.org].
Please explain in exactly what way Node.js offers an alternative to javascript on the client side; go ahead, we're waiting ;-)
Re: (Score:1)
And there's also the problem with the messy DOM. It's not just JavaScript.
Re: (Score:1)
Programming languages may be sufficiently describable via English, but graphics and GUI's seem to be a different animal. It's hard to treat many features independently such that describing all the possible interactions and potential overlap behavior may be too much for text.
And how does a reference standard make for "inflexible code"?
Re: (Score:2)
Couldn't resist: http://xkcd.com/927/ [xkcd.com]
Doesn't fit 100% but 93%. At least.
Re: (Score:2)
Anyhow, I was mildly amused at the efforts to disparage this language above. Donkey Balls and all; quite convincing for some of you I'm sure.
While the strengths you describe are all true, you conveniently ignore a few well-know problems--or are ignorant of some of the more sophisticated points. For instance, the rules regarding scope and closures and when "this" is captured are bad mistakes, just a complete fucking mess. The several flat-out errors in the design of this language are very well known and widely discussed, such that in any reasonably sophisticated discussion of javascript people often take that knowledge for granted. I don't know i
Unit testing THE PROPER TERM? (Score:2)
The terms in this field are MADE UP and then popularized by people who love new terms so they can sound smart with more jargon to confuse the masses with their "brilliance".
Automated Testing is what it is and it existed before Unit Testing. We really must cut down on the huge number of terms we adopt in this profession and when we do, it should be something that isn't so removed from reality.... like Unit Testing or cookies...
We should shun people who mindlessly go around enforcing these new terms onto oth
"erratum" (Score:2)
"the book contains several erratum, most of them a simple mismatch of singular and plural forms:"
i lol'd
"Automated testing" vs "Unit testing" (Score:2)
I haven't read the book, but I wonder whether the reviewer has got this right.
Unit testing is a very specific thing -- testing contained components individually. Checking that class X does what it's meant to do.
But it's separate from integration testing where you plug a bunch of your components together and check that they collaborate correctly. ... and you can automate both. I'd hope the book covers both.