If you’re unfamiliar with Jasmine, Ragonha will give you a solid foundation of the testing framework by the end of the second chapter. Less than 40 pages in and you’ll understand Jasmine’s approach to testing, as well as how to stand up a basic test suite. His coverage of the core functions and the collection of built-in matchers is concise and accurate. He builds on this foundation by demonstrating Jasmine’s abilities in testing everything from asynchronous code (Sinon.js!) to MVC components (Backbone.js!) to AMD modules (Require.js!).
Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.
Borderline four stars... and I think when it's completed and fully edited, it just might be. (Disclosure: I read an early access edition; O'Reilly ...moreBorderline four stars... and I think when it's completed and fully edited, it just might be. (Disclosure: I read an early access edition; O'Reilly  has been doing that a lot lately...)
: To be fair: almost all of the technical book publishers that I know of are doing this lately -- i.e., releasing "Early Access Editions" and "MEAPs" and the like.
: I go back and forth on this bit of critique. If you're "all theory" then you're potentially losing out on providing some value because you're discussion is too far away from the real problems; but if you're too close to "the real thing" then you're just talking about that specific situation or tool-chain and it winds up being about addressing that problem with that tool, and not really "that class of problem". Elliott is somewhere in the middle here, listing only slightly toward "too specific" and only in a couple of places.
: The PDF I have of this book has a little more, and some slightly different content than the version I read on my Kindle. Again: "Early Access Editions" and all that...(less)
And that's where MacCaw's Little Book on CoffeeScript comes in.
It's short (62 pages!) and gets right to the point. And MacCaw is (by and large) eloquent about the subject, if a bit... provocative at times.
Loved: I wanted to learn a couple of things about CoffeeScript and MacCaw gave us exactly that, and with no ceremony. "This is CoffeeScript. Yes, this is all there is to it. And we're done."
However: there were a few statements in the book that made me bristle a bit. Example:
And the crux of the book is about CoffeeScript. And by the end of it, you'll know enough about that little language to form your own opinion of it. And that opinion is probably something like:
I would rate this one as a pretty solid introduction to AngularJS, covering the framework's philosophy, the core APIs, and getting into a few (but not...moreI would rate this one as a pretty solid introduction to AngularJS, covering the framework's philosophy, the core APIs, and getting into a few (but not all) of the nuts-and-bolts. By the time you get to the end of it, you should be able to build a non-trivial app in Angular -- though the jury's out on exactly how non-trivial that will be. Green and Seshadri have a clear and straightforward approach to presenting the material (no tricks!) and it (mostly) helps that they're both so deeply involved in the framework's development.
I had quite a few "ah-ha" moments while reading this one, enough to get me better engaged with "the Angular Way" and to see some mistakes and pitfalls I was making in my own apps. Unfortunately, despite how clear Green and Seshadri are throughout the text, there are still a few concepts that don't quite ring totally clear. In particular: (1) there is a whole chapter on directives and yet at the end of it, I was not sure that I understood them that much more than when I started ; (2) whither filters?; (3) I have a sneaking suspicion that they slyly snuck in a few of the kinda/sorta undocumented features of the core Angular libraries without really mentioning it. 
Overall, the book is well-structured, with clearly titled chapters, making it easy to jump around and cherry-pick what you need out of it. If you're new to Angular, I highly recommend this book and urge you to (at a minimum) read the first four chapters.
: That being said: you can tell just how important Green and Seshadri think directives are, and also just how complicated they think they are. Directives are introduced pretty early on, and then they get their own chapter, and then there's another more detailed (and arguably more useful) illustrative example in the "Cheatsheet and Recipes" chapter. (Which, by the way, would have been better titled as "Case Studies" -- but I digress.) Anyway: I'm thinking that directives are just one of those things that's critical to "the Angular Way" but is also fairly complex (incidentally or otherwise?) and you just need to find your own "ah-ha" moment.
: I say kinda/sorta because the Angular documentation (you may have noticed) is broken down into an "API Reference" and a "Developer Guide" and it isn't always clear which features are documented where. Or why something is documented in one but not the other (or else why it's in both...) So maybe I'm being a little unfair when I say "snuck in" and "undocumented" but... well: that's how it felt.(less)
tl;dr: It's a 150 page essay on auto-boxing, full of dangerous code examples and anti-patterns and soft warnings to "not do what I just did", and some...moretl;dr: It's a 150 page essay on auto-boxing, full of dangerous code examples and anti-patterns and soft warnings to "not do what I just did", and some of the wording is not-wrong-but-not-quite-right, but hey there are some decent parts, I guess.
This is an admirable goal, and one that I fully support. But when I got to the end, I scratched my head and wondered aloud: "Did I just finish a 150 page essay on auto-(un)boxing?"
And I think that's why my reaction was to think: "This is a dangerous book."[^1] As an author, you're in a powerful position as a teacher and role model--so if you're demonstrating "weird" code or error-prone techniques or calling things by the wrong name[^2], then you might wind up influencing a bunch of developers into those bad habits--even if you didn't mean to, even if you warned them against those exact methods.
Perhaps I'm over-reacting a little bit, but believe strongly that these things matter.
"Comma-first" or abusing ASI is one thing... But using Number where you should be using parseInt is quite another.
I had other criticisms as well (e.g., talking about "associative arrays" is always a sketchy proposition when your target audience is JS novices; e.g., making no mention of strict mode whatsoever[^3]) but they're really just pale variations on "the big one" above.
[^3]: The omission of strict mode seems like a major oversight to me. I realize that Lindley's discussion was germane to ES3 and not ES5--but 'use strict' is out there in the wild, and it can dramatically alter some of the behaviors described in this book. If the target audience really is people that are diving into the plumbing of their essential libraries, then some of them are going to see this and not realize the significant implications it might have w/r/t/ some bug they're trying to trace.
[^4]: Perhaps even too colloquial from time to time. "Grok"? Seriously? We need a moratorium on this so-called word.
Disclosure: I received an electronic copy of this book from the publisher in exchange for writing a review.(less)
I had the privilege of getting some early looks at this book and am glad he pulled the wraps off of it to share with everyone.
Right off the bat: I read an early access edition, and in a lot of places... it shows. It'll come through editing and be a lot tighter by the time you...moreRight off the bat: I read an early access edition, and in a lot of places... it shows. It'll come through editing and be a lot tighter by the time you read it. I promise.
Putting that aside, I had some mixed feelings about this book. I'll try to explain it as follows:
Trostler talks about this, but not nearly at the length I was hoping for. Whereas Murphey kept her talk (albeit, it was a one hour talk) focused on adopting testable styles, Trostler's book manages to be about writing testable code, writing tests, and running tests. Given the title, I was expecting more about that functional style, more about decomposing functions into discrete units, more about how to reason about problems etc. And it wasn't even that this was missing, just that he was more/less finished talking about that by (say...) Chapter 3.
My hat is off to Trostler for furthering the conversation; and/but: his editor has some work ahead of them both.(less)
Hales opens the book with a discussion of "modern" client-side architecture, devoting the first four chapters not to specific technologies, but instead to designing loosely coupled "Mobile First" front-ends. As you might have guessed, this means that we spend some time talking about client-side templates;  about how to approach fluid, "native-feeling" user experiences; and about how to reason about, build, and deploy the front-end piece of your technology stack. Again, as Hales is presenting us with a "Mobile First"  approach, a lot of attention is given to performance -- how to keep components lightweight, how to minimize network overhead, how to design for connectivity interruptions, and how to keep battery consumption down. Overall, it's a very strong first half -- and by itself was worth the price of admission.
The second half of the book is dedicated to the five "HTML5e"  APIs that Hales calls out as modern, as the place where you can do some real innovation with your app. These five APIs include: WebSockets, Web Storage (e.g., localStorage and sessionStorage), Geolocation, Device Orientation, and Web Workers. Without going into detail about each of those APIs here, I will say that Hales introduces each one in an at least serviceable fashion. Each of these chapters describes what that API is, what its target use case is, what the status of its specification is, (approximately) what kind of coverage is out there from the browser vendors, a case study implementation built on top of it, what it takes to shim or polyfill the API (if possible), and what frameworks are out there to support you if you don't want to "run naked" with that API. Each of these API-centric chapters can stand alone, and you should be able to use any of them as a quick orientation should the need arise. That being said, they vary in their technical depth -- e.g., the WebSockets chapter is quite thorough  while the chapter on Device Orientation seemed to just barely cover the fundamentals. 
All that being said, I did have a couple of quibbles that I need to raise, lest I feel derelict in my duty as a reviewer:
As I finished the book, I found myself feeling pretty excited about these new "HTML5e" technologies. Hales does a superb job in introducing them and in illustrating the possibilities latent in each one. Even better than that though was his discussion of how to go about designing and developing these modern front-end architectures to begin with. I would definitely recommend this book to front-end developers that have their fundamentals down and are ready to start looking at these kinds of sophisticated APIs and modern architectures.
: Well, almost all. There was no WebGL action in there, but it seems kind of ridiculous to think that that would be lumped in there with the "HTML5e" technologies.
: Hales seems to go a step beyond "Mobile First" and (in the Preface) tentatively introduces this notion of "Offline First". (And/but never really comes back to that little maxim.)
: Hales says right in the Preface that "if you are convinced that server-side generated markup is the way of the future, then chances are you won’t enjoy this book." Unfortunately, I think that this statement smells a bit of trolling, and it fails to acknowledge that there's nuance here. This is a disappointment, because so much of the rest of this book speaks very intelligently about evaluating specific technologies to see how they might solve your problem, and about the choices and trade-offs that you need to make along the way. Where and how your app's mark-up is generated is another of these considerations, and it was frustrating to see that question cast off so flippantly. (To be totally fair, Hales does later say: "Most of the time, you’ll end up with a hybrid application that does some processing on the server and much more on the client." Which is a far more sensible thing to say, though considering it's stated in Chapter 4, it's almost too-little-too-late.)
: It was somewhere around Chapter 2 that I started to ask myself: Is "Mobile First" just a euphemism for "Modern First"? After all, who are our polyfills and shims really targeting?
: "HTML5e" is Hales' shorthand for "HTML5 for Enterprise". I rather took a shine to that.
: Though I'd argue that he could have provided a little more background on Comet and long-polling, just for the sake of being thorough.
: Perhaps I missed the point? Maybe that really was everything there was to say about Device Orientation?
(Disclosure: I received an electronic copy of this book in exchange for writing a review.)(less)
Would I recommend it to other front-end developers? Yes, but with the caveat that it'll get you up and running, and not much else. You'll soon be after more, and more detailed, information.(less)
On the surface, many of my quibbles with the book seem like nit-picks:
• The first eight chapters seem like they could have been rolled into one; • The section on namespacing patterns seems like it should have been its own stand-alone chapter, and not “jammed in” with the jQuery plug-in design patterns; and • what is with the single-page final “Conclusions” chapter? 
I don’t place all of the blame on Addy Osmani for this, though. As I pondered my disappointment, I realized that his editors probably phoned it in with this one. Though some effort would be required to restructure the book, I think there was some easy guidance they could have given about restructuring the book to make it easier to bring out the highlights; but they just didn’t bother. Even if we give them the benefit of the doubt and assume that they meant for it to be published this way, I maintain that they half-assed the editing;  for example:
Like I said: they really phoned in the editing.
Now, there is a highlight reel here. There is plenty of useful content within the book–and this comes back to my original statement about feeling let down because of how much respect I have for Osmani. As anyone who reads Osmani’s blog (or his guest posts around the web, or his screencasts…) knows–he has a terrific pedagocial streak, and it’s clear that he enjoys helping people learn, and that he’s particularly adept at helping them learn to be better front-end developers. Throughout the first eight chapters,  he does a fantastic job of defining what constitutes a pattern, of explaining why we (as front-end developers) should care about and study design patterns, and of what makes something an anti-pattern. Chapter Nine (the “walking tour” of the Gang of Four patterns) has the right balance between discussing the theoretical details behind a given pattern, and an illustration of its practical application. The most critical follow-up to Chapter Nine is found in Chapter Twelve, which essentially takes jQuery and uses it as a case study for those design patterns in action. Lastly, you can think of Osmani as providing a curator’s role with this book; there are many places in the text where he is citing work from others as either illustrating a particular facet of a design pattern, or else as building on it in some important way. 
(Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.)
 Perhaps that’s the price of success? That the people that admire you wind up feeling let down when you deliver something that’s… Only average? Not mind-blowing? There’s a part of me that thinks I’m being unfair or too harsh, but at the same time… Sometimes you need to hold folks to high standards?
 Granted: I’ve dinged other books for not having a “concluding” chapter, and for otherwise ending abruptly while wrapping up some other subject (Sarrion’s jQuery UI book comes immediately to mind)–clearly I would rather have a weak “concluding” chapter than no concluding chapter at all. So I’m kind of being a hypocrite here. Kind of.
 Mostly the technical editing; but it seems like the copy-editing suffered a bit as well. (My heart sank a little bit when I saw the second ‘k’ in Nicholas Zakas' name in the reference section.)
 If we assume that a chapter’s title is an H1 heading, major sections are an H2, and so on down the list, then I would submit that there are numerous examples throughout the text where we have H2-level headings that seem like they should be H3 or below. E.g., how “Pseudoclassical Decorators” and “Decorators with jQuery” are both H2 level headings, but feel like H3 level sub-sections to “The Decorator Pattern” section; e.g., the H2 level “Namespacing Patterns” section that (in my mind) really should mark a whole new chapter in its own right.
 Again: those first eight chapters really ought to have been formed up like Voltron into one.
 And here is where recipients of the ebook version may be better off. I’m not sure how the links and references appear in the print book, but the ebook has clickable links to blog posts and other websites. Which is great. Thumbs up to that.
Before we go any further, a few words about what the book is not:
Now, for as easy as it is to recommend ClojureScript: Up and Running, I did find myself with a few critiques.
Despite these (minor?) critiques, I would easily and heartily recommend ClojureScript: Up and Running to anyone with even a passing interest in learning the language. You may not walk away from the book with a desire to use ClojureScript, but you'll certainly understand its basics, and at least then you're forming an informed opinion of it. And this is largely attributable to Sierra and VanderHart's lucid writing -- there is something about Clojure that makes "technical writers" into "better writers". To borrow from Fogus and Houser: it could be because "Clojure changes the way you think!"[^8]
[^4]: Though it might help to have done a couple of the koans.
[^5]: You could read it in a day, but I’d suggest taking your time, and really letting it sink in. Make it two days.
Disclosure: I received an electronic copy I the book in exchange for writing a review.(less)
--- long version: ---
Now, I don't want to give away the ending, but Web Workers are actually pretty simple to use.  There are a few important limitations to keep in mind (e.g., no DOM access, limited BOM access) but Web Workers are otherwise a great candidate feature in the "HTML5 technology constellation" to perform heavyweight, long-running tasks. Green's approach here is to provide simple explanations and then demonstrate the features in action with relevant code examples. With his explanations, you should be up and running with Web Workers in an afternoon.
That being said, I had a few minor quibbles closing the covers on this one. First, the sample code is available in a Github repo, but this isn't mentioned until the closing remarks in the final chapter; this is a non-sensical place for them, especially considering that there is already a perfect place to mention them in the preface. Second, some of the code examples as they appear in the book are either rough-around-the-edges or else incomplete; for example, Example 3-4 has a variable declared twice, and Example 5-1 is missing the style information (meaning your version doesn't look anything like the screenshot). I'm a bit of a pedant about these sorts of things, so they always rub me the wrong way, but they do not otherwise detract from the technical points that Green is trying to get a across in the book, so I won't hold that against him.
Recommended? If you need to come up to speed on Web Workers quickly without anything extra? Yes.
 Provided you're in a browser that supports them.(less)
