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 sometl;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.
Cody Lindley's JavaScript Enlightenment has an awesome title, and I wanted very much to like it--but I think I'm going to have a hard time recommending it to anyone. Maybe.
Lindley states that the target audience for his book is (effectively) JavaScript dilettantes. In his words:
...it is my hope that the material in this book will transform you from a JavaScript library user into a JavaScript developer.
I interpretted that statement to mean that he is looking at the designers and the junior developers and the programmers coming at JavaScript from other languages--all the ones out there that have been using jQuery and/or ExtJS and/or Dojo with effectiveness (or at least competence) and now they're interested in digging into the guts of their favorite library, and perhaps even getting their heads around that thorny beast called JavaScript.
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 ?"
Understand objects and you will understand JavaScript.
This is (more/less) Lindley's thesis statement for the rest of the book. From there, we have a lot of discussion and exposition about JavaScript's types, including quite a bit of examination into how the various primitives are coerced (behind the scenes) into their wrappers and then back down again. Lindley is right, this is important stuff to know if you want to have a deep understanding of JavaScript--but if you're at the point with JS libraries that you're taking a wrench to the plumbing, then you've probably already gotten this information on your own already. (Or else have learned how to look it up in or or the .) But my skepticism about this might be totally unfounded--perhaps there is a big audience for this kind of book. (Most of the ratings on 카지노싸이트 are 5 stars.)
But... My biggest issue comes from what I perceive to be a... almost reckless or dangerous approach to presenting the material. What I mean by this is that while many of the code examples are technically correct, they are not idiomatic -- in other words, you wouldn't see code like that "in the wild." (Or shouldn't, anyway.) Sure, you can use the String constructor to create strings -- but this almost never offers you any advantage over simply creating a string with literals. (Most of the time it will hurt you, or confuse the typeof operator, or lead to some other language quirk that will catch a JavaScript novice off-guard.) Granted, to Lindley's credit, he states in numerous places in the text that "no one really does this" or "you should just use the primitive/literal form of this" -- but after also asserting (right at the very beginning) that the reader should pay more attention to the code... Well, I'm fearful that those same readers will pick up hard-to-break bad habits.
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 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.
So where do I land on this book? For all my critique of it, I am not sure that I have a recommendation that fills quite the same niche. Addy Osmani's Learning JavaScript Design Patterns came to mind first--but then I thought about how that might actually be a follow-up read to JavaScript Enlightment. If Osmani's Patterns book is out, then so is Stefanov's JavaScript Patterns. And Lindley more/less explicitly calls out Crockford's JavaScript The Good Parts as the kind of book that would scare off his target audience. Nicholas Zakas' new book, Principles of Object-Oriented Programming in JavaScript, is very similar in what it covers, and has more/less the same thesis... According to my survey, that's the closest contender. (And each offers something that the other does not so...)
I guess my final verdict is that I'd recommend Zakas' Principles of Object-Oriented Programming in JavaScript, and if it scares you too much then back-track to JavaScript Enlightenment -- but with the caution that you need to be disciplined in how you approach it, because we can't have you littering your code with new Number(1).
----
[^1]: I had a similar reaction when I reviewed .
[^2]: For example: not calling "auto-boxing" by name. For example: calling it a "self-invoking anonymous function" instead of an .
[^3]: The omission of 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....more
Nicholas Zakas has a new (and short!) book out on Leanpub called Principles of Object-Oriented Programming in JavaScript. Remember the OOP coverage frNicholas Zakas has a new (and short!) book out on Leanpub called Principles of Object-Oriented Programming in JavaScript. Remember the OOP coverage from his Professional JavaScript for Web Developers? It’s like a deep-dive version of that. Recommended.
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.
Zakas goes into the gritty details of the various OOP patterns that are available and idiomatic in JavaScript. After some technical introduction into some of JavaScript's low-level details (mostly around the primitives and reference types), he gets in to the different patterns, touching on the tried-and-true (if flawed) methods that we relied on from back in the ECMAScript 3 days, through to the new and native ECMAScript 5 methods. He also gets into mixins and scope-safe constructors.
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 youRight 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:
Rebecca Murphey did a talk during the 2012 JavaScript Summit (put on by E4H) which was titled "Writing Testable JavaScript". Early on in that talk, she impressed upon us that she was going to talk about how to write testable JavaScript, and not how to write JavaScript tests, nor how to test JavaScript. These are important distinctions. Writing tests (in a way) is this weird hybrid of somehow both writing more code and writing documentation. And testing your code is ... well, it's the act of putting your code through the accompanying tests to see if they pass muster. But writing testable code is about adopting a certain style wherein your code becomes easier to test. And the argument goes that if your code is easier to test, then it is also easier to reason about. (Insert functional programming rant here.)
Anyway...
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.
From there, he takes us on a tour of the rest of Test Town: writing unit tests, writing integration tests, code coverage, performance testing, load testing, debugging, linting and code quality, and how to bundle it all up and automate it. Somehow this is both too much information and not nearly enough at the same time. For example: there is a whole chapter dedicated to code coverage, and yet I walked away from it not really sure if I knew how to do that kind of instrumentation, nor if I fully understood the value. For example: integration testing, performance testing, and load testing are all jammed in to one chapter, and should probably have been split up in to separate chapters, and/but he also starts talking about things (e.g., generating HAR reports) which are... not strictly testing JavaScript.
I think maybe that's where I got my first real taste of those mixed feelings. I've been looking at a lot of front-end performance stuff lately, and so I'm very interested in it. But talking about "wire weight" is not what I think about when I see a book titled Testable JavaScript.
At any rate, lest this turns in to an off-color and off-topic rant: I reconcile my mixed feelings about the book in a mostly positive manner. The things that are outside the scope that's implied by the title are all things that any front-end engineer worth her semicolons should be fussing about anyway -- so that's all well and good. And I see here in my notes a snarky remark about "suggested alternative title: Testing JavaScript with Y.Test" -- but that's a little unfair of me. Overall, this book (and books like it) need to be written for front-end engineers. We need this badly, and I'm happy to start seeing these books crop up. This is the sort of thing that we need to see more of in our discipline.
My hat is off to Trostler for furthering the conversation; and/but: his editor has some work ahead of them both....more
I was drawn to Wesley Hales' HTML5 and JavaScript Web Apps (O'Reilly, 2012) because it seemed right up my alley -- a book about all the latest client-I was drawn to Wesley Hales' HTML5 and JavaScript Web Apps (O'Reilly, 2012) because it seemed right up my alley -- a book about all the latest client-side technologies [1] for building enterprise grade "HTML5-based" web apps. At around 150 pages, Hales takes us on a whirlwind tour of these new technologies and tactics, taking a "Mobile First" [2] approach and working "up" from there -- though he always bringing the lessons all the way back around to apps that target mobile devices. Overall, though the style and tone is fairly colloquial, the content is pretty technical, and I would not recommend it to anyone that is not already a competent front-end developer. That being said, if you are that competent front-end developer, then you will find a lot of excellent material here that will introduce and orient you to these new technologies. [3]
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; [4] 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" [5] 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" [6] 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 [7] while the chapter on Device Orientation seemed to just barely cover the fundamentals. [8]
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:
1. Citation needed. I believe that this book could have used a reference section with citations. There were numerous times where I found myself raising a skeptical eyebrow about some point being made in the text as if it were an unequivocal fact. Example: "CSS selector performance can cripple older mobile browsers." OK. Says who? Which browsers? What kind of performance hits are we talking about here? "Stats, or it didn't happen." 2. Define your terms. There were a couple of places in the text where I found myself wondering "What do you mean by that?" This was especially true when Hales used the phrase "user experience", which he uses liberally throughout the text without ever really stating what he means by it. I have an idea of what he means, but I also know that so many people have so many different ideas of what it means that it is seldom safe to assume you know what they mean. 3. An elephant in the room. There seemed was a big question that never seemed to get resolved for me. That was the question of "progressive enhancement". Hales uses the terms "graceful degradation" and "progressive enhancement" throughout the text, but this is usually in the context of polyfills (which I got the sense he was erroneously conflating with GD/PE). Don't get me wrong, I appreciate the spirit of Hales' argument -- that you build for the latest/greatest HTML5e technologies, and polyfill your way to your supported bottom. But then in Chapter 4, he is quoting a Yahoo! source which talks about "feature phones" that "can't even run JavaScript" -- and I find myself reflecting on that point that Hales more/less opens with... The one about client-side templates. And I find myself wondering: What good is all that geolocation and WebSockety goodness if you can't even render your widgets because JavaScript is turned off?
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.
----
[1]: 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.
[2]: 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.)
[3]: It's worth pointing out that Hales is almost painfully aware of how new a lot of these technologies are. Each chapter has an embedded disclaimer of one form or another that indicates the status of the specification ("Working draft!") and any of the known quirks ("UTF-16 turns 5MB caches into 2.6MB caches!") or bugs ("JavaScript execution exceeded timeout in iOS after four minutes!") that exist in the implementations that you'll encounter out there in the wilds of Userland. It's almost like he's handing you a pair of chaps and a ten gallon hat before muttering: "There's a fortune to be made in these hills if'n you got a strong stomach."
[4]: 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.)
[5]: 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?
[6]: "HTML5e" is Hales' shorthand for "HTML5 for Enterprise". I rather took a shine to that.
[7]: 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.
[8]: 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.)...more
What I liked most about Node for Front-End Developers is the same thing that I liked most about Stoyan Stefanov's JavaScript Patterns: Means triesWhat I liked most about Node for Front-End Developers is the same thing that I liked most about Stoyan Stefanov's JavaScript Patterns: Means tries to stay as close to the bare-bones as possible, and not get too mixed up in frameworks, libraries, and modules. (That being said, after showing you how to do what does, she then uses the Connect module as a short-hand for "that".) The emphasis here is on using Node as a web application server, and for serving that content over HTTP; I'd have liked to see a bit more about using Node for command-line utilities etc., but then it wouldn't have been so short. (And I say "short" as a good thing here; I was able to read it in a day, and that is more/less exactly how this kind of intro book should go.)
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....more
Haven't read this one "straight through", but I've read enough of it (off and on) to get a decent sense of it. It reads like someone's memoirs as theyHaven't read this one "straight through", but I've read enough of it (off and on) to get a decent sense of it. It reads like someone's memoirs as they explore Git; and for that, it's valuable. But that also makes it hard to find what you're looking for sometimes. (And by that I mean that individual chapters and section headings have ... "narrative" titles, and not necessarily descriptive titles. How was I to know that "Shh... we're in a library!" was where I'd find information about submodules? And/but it was a pretty good break-down of the submodule use-case.)...more
Basically unreadable. The book opens with a kind of foreword where the author explains that this (this!) is improved re: spelling/grammar over the preBasically unreadable. The book opens with a kind of foreword where the author explains that this (this!) is improved re: spelling/grammar over the previous edition. And/but it would almost be *better* if it were rife with these kinds of errors. Instead it's just a series of gross-out moments and zombie non sequiturs....more
I picked this one up as schwag at a conference I attended/spoke at; I was pretty clearly not the audience for this book but at the same time: hey, freI picked this one up as schwag at a conference I attended/spoke at; I was pretty clearly not the audience for this book but at the same time: hey, free book. It's definitely for "absolute beginners" re "programming" [1] for the web with HTML and CSS. Which isn't to say that it isn't without its merits. On the plus side, Robson et al. introduce the box model and doctypes and selector inheritance and a bunch of other concepts that a lot of self-taught early stage web developers don't learn about until it's almost too late. On the not-so-plus side, they make liberal use of IDs for their CSS selector examples (without explaining why you generally shouldn't use them) and are a little inconsistent in the kinds of warnings they give w/r/t/ things like browser compatibility. [2] Nevertheless, I wish that I'd had this book for when I was learning all of this stuff, instead of trying to wade through Goodman... and Meyer... and Flanagan. One book with a solid foundation on the fundamentals of page flow, selectors and inheritance, positioning, etc. [3]
That being said, please don't fool yourself into thinking that you're a "web developer" when you finish this book. You'll be able to bang together some halfway decent static pages--and maybe that's totally sufficient for your needs. But this is really just a 101 course [4] in everything else that comes with the territory of being a front-end developer.
----
[1] I use "programming" in quotes here because, as any professional web developer knows, . More/less the same goes for styling with CSS. Which isn't to say that there's nothing to learn, or that there aren't difficult parts, just... get back to me after you've finished coaxing something out of O(n^2).
[2] For example: there's a multi-page treatment of the video tag and all the complications that you might face, and there are some warnings in there about "older IE" (e.g., how it doesn't handle certain text scalings in predictable ways) -- but I don't recall seeing warnings about how IE flubs the box model (esp. in quirks mode), nor how display tables aren't supported in "older IE" either.
[3] Again: not that it isn't missing some nuance etc. But it's a good place to start.
[4] And even then, it's more like... the reading you should have done in high school before getting to the 101 course? The summer selections that you need to have done before the first day of class? Something along those lines....more
Borderline four stars. What I liked about it was that he was talking about how, for all of science's rigor and effort at being systematic, it's also qBorderline four stars. What I liked about it was that he was talking about how, for all of science's rigor and effort at being systematic, it's also quite often just... stabbing in the dark. This book is really about the joy of asking questions, and how solutions and "answers" wind up being so... limiting. But I grew up around this (my dad is a scientist) and so this didn't seem as revelatory for me as I suppose it would to others. But there are some damn fine anecdotes in here....more
I put this one off for a long time, but finally read it. I'm not sure where I land on it. Finishing it, I have a vague sense of why it's important (e.I put this one off for a long time, but finally read it. I'm not sure where I land on it. Finishing it, I have a vague sense of why it's important (e.g., the satire and all) but also feel like I'm too distant from what it's satirizing. There were some truly excellent moments and passages, but I mostly did not enjoy reading it. Maybe I'm not smart enough. (More likely: not patient enough.)...more
Katie Cunningham’s Accessibility Handbook (O'Reilly, 2012) is a concise and specific introduction to accessibility (a11yreview: Accessibility Handbook
Katie Cunningham’s Accessibility Handbook (O'Reilly, 2012) is a concise and specific introduction to accessibility (a11y) and -compliance. Cunningham provides a “walking tour” of the major types of disabilities that web developers need to consider when creating a site for a11y, illustrating how people with those disabilities will use a site, and then detailing easy solutions and best practices to craft a site with the necessary accommodations. Better yet, she makes strong cases for why many of these accommodations are actually “features” and not “compromises”.
The book is broken into chapters such that each one focuses on a specific disability. Some of these disabilities may seem obvious (e.g., blindness, deafness), while others may come as a surprise (e.g., color blindess, motion disorders). Having the book sectioned in this way was a smart choice, as it becomes easy to focus on that one type of disability, and to reason about the strategies necessary for accommodating it. The goal of each chapter is to get you (as a developer) into a headspace where you can easily understand how a person with one of those disabilities will approach your site, thus making it easier for you to understand the 508-compliance rules.
As a front-end developer without much experience in the realm of a11y, and with no knowledge of 508-compliance, I approached this book as a good place to start. Having finished it, I maintain that it was a good introduction to the subject. Though I got the information about the disabilities and how to accommodate them, there was almost nothing in here about –granted: Cunningham cites ARIA, and shows some examples when talking about “Complete Blindness”, but she also says that it’s too big of a subject to cover in her book. That being said, when I find a good resource on ARIA, I’ll be pleased to know that this book gave me a decent framework for thinking about those problems.
Lastly, as I mentioned before, Cunningham does a decent job of explaining why many of the accommodations that she describes actually become “features” of your site, and not “compromises”. For example: everyone can benefit from having good tabindex properties set on your form fields. For example: everyone benefits from well-labeled graphs and charts. For example: by making your menus, icons, and other click-targets “adequately sized”, you’re not only helping someone with Parkinsons, you’re also helping people accessing your site from a mobile device. And lastly, my favorite example: by paying attention to the source order of the elements in your site, you’re not only helping the blind (and/or anyone else using a screen reader) but you’re also making it easier to give your site a responsive design (and I hear it’s helpful for SEO, as well).
Would I recommend this book? Yes, to someone who needs a quick “walking tour” of a11y–but probably not to someone who is already familiar with the subject, and definitely not to someone who is looking for more on WAI-ARIA.
Full disclosure: I received an electronic copy of the book from the publisher in exchange for writing a review....more
There's a "real" review of this book buried deep down somewhere in me. But for now:
(1) When they made that I, Robot movie with Will Smith, I thinkThere's a "real" review of this book buried deep down somewhere in me. But for now:
(1) When they made that I, Robot movie with Will Smith, I think they were trying to make this; only then they changed it into a completely different story that left out pretty much all of the things that made this book good.
(3) I would so very much recommend this book over I, Robot. It isn't that the latter is bad--it serves as a good introduction to the milieu, and/but it reads like a series of short stories (which, let's be honest, they are) which themselves are more like thought experiments. There isn't much of an over-arching narrative to really carry you through it. Meanwhile, here in Caves of Steel we have what is basically a police procedural/pulp noir-style detective story wrapped up inside of a science fiction setting, with just the tiniest dash of PKD-ish "weird" thrown in to keep you on your toes.
(3) There were a couple spots in this book where I thought: "Well, this is almost a PKD book..." But with all those "weird" twists shoved right out in front of you from the beginning, instead of snuck in there as surprises. (The equivalent of crossing PKD's street at the crosswalk? instead of jay-walking like he taunts you to?) And: BUT Asimov goes "this way" with the weird (i.e., making them prosaic as the narrative goes on) whereas PKD would have gone "that way" (i.e., with all the escalating and eldritch horrors of each reveal). I'm speaking (of course) of having a robot that looks like a human being; I'm speaking (of course) of having the whole human population of New York crammed into a giant steel dome; I'm speaking (of course) of having a conspiracy of Luddites that swarm around our narrator.
(4) The Mediaevalists: there's this theme throughout that they're basically . But I seem to recall a section where they're OK with certain other technologies, as long as those technologies allow population growth on Earth to continue unabated. It's just robots that they don't like. But they'll decry other technologies too--when it's convenient. (Am I messing this up? Please call me out on it if I am... It's totally possible I missed some small distinction in the text somewhere.)
(5) I am reminded by Manny's review of all that business with "Jezebel", and Asimov's defense of her via Baley. Manny calls this evidence of Asimov being a feminist ("somehow without ever acquiring that label"). While I don't (strongly) disagree, I still think that the language he uses to talk about women (here, and in I, Robot) still seem like a product of the time--and isn't necessarily the most positive. (I got annoyed with the scene with Jessie putting on here make-up. Feminine mystique, my ass.)
카지노싸이트.com has a community guideline that states that reviews must be about the book, and not about the author. Now, I happen to agree with the spi카지노싸이트.com has a community guideline that states that reviews must be about the book, and not about the author. Now, I happen to agree with the spirit of this guideline, but I also feel like that guideline gets a little fuzzy when you’re looking at non-fiction, and especially fuzzy when you’re talking about technical books. I mention this because this provides the appropriate frame of reference for what I’m about to say next: that I was disappointed in Addy Osmani’s Learning JavaScript Design Patterns (O'Reilly, 2012), but that most of my disappointment is because I hold him in high esteem, and as such was expecting so much more from this book. [1] What was I expecting? A deep dive into how can be (and are) applied to JavaScript development. But (and here’s where it gets weird) that’s also exactly what Osmani delivers. So why the disappointment? Because it felt like a compilation or round-up of blog posts on the subject.
In other words: it is a Greatest Hits album–if someone made a Greatest Hits album of blog posts from JavaScript pedants.
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? [2]
But I feel like these things are important. The structure of the book is important. How the information flows from one chapter to the next is important. The top-level chapter titles that you’re scanning in the table of contents are important. As I finished the book, it seemed to me that there was important information in there that was otherwise buried or obfuscated. If you didn’t know to look at sections within the chapter (or else weren’t patient enough to do so) then you might never know that there was a comprehensive discussion of namespacing patterns embedded within the discussion of jQuery plugin design; nor would you know that the “JavaScript Design Patterns” chapter was a (nearly) exhaustive walking tour through the Gang of Four’s patterns as they align with JavaScript-based software development.
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; [3] for example:
• The heading levels did not always have a clear correspondence with the level of importance for that section; [4] • The 2d object property notation on page 210 which (as it’s written) is clearly invalid JavaScript; • The multiple (multiple!) instances where (unescaped!) double-quotes are used within double-quotes–and how the syntax highlighting in the text even gives this away as a syntax error; and • Speaking of syntax highlighting, how it’s applied inconsistently throughout the electronic version of the book.
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, [5] 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. [6]
And/but I also think that for getting the maximum value out of this book, you need to be a part of the right audience. In the preface, Osmani writes that the target audience is “professional developers wishing to improve their knowledge of design patterns and how they can be applied to the JavaScript programming language” (pp. ix). He assumes that you have a good intermediate knowledge of JavaScript to begin with (“You do know what a closure is, right?”) but not necessarily that you are “advanced”, and not necessarily that you have made a formal study of computer science. [7] That being said, his statement that the book is targeted at “professional developers” seems a bit broad to me. A non-trivial proportion of the text has jQuery as its focus, [8] which leads me to conclude that the book is targeted more at front-end developers that (for better or worse) lean heavily on the jQuery for their heavy-lifting.
Putting all of this together, I believe that if I were forced to choose, I would recommend over Osmani’s JavaScript Design Patterns. Don’t get me wrong: if your bookshelf as room for both, then it’s worth it to explore both; each covers subject matter than the other does not, but in the places where they overlap, I find that Stefanov’s book rings a little bit more rigorous. Osmani’s book seems a bit more current with respect to citing specific technologies, but that also suggests to me that it will feel out-dated just a little more quickly.
(Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.)
----
[1] 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?
[2] Granted: I’ve dinged other books for not having a “concluding” chapter, and for otherwise ending abruptly while wrapping up some other subject ( 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.
[3] 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.)
[4] 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.
[5] Again: those first eight chapters really ought to have been formed up like Voltron into one.
[6] 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.
[7] Which, thank goodness for that, since so many of us front-end developers are self-taught “liberal arts majors drafted into web developer service during the dotcom boom”. (Tip o' the hat to Eric Miraglia for that quote from his foreword to .)
[8] I have mixed feelings about this part of my critique. On the one hand, jQuery is a prevalent (pervasive?) library used by a huge number of front-end developers. And for better or worse, that library is synonymous with JavaScript as a whole to many developers. That being said, it seems disingenuous to call the book “JavaScript Design Patterns” when you’re dedicating two of your most lengthy and substantial chapters to that library. Perhaps the “Get Out of Jail Free” card here is that (1a) one of those chapters is really more of a case study and (1b) that so many folks are familiar with the library makes it a good case study because it’s familiar and also (2) if that helps these lessons reach and resonate with your target audience, then that’s probably a good thing....more
An (apocryphal?) tale:[^1] when Brendan Eich unveiled the original JavaScript (nee LiveScript, nee Mocha) prototype at (then) Netscape, it was a Lisp.An (apocryphal?) tale:[^1] when Brendan Eich unveiled the original JavaScript (nee LiveScript, nee Mocha) prototype at (then) Netscape, it was a Lisp.[^2] It was only at management's insistence that the language received a C-like syntax, and even then it was mostly to have some kind of syntactic parity with Java (with which it was supposed to provide some "glue"). Now: if you think about JavaScript using this lens, then it is easy to conjure up images of as "the JavaScript that could have been".[^3]
And that is exactly what we have in Sierra and VanderHart's ClojureScript: Up and Running -- a guided quickstart to the language that JavaScript could have been. And what an interesting little language it is!
Sierra and VanderHart deliver an excellent introduction to ClojureScript, which is targeted at a sufficiently broad audience of Clojure developers, JavaScript developers, and developers of all other stripes looking to do some discovery. You don't need to know Clojure going in,[^4] but I suspect you'll want to know at least a little JavaScript. From there, they take you through installing ClojureScript, installing and working with the build tool, the core syntax, and... it goes upward from there. Just as the title suggests: there's everything that you need to get started. By the time you walk away from the book,[^5] you should be able to confidently say what ClojureScript is, what motivated its creation, and you should have enough of the basics down that you could write a trivial application with it. (Perhaps even something more "intermediate" level, if you're patient and persistent.)
Before we go any further, a few words about what the book is not:
* It is not a comprehensive language guide. * It is not a thorough introduction to Clojure. * It is not a primer on JavaScript. * It is not a nitty-gritty low-level reference.[^6]
Now, for as easy as it is to recommend ClojureScript: Up and Running, I did find myself with a few critiques.
First, as someone who likes JavaScript and enjoys writing it, there are some borderline inflammatory statements in here. There's the line about having a "cleaner syntax"; and we all know the volumes-upon-volumes of blog posts, forum threads, and flame wars that are already out there about statements like this one. Then there's that line about how "JSON is a feeble data format"; and I find myself thinking I've never felt limited by JSON... These statements read like trolling, and they distract a bit from the salient points being made. (See also: "Stop taking these things so personally.")
However, this leads me to my second critique: that (again: as someone who lives and breathes JavaScript) the ClojureScript way is not always the JavaScript way, and this seems to be taken for granted in the text. (As an aside: this is perhaps a critique more of ClojureScript than it is of the book.) There is some discussion in the text about how to "marry" these discrepancies, but as ClojureScript is "more strict", and as ClojureScript is the compiler... it's the one that "wins" when there is a disagreement. Granted, having gotten through the book, and having grasped the motivation behind the language, I also understand why things resolve in this way -- and in light of the idea that "ClojureScript is the JavaScript that could have been", it's almost nice to see things resolve this way but... To a self-identifying JavaScript professional, some of this can be a little off-putting.[^7]
And my last critique: for an introduction, they sometimes drift into almost-but-not-quite esoteric territory without adding sufficient context. Example: "In JavaScript, strings are often used for constants or identifiers in code; keywords fill the same role in ClojureScript." I read these words, and I understand them. And I believe that I understand the concepts. But I do not believe that I could explain this to someone else. I could not explain why it is important; I am missing some bit of experience or context to bring it fully into focus. There are a handful of these in the book (maybe a half-dozen or so?) but I made a note of them every time: "Come back to this passage after you've seen it in the real world."
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]
[^1]: The best source I could come up with to back up my point was on Dr. Axel Rauschmayer’s blog. But how much source material do you really need for fun little bits of apocrypha anyway?
[^2]: Or at the very least, it was “Lisp-like”.
[^3]: I wonder: if JavaScript had been a Lisp all along, would we be having the whole conversation at all?
[^4]: Though it might help to have done a couple of the .
[^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.
[^6]: That being said, I really felt like the book could have used an appendix or a quick reference for some of those core language features. Not every book out there needs to be Flanagan’s JavaScript The Definitive Guide (with its hundreds of pages of appendices and dictionaries and references…) – but it’s helpful to get a bookmarkable section like that. (Hmm… what does disj do again…?)
[^7]: Especially when you’re going to call an object (i.e., {}) an “associative array”. That’s a dangerous word in JavaScript land. (I’ve heard them called “objects” and “maps” and “hashes”, but there’s no such thing as an “associative array”.)
[^8]: I wasn’t sure how else to fit in this point, so I’m going to jam it in with this footnote: the real coup in this book, the real “magical moment” was when I got to their discussion of how ClojureScript uses as a way of deliberately and purposefully dealing with JavaScript’s otherwise clumsy notion of state as mediated through its global scope. It was like some bright light shone down from the sky and paved the road to enlightenment with parens. That alone is worth the price of admission.
----
Disclosure: I received an electronic copy I the book in exchange for writing a review....more
Although I run the risk of fawning all over this book here, Jan Goyvaerts and Steven Levithan's Regular Expressions Cookbook (Second Edition) (O'ReillAlthough I run the risk of fawning all over this book here, Jan Goyvaerts and Steven Levithan's Regular Expressions Cookbook (Second Edition) (O'Reilly, 2012) is a technical text that I will gladly describe using words like "essential" and "indispensable" and "invaluable". It should be on every working programmer's bookshelf, if not on her desk. It is exhaustive and rigorous, covering the major regex flavors across eight popular/widespread general purpose languages. [1] If your work brings you in regular contact with regular expressions, then you need easy access to this book.
To begin with, Goyvaerts and Levithan present an in-depth discussion of each regex feature, starting with the very basics (e.g., making matches against literal expressions) and working up into some pretty sophisticated topics (e.g., writing parsers). True to the title, their approach is a "cookbook" style: a general problem is stated, a solution is presented (or multiple solutions, if that's what it takes), and then they go into an almost painful (but neatly sectioned) level of detail about the solution, describing it token-for-token in some cases. Now, by "neatly sectioned" I mean that their discussion of each solution is broken down by language [2] wherein they are careful to point out flavor- and/or language-specific nuances, quirks, bugs, and/or unique features. They are very careful about this part--if a particular feature does not work in a language (e.g., how JavaScript lacks named capturing groups) then they show you how to work around that deficiency; but perhaps more importantly, if a feature is unique to a language, they point it out as such and caution you against using them (i.e., to keep your regexes general and portable). [3]
Later chapters (i.e., 4 through 9) look at more specific problems--e.g., performing validation on email addresses, [4] dealing with Roman numerals, combing for text in the Apache Common Log Format, or parsing URLs. The recipes are all cross-referenced with each other, so if a particular solution really only solves about 75% of your problem, they're prepared to point you in the right direction. They get right to the point, and then tell you where to go for more. What else can be said about these chapters except that they're like the magnificent arsenal you'll be wishing for when the text zombies swarm at your gate.
All of this makes the Regular Expressions Cookbook very skimmable. It is easy to pick it up, find the particular recipe that is going to help you out of a jam, and power through with that solution in hand. Do you "just" need a quick JavaScript solution? Done. Curious how it might compare to the solution in Java or Ruby? No problem. You skim the surface, or you can go as deep as you need [5] on some very narrow and specific sub-sub-subject within the corpus of regular expressions knowledge. (That being said, take their advice and be sure to read the first three chapters so that you are properly equipped for those deep dives later on.)
As I said before, if your work regularly brings you in contact with regular expressions, you'll want to arm yourself with this. Highly recommended.
---
[1] Goyvaerts and Levithan define the regex flavors as: .NET, Java, JavaScript, PCRE, Perl, Python, and Ruby; the specific languages covered include: C#, Java, JavaScript (and Levithan's XRegExp library), PHP, Perl, Python, Ruby, and VB.NET. They also have a list in chapter 3 of 11 other languages which--while not specifically covered--are applicable because they adhere to one of the flavors.
[2] I should add "where appropriate" here, and note that the per-language sections in each discussion are much more common in the early chapters (2 and 3, with a pretty sharp drop-off starting in 4). This is because they're covering the fundamentals, and there's a lot more in the way of quirks and nuances to tread lightly around at this point.
[3] In other words: they remind you not to get too clever. "Sure you could do that as a one-liner... but no one's going to know what that means next week. Not even you."
[4] Which, validating an email address is not as easy as it sounds.
[5] Or as deep as you want, if you're in to that sort of thing.
---
Full disclosure: I received an electronic copy from the publisher in exchange for writing a review....more
I did copy editing on this book, so my review is of an unfinished (but close to finished) version. That being said: McKinney is the principal author oI did copy editing on this book, so my review is of an unfinished (but close to finished) version. That being said: McKinney is the principal author on pandas, a Python package for doing data transformation and statistical analysis. The book is largely about pandas (and NumPy), but also delves into general methodologies for munging data and performing analytical operations on them (e.g., normalizing messy data and turning it into graphs and tables); he also delves into some (semi) esoteric information about how Python works at very low levels, and discusses ways to optimize data structures so that you can get maximum performance from your programs. This book won't be useful for someone looking for a book that discusses data analysis in a broad sense, nor would it be useful for someone looking for a generalist's book on Python -- however if you've already selected Python as your analytical tool (and it sounds like it's more/less the de facto analytical tool in many circles) then this could be just the book for you....more
Loading...
