|
|
|
|
|
|
|
|
|
|
|
|
|
|
my rating |
|
|
|
|
|
|
|
|
|
|
||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1449320511
| 9781449320515
| 1449320511
| 3.22
| 40
| Jan 01, 2012
| Dec 18, 2012
|
liked it
|
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 |
Notes are private!
|
1
|
Nov 21, 2012
|
Nov 24, 2012
|
Nov 21, 2012
|
Paperback
| ||||||||||||||
| 1449318835
| 9781449318833
| 1449318835
| 3.06
| 47
| Jan 01, 2012
| Jan 2012
|
liked it
|
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 tries
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 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 |
Notes are private!
|
1
|
Nov 20, 2012
|
Nov 20, 2012
|
Nov 20, 2012
|
Paperback
| ||||||||||||||
| B0DTS5QYDN
| 3.83
| 537
| Jul 17, 2011
| May 01, 2012
|
it was ok
|
카지노싸이트.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 |
Notes are private!
|
1
|
Sep 07, 2012
|
Sep 15, 2012
|
Sep 07, 2012
|
ebook
| ||||||||||||||||
| 1449327435
| 9781449327439
| 1449327435
| 3.27
| 107
| Aug 22, 2012
| Dec 04, 2012
|
really liked it
|
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] Companion reading: * Clojure Programming (Chas Emerick, et al.) * The Joy of Clojure (Fogus & Houser) * Closure The Definitive Guide (Bolin) ---- [^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 |
Notes are private!
|
1
|
Dec 13, 2012
|
Dec 16, 2012
|
Sep 04, 2012
|
Paperback
| ||||||||||||||
| 1449322131
| 9781449322137
| 1449322131
| 3.16
| 25
| Apr 22, 2012
| Jul 03, 2012
|
liked it
|
short version: A good and pretty in-depth overview of the emerging Web Worker standard. But "in-depth" here fits into about 50 pages because the API d
short version: A good and pretty in-depth overview of the emerging Web Worker standard. But "in-depth" here fits into about 50 pages because the API design is so simple. I could have seen this as tightened up and folded into Nicholas Zakas'
Professional JavaScript for Web Developers
as a chapter. --- long version: --- Ido Green's Web Workers: Multithreaded Programs in JavaScript (O'Reilly, 2012) is a dive into the emerging API of Web Workers. It's a short book--at 46 pages, it may as well be a chapter from another technical book--but it's free of fluff, and laser focused on one topic, and one topic only. But this is just fine; we're only here to learn about Web Workers, after all. Now, I don't want to give away the ending, but Web Workers are actually pretty simple to use. [1] 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 , 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. --- [1] Provided you're in a browser that supports them. ...more |
Notes are private!
|
1
|
Jul 03, 2012
|
Jul 08, 2012
|
Jul 02, 2012
|
Paperback
| ||||||||||||||
| 1449327680
| 9781449327682
| 1449327680
| 3.89
| 290
| Jan 01, 2012
| Jul 03, 2012
|
liked it
|
Maintainable JavaScript by Nicholas Zakas (O'Reilly 2012) is a short-and-sweet little text on (as the cover says) "writing readable code". And by "rea
Maintainable JavaScript by Nicholas Zakas (O'Reilly 2012) is a short-and-sweet little text on (as the cover says) "writing readable code". And by "readable code", Zakas means "code that other developers not named [YOUR NAME] will be able to read and make sense of and ultimately maintain". It goes beyond maintainable and readable code though--Zakas takes us on a tour of how to deliver high-quality JavaScript that is testable and maximally performant in production. If you look at Zakas' catalog, this subject is right in his wheelhouse, and the book reads like either a sequel to his 2010 [title: High Performance JavaScript] or else as Right off the bat: the target audience for this book is not advanced JavaScript developers. If you are an advanced JavaScript developer (or even many mid-level JS devs) then these are concepts that you are already familiar with. You've already dabbled in a style guide. You already know to minimize global variables. You already know to use feature detection. And there's a good chance you're at least linting, if not testing, if not doing both of those things automatically as part of your build. If that sounds like you, then you might want to take a pass. But before you do, give the table of contents a second glance. (If nothing else, you'll feel really validated.) So who is it for? It's for novice and intermediate level JavaScript developers that want to get a better sense of what "readable" and "maintainable" code looks like. It's for folks that are plowing through the other "slim" JavaScript books in the O'Reilly catalog. [1] It's for technical managers who don't have a JavaScript background. It's for folks that want to start a book club for front-end devs and have spirited debates about ASI and how many spaces to indent when an expression continues on the next line. As I worked through Part I ("Style Guidelines"), my initial impression was that Zakas was writing a how-to for writing JavaScript style guides. We have 44 pages of in-depth discussion on where to put curly braces, how many blank lines to use (and where), and what a proper comment looks like. Esoteric rationales to inform what (on the surface) seem like so much pedestrian banalia. ("Who cares what I name my local variables?") But by the end, there is a well-reasoned case made for all of the recommendations that will go on to appear in Appendix A. 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, [2] 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 .) The chapters in the Automation section were my favorites. Zakas builds up a solid Ant-based [3] 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 [4] and testing. [5] [6] All in all? I would strongly recommend this to folks that are new to JavaScript, but only a mild nudge to seasoned folks. ------ [1] And by "the slim JavaScript books", I mean: Crockford's JavaScript: The Good Parts , Stefanov's JavaScript Patterns , and Zakas' High Performance JavaScript . [2] Especially if you've been keeping up with Zakas' blog posts. , anyone? [3] Although, honestly, my first thought was: "Really? Ant?" [4] 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. [5] 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. [6] Also: Zakas implies that you need to run JavaScript tests in the browser and I just don't believe that to be so. If you're working with the DOM or BOM objects, then yes: he's right. But if you're otherwise following functional programming patterns, and have clearly defined arguments and returns, and you're avoid side-effects in your code... Well, you should be able to unit-test stuff like that without a full-blown browser at your beck and call. ------ Disclosure: I got a free copy from O'Reilly in exchange for writing a review as part of their blogger/reviewer program... ...more |
Notes are private!
|
1
|
May 20, 2012
|
May 23, 2012
|
May 20, 2012
|
Paperback
| ||||||||||||||
| 1449316999
| 9781449316990
| 1449316999
| 3.25
| 16
| Mar 09, 2012
| Apr 24, 2012
|
it was ok
|
Eric Sarrion's jQuery UI (published by O'Reilly) is a beginner-to-intermediate level overview of the library and its widgets. [1] Sarrion wa
Eric Sarrion's jQuery UI (published by O'Reilly) is a beginner-to-intermediate level overview of the library and its widgets. [1] 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. If you are a JavaScript novice, or else are new to jQuery or its UI library, then Sarrion's book is good for getting up and running fast. Each chapter is reasonably self-contained--e.g., if you just need to learn the ins and outs of the jQuery UI dialog(), then you can blow through chapter 4 in about 15 minutes and pick up enough to create a reasonably sophisticated modal dialog. Each chapter includes a series of tables that provide a quick reference for each method/widget's available options, methods, and events. Further, the example code at the end of each chapter is a valuable way to get some ideas about how to put each widget into action. [2] These explanations and examples are easier to digest than the documentation [3] and examples that are otherwise available in the . That being said, if you are a web development professional with sophisticated JavaScript knowledge, you may find yourself grinding your teeth all over the place here. And that's not just because we're talking about an elementary introduction to a popular UI widget library with an almost brain-dead-simple API. It's because--as they say--the devil is in the details, and boy are there some cringe-worthy details: » 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. » Non-idiomatic JavaScript. Everyone has their own style, I get that. But there are some things that are just... strange when you see them. Sarrion apparently likes to put a space between the method name and the parens when invoking a function. I have never seen code like that before and had to go and look it up. Can you even do that? [4] Opening curly braces on a new line, that's one thing [5], but a space between the name and invoking parens on every page was enough to make me want to scream. » Non-idiomatic and arguably dangerous JavaScript. Beyond "everyone has their own style", we get into the area where you have valid code that is otherwise not really good code because its known to be error-prone code. I am talking (of course?) about single line if statements [6], == comparisons, browser detection [7], and other minor transgressions. I take issue with these mainly because of what I perceive to be the audience: if the book is targeted toward beginner and intermediate level devs, then we have a responsibility to set a good example. » Confusing details in the tables. I have a bit of a bone to pick with whomever was responsible for getting these tables together. First: the second (explanatory) column in most tables in more chapters had the heading "Function". Granted, it is easy to figure out from the context that "Function" here means "intended purpose of the thing listed in the left column"--but this is a book on JavaScript and as such, it pays to be careful with that word; that word means something specific. Second: (and this is probably a more egregious error) don't split function names. This may very well have been an accident, and looking back, I only see the one but... when the method name is getDate, don't let it break onto two lines like that. [8] The laundry list of quibbles aside, my two big disappointments were as follows: First: I was hoping for some more sophisticated coverage of the jQuery UI library. In a lot of ways, the text is just a re-hash and/or expansion on the jQuery UI documentation. This is fine for JavaScript novices, or else for folks that just want to get up and running with the library quickly [9] and don't care about a deep dive or its inner-workings. Second: I was also looking for more in the way of plugin development. jQuery UI is already a pretty feature-rich library, but there are always places where you can expand on it, or else create your own purpose-built widgets for your apps. There is no real discussion here of the library's idioms or patterns, nor of how to approach extending the library or writing plugins or widgets around it. [10] Again, if you're a JavaScript lightweight and are just looking to get going quickly with jQuery UI--then this book could be super helpful for you. If you're a bit more sophisticated... borrow your neighbor's copy in a pinch, but don't get your hopes up beyond what you'd otherwise be able to look up online. --- [1] 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. [2] Though I was disappointed that there was no associated Github repo. [3] 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. [4] Turns out that you can. But: !?!?!? [5] A thing I don't like, but whatever. [6] Doubly dangerous because they're missing their curly braces. [7] As opposed to feature detection. [8] Table 8-9, I'm looking in your direction. [9] 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. [10] 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. ...more |
Notes are private!
|
1
|
Mar 30, 2012
|
Apr 09, 2012
|
Mar 30, 2012
|
Paperback
| ||||||||||||||
| 9781593275846
| 1593275846
| 4.14
| 3,182
| Nov 15, 2010
| Nov 2014
|
really liked it
|
A great introduction to JavaScript as a language, and a good introduction to computer science/software engineering more generally. Haverbeke makes no
A great introduction to JavaScript as a language, and a good introduction to computer science/software engineering more generally. Haverbeke makes no assumptions about what you know coming into the book, which is helpful inasmuch as it makes it accessible; but he also isn't patronizing like some "intro" books can be, meaning that if you are already familiar with some of this stuff, you're likely to learn something new. (Or at least find some pleasant challenges in some of the though exercises that he puts forth.) The material gets pretty challenging toward the end (like you'd hope) but (1) Haverbeke trusts you to do the work to learn enough to get through it and (2) he does throw you a bone on some of the problems with a little appendix to help you work through some of those challenges. FULL DISCLOSURE: a did receive a free copy of this book as a "thank you" gift for some other work I did on behalf of this publisher. ...more |
Notes are private!
|
1
|
Dec 16, 2014
|
Mar 16, 2015
|
Jan 11, 2011
|
Paperback
| |||||||||||||||
| 0596806752
| 9780596806750
| 0596806752
| 4.17
| 1,630
| Sep 01, 2010
| Oct 26, 2010
|
really liked it
|
If you're a JavaScript developer, you would be wise to have this on your bookshelf--nestled nicely between
JavaScript: The Good Parts
and
High
If you're a JavaScript developer, you would be wise to have this on your bookshelf--nestled nicely between
JavaScript: The Good Parts
and
High Performance JavaScript
. The three make a nice little troika. And read them in that order: The Good Parts, Patterns, and then High Performance. Here's why: What Stefanov gives us with this book is effectively an overview [†] of best practices for JavaScript development, going over the benefits and gotchas of certain important language features, and translating those into design and implementation patterns. Many of these patterns are language-agnostic--and you're likely to recognize them from "The Gang of Four"--but Stefanov puts them in their JavaScript party dresses and takes them out to the ball. Wisely, Stefanov also presents these patterns in an environment/host-independent fashion, so the lessons you learn about encapsulation or inheritance or performance should be equally valid regardless of whether you're coding for the browser [‡] or NodeJS or some image exporting automation for Adobe Illustrator. Stefanov is also a lucid and concise author, clearly illustrating his points about these design patterns; the text is accessible--easy to follow and digest--and he is careful to clearly define words and terms that might be ambiguous or commonly misunderstood (e.g., "function expression" vs. "function declaration" vs. "function literal"). JavaScript patterns makes a great transition guide for intermediate developers--the men and women who have stopped confusing jQuery-the-library with JavaScript-the-language--the folks who are ready to re-evaluate their approach software development with JavaScript. This is for the folks that made it through Crockford's The Good Parts knowing that they learned something but also feeling less-than-certain about how to apply that something. This is the follow-on; JavaScript Patterns is the application of those lessons. And then after you've written your clean, maintainable, scalable applications--then you make the jump to Zakas' High Performance JavaScript to tune things just a little bit further. 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: (1) Relative to The Good Parts and High Performance, JavaScript Patterns was not published in the order that I recommend reading them. As a consequence, since I'd read the others (and quite a few others above and beyond those two), there is quite a bit of information in there that I'd seen before. This is not a Bad Thing; sometimes it pays to see information presented again--to help it sink in or else to gain another perspective on it. And in some cases Stefanov offers an as-good-or-better explanation on certain topics/techniques as others writing in the field (e.g., his examples for memoization and currying rival Crockford's, and his explanation of the pub/sub pattern (and custom event design) is more concise than the one Zakas presents in Professional JavaScript for Web Developers ). Sometimes (and I've written this before) you were just hoping for... just a little bit more. (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. ...more |
Notes are private!
|
1
|
Oct 25, 2010
|
Dec 05, 2010
|
Oct 25, 2010
|
Paperback
| ||||||||||||||
| 059680279X
| 9780596802790
| 059680279X
| 4.11
| 596
| 2010
| Apr 13, 2010
|
it was amazing
|
While reading Nicholas Zakas' High Performance JavaScript, it occurred to me that there were actually two different reviews that I wanted to write. So
While reading Nicholas Zakas' High Performance JavaScript, it occurred to me that there were actually two different reviews that I wanted to write. So, rather than try to reconcile them into one review, I'll simply apply them here as an ordered list. (1) To continue with the JavaScript University metaphor (from my review of Zakas' Professional JavaScript for Web Developers ): Finals are coming up in Prof. Crockford's upper-division JavaScript class. You've been a diligent student all semester and although you're not failing, it always seems like you're somewhere in the middle of the pack. You want desperately to ace the final exam, so you reach out for some help. Zakas (the graduate student/teaching assistant for the class) offers to show you the thesis he is working on. Then It hits you like a bolt from the blue -- every bit of it resonates with you. "It's so simple! so clear!" you exclaim. The inner machinations of the language snap together in a way that makes it all feel new and exciting -- the possibilities are boundless! You go back over your notes. You were close -- oh so close -- the whole time. But the last little bits drop in. A refinement here, a re-factor there... and the next thing you know, things are blazing. Your pages load 60% faster, execution time is down an average of 40%. You're amazed at yourself. And when the grades for the final exam come back, you're pleased to see that you aced it (aside from that little Oops on scoping closures -- but you try to think of that as a conscious trade-off). Prof. Crockford is pleased (if a little disappointed that it took you this long to Get It) and you're the envy of your peers. At least until next semester's RegEx class with Prof. Levithan. [ Rated: ★★★★★ ] (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: ★★★★ ] ...more |
Notes are private!
|
1
|
Apr 07, 2010
|
Apr 12, 2010
|
Apr 07, 2010
|
Paperback
| ||||||||||||||
| 047022780X
| 9780470227800
| 047022780X
| 4.19
| 615
| Apr 15, 2005
| Jan 14, 2009
|
it was amazing
|
This book should have been sub-titled: JavaScript The Good Parts (the long version) While I was reading this, I liked to imagine that I was at universi This book should have been sub-titled: JavaScript The Good Parts (the long version) 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. (read the rest ) ...more |
Notes are private!
|
1
|
Jan 13, 2010
|
Feb 05, 2010
|
Jan 13, 2010
|
Paperback
| ||||||||||||||
| 1847195148
| 9781847195142
| 1847195148
| 3.04
| 23
| Nov 28, 2008
| Nov 28, 2008
|
None
|
Notes are private!
|
0
|
not set
|
not set
|
Dec 24, 2008
|
Paperback
| |||||||||||||||
| 0596517742
| 9780596517748
| 0596517742
| 4.23
| 8,650
| Jan 01, 2008
| May 01, 2008
|
really liked it
|
"There is danger and misery at the edges." As the title implies, Douglas Crockford takes a subset of JavaScript, identifies it as "the good parts" and "There is danger and misery at the edges." As the title implies, Douglas Crockford takes a subset of JavaScript, identifies it as "the good parts" and proceeds to explain why these parts are good (and should therefore be used). Crockford commends JavaScript for being a very expressive language but is also honest about the failings of individual parts (e.g., how arrays aren't really arrays but are in fact "array-like objects") and proposes some genuine solutions for them that do not involve abandoning the language all together[†:]. Crockford gives a good overview of JavaScript's grammar without attempting to be exhaustive. He assumes that you are already at least familiar with JavaScript (which is why you would be interested in knowing "just the good parts", presumably) and there is an underlying assumption that you have experience with at least one other language (probably a "C-like" language). 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. --- † = Which is, of course, fortunate because you have no choice but to use JavaScript when creating applications for the web. (And don't give me that bullshit about using Flash because that's a very narrow view of the web.) ‡ = 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.) ...more |
Notes are private!
|
2
|
Apr 2010
not set
|
Apr 04, 2010
Oct 22, 2008
|
Sep 24, 2008
|
Paperback
| ||||||||||||||
| 0596805527
| 9780596805524
| 0596805527
| 4.07
| 3,375
| 1996
| May 10, 2011
|
really liked it
|
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
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 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 ---- I continue to hold this book in high esteem, and the Sixth Edition is a huge improvement over the old edition that I had. You can tell that Flanagan put a lot of thoughtful work into the re-write. If asked to choose between this and Zakas' Professional JavaScript for Web Developers (3rd Ed.)... I don't know if I could. Both of them are thorough, both of them are comprehensive... Zakas can be easier to digest, I think; but Flanagan also offers this really nice API reference guide in the bottom half of the book. Toss up... There's much to appreciate here, and almost every JavaScript question you might have has an answer between these covers. ...more |
Notes are private!
|
3
|
Oct 23, 2012
not set
not set
|
Nov 19, 2012
Jan 2009
not set
|
Aug 19, 2007
|
Paperback
|
|
|
|
|
|
|
my rating |
|
|
|---|---|---|---|---|---|---|---|
|
| 3.22
|
liked it
|
Nov 24, 2012
|
Nov 21, 2012
|
|||
|
| 3.06
|
liked it
|
Nov 20, 2012
|
Nov 20, 2012
|
|||
|
| 3.83
|
it was ok
|
Sep 15, 2012
|
Sep 07, 2012
|
|||
|
| 3.27
|
really liked it
|
Dec 16, 2012
|
Sep 04, 2012
|
|||
|
| 3.16
|
liked it
|
Jul 08, 2012
|
Jul 02, 2012
|
|||
|
| 3.89
|
liked it
|
May 23, 2012
|
May 20, 2012
|
|||
|
| 3.25
|
it was ok
|
Apr 09, 2012
|
Mar 30, 2012
|
|||
|
| 4.14
|
really liked it
|
Mar 16, 2015
|
Jan 11, 2011
|
|||
|
| 4.17
|
really liked it
|
Dec 05, 2010
|
Oct 25, 2010
|
|||
|
| 4.11
|
it was amazing
|
Apr 12, 2010
|
Apr 07, 2010
|
|||
|
| 4.19
|
it was amazing
|
Feb 05, 2010
|
Jan 13, 2010
|
|||
|
| 3.04
|
not set
|
Dec 24, 2008
|
||||
|
| 4.23
|
really liked it
|
Apr 04, 2010
Oct 22, 2008
|
Sep 24, 2008
|
|||
|
| 4.07
|
really liked it
|
Nov 19, 2012
Jan 2009
not set
|
Aug 19, 2007
|
Loading...