Where the book becomes more interesting is in Parts II ("Programming Practices") and III ("Automation"). Again: the chapters that comprise Part II are going to seem like review for many seasoned JS devs: keep your JS and your mark-up loosely coupled; avoid global variables; keep configuration data separate from business logic; use feature detection instead of browser detection. As much of these may seem like review,  don't get cocky and skim it, either--there are some gems in there. (In particular I'm thinking of the chapter on Event Handling that spawned this interesting post by Ben Nadel.)
The chapters in the Automation section were my favorites. Zakas builds up a solid Ant-based  build system over the course of 7 chapters that includes validation and linting, file concatenation and gzipping, minification, documentation, and automated testing. As I've become highly interested in the build process, I was riveted by these chapters. Zakas at least touched on every topic in the automation/build topic that I would have wanted to see. But that being said: the operative phrase was "touched on"--I would have loved to see more on this subject. He provides a lot of excellent starter material, and Appendix B is a rich list of other jumping-off points, but it also seemed... shallow? Like he was just scratching the surface? This seemed especially true of the chapters on documentation  and testing.  
 Although, honestly, my first thought was: "Really? Ant?"
 Although I suppose I have lofty expectations for documentation. (A detailed glossary of what the different @keyword annotations are for etc.) This chapter is probably fine, it's my expectations that are messed up.
 I definitely think there could have been more on testing. There's like a page and a half on PhantomJS. Having played around with it a bit myself, I feel like it could have earned a chapter all to itself. Granted, I wouldn't want the whole book to be about testing (Grails in Action, I looking in your direction)--and since most JS books don't mention testing at all, I'm grateful to see it get at least the chapter that it did but... I could have used a little more.
Disclosure: I got a free copy from O'Reilly in exchange for writing a review as part of their blogger/reviewer program...(less)
Eric Sarrion's jQuery UI (published by O'Reilly) is a beginner-to-intermediate level overview of the jQuery UI library and its widgets.  Sarrion wa...moreEric Sarrion's jQuery UI (published by O'Reilly) is a beginner-to-intermediate level overview of the jQuery UI library and its widgets.  Sarrion walks through these widgets one-by-one, chapter-by-chapter, offering a description for each, elaborating on the UI problem that each is designed to solve, and then detailing the API for each of these widgets. Each chapter is constructed after this pattern, illustrating how to setup your mark-up to best work with these widgets, how to initialize and interact with each widget type, and then showing some example implementations of varying degrees of sophistication.
» Sloppy mark-up. Sarrion mentions that Internet Explorer needs a doctype, but then does not go on say what a doctype is, or why it's necessary or what the consequences of omitting the doctype are... And/but then he doesn't quote the attribute values in his sample HTML either. Even a footnote or two on such subjects would suffice.
 Sarrion's jQuery UI covers version 1.8, but I noticed that it does not cover the position utility. As the position utility is currently flagged on the website as "new", then I presume that the book went to press before that utility's release.
 Though I was disappointed that there was no associated Github repo.
 I'm tempted to go as far as to say they're "superior" to the official documentation, which I've always felt were sort of tacked on. It isn't as though jQuery UI has a terribly complex API (it doesn't, though it is quirky and idiomatic-unto-itself (which: "I guess it's internally consistent, at least")) -- it's just that the official docs focus more on the examples and bury the actual documentation "down there" below the fold, like an after thought. "Minus one to that", if you ask me.
 Turns out that you can. But: !?!?!?
 A thing I don't like, but whatever.
 Doubly dangerous because they're missing their curly braces.
 As opposed to feature detection.
 Table 8-9, I'm looking in your direction.
 E.g., a junior or mid-level dev in an organization that is already using jQuery UI; e.g., an e-commerce shop that is heavy on back-end devs and just wants to put some quick polish on their site.
 This is only partly true. I give Sarrion some big-time bonus points for the calculator example at the end of chapter 5 where he builds the thing up as a one-off, then re-factors it into a plugin-style widget. (less)
And read them in that order: The Good Parts, Patterns, and then High Performance.
So you're probably wondering then: if you recommend it so highly, why only four stars?
The four stars comes mostly from two niggling points:
(2) And this is super nit-picky but... The book could have taken another quick editorial pass for spelling and grammar. The one that stuck out at me was right in the intro to Chapter 6: "But it's important to keep the end goal in mind--we want to reuse cod;." Indeed.
† : An in-depth overview, but an overview nonetheless.
‡ : Stefanov is careful to "keep the browser out of it" and dedicates only one chapter (Chapter 8: DOM and Browser Patterns) to the subject; though everyone's favorite host environment does creep in a couple of times, in a couple of examples.(less)
(2) The frustrating part about working at a well-organized shop is that you get yourself all excited for a book like this and then half the recommendations in there are things that you're already doing. Put scripts at the bottom of the document? Check. Minify and compress? Check. Concatenate and package? Check. So on the one hand you say: "I guess I can sleep a little easier at night knowing that our build system adheres to the best practices recommended by the experts out there." But on the other hand, you're a little disappointed because you were hoping for some startling revelations. Again: not that this makes it without merit. From this perspective, what is noteworthy about this book is that these best practices and techniques are all gathered up in one place and presented in a logical order; even if "you're already doing it right", it is still a worthwhile exercise to meditate on the specifics, and to really go deep on why these best practices are important. (Plus, it's great to see the data -- nothing beats a little chartporn for proving the point.) [ Rated: ★★★★ ](less)
While I was reading this, I liked to imagine that I was at university and that Douglas Crockford was the insanely popular genius professor that showed up late for lectures, and then either spoke too fast or else mumbled a lot, and then locked himself in his office refusing to answer the door during office hours while he worked on his Next Big Thing that would make everyone oooh and aaah and validate his brilliance. Meanwhile, in that same imaginary university, Nicholas Zakas was the graduate student that served as the TA to that class—and he happened to be equally brilliant and super-accessible and willing to take the time out to explain it all in a way that was thorough and comprehensible.
Crockford's is a short book. It's a bit terse at times but his examples are clear and he supplements these with railroad diagrams[‡:]. That terseness also translates more/less directly into density, like he's running 10:1 compression on his thoughts here. They require some unpacking and digestion.
Of particular note: Crockford dedicates the entire 9th chapter to code-writing style. Why? He argues that it is an essential skill, that good code-writing eliminates ambiguities (see also: Appendices A & B) and makes the code easier to read and therefore easier (and cheaper) to maintain overtime -- doubly so if that code's lifespan exceeds that of its original developer.
This book is a great one to keep next to David Flanagan's "el Rhino diablo". That said, I believe this one should be consulted first to confirm good function and good form before winding back onto something more encyclopedic.
‡ = To be perfectly frank, the railroad diagrams are bewildering at first. If you have never seen them before, they provide a serious "WTF?" moment the first time. When I encountered the second set of railroad diagrams was when I knew that I was going to need to re-read the first quarter of the book just to be safe.
--- 2010 UPDATE: 3rd read. Still good, still relevant. Definitely the kind of book you get a little more out of each time. (For one thing, I slightly flubbed the quote above about the arrays, but not so bad as to retract it.)(less)
This book has been on my shelf for five years. I use it every week; I should probably know more by now but this book always has exactly what I need to...moreThis book has been on my shelf for five years. I use it every week; I should probably know more by now but this book always has exactly what I need to jumpstart me through whatever brain-fart froze me up in the first place.
It has earned the nickname: El Rhino Diablo!
---- Updated for Sixth Edition ----