Rob's bookshelf: javascript

Rob's bookshelf: javascript en-US Wed, 24 Jul 2024 07:35:33 -0700 60 Rob's bookshelf: javascript 144 41 /images/layout/goodreads_logo_144.jpg <![CDATA[TypeScript Cookbook: Real World Type-Level Programming]]> 142415226 419 Stefan Baumgartner 1098136659 Rob 4 2024, javascript, technical 4.19

TypeScript Cookbook: Real World Type-Level Programming

author: Stefan Baumgartner
name: Rob
average rating: 4.19
book published:
rating: 4
read at: 2024/07/24
date added: 2024/07/24
shelves: 2024, javascript, technical
review:

]]> <![CDATA[Principles of Object-Oriented Programming in JavaScript]]> 17155916 In The Principles of Object-Oriented JavaScript, Nicholas C. Zakas thoroughly explores JavaScript's object-oriented nature, revealing the language's unique implementation of inheritance and other key characteristics. You'll learn:

The difference between primitive and reference values
What makes JavaScript functions so unique
The various ways to create objects
How to define your own constructors
How to work with and understand prototypes
Inheritance patterns for types and objects

The Principles of Object-Oriented JavaScript will leave even experienced developers with a deeper understanding of JavaScript. Unlock the secrets behind how objects work in JavaScript so you can write clearer, more flexible, and more efficient code.]]> 91 Nicholas C. Zakas Rob 4 2012, javascript, technical Nicholas 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.

Good stuff.]]> 4.43 2012 Principles of Object-Oriented Programming in JavaScript

Principles of Object-Oriented Programming in JavaScript

author: Nicholas C. Zakas
name: Rob
average rating: 4.43
book published: 2012
rating: 4
read at: 2012/12/18
date added: 2023/03/17
shelves: 2012, javascript, technical
review:
Nicholas 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.

Good stuff.
]]> JavaScript: The Good Parts 2998152 153 Douglas Crockford 0596517742 Rob 4 "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 "". 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.)]]> 4.23 2008 JavaScript: The Good Parts

author: Douglas Crockford
name: Rob
average rating: 4.23
book published: 2008
rating: 4
read at: 2010/04/04
date added: 2023/03/16
shelves: technical, 2008, on-going, javascript, always-on-my-desk, 2010
review:
"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 "". 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.)
]]> <![CDATA[JavaScript: The Definitive Guide]]> 8143605 JavaScript: The Definitive Guide has been the bible for JavaScript programmers—a programmer's guide and comprehensive reference to the core language and to the client-side JavaScript APIs defined by web browsers. The 6th edition covers HTML5 and ECMAScript 5, with new chapters on jQuery and server side JavaScript. It's recommended for experienced programmers who want to learn the programming language of the Web, and for current JavaScript programmers who want to master it.]]> 1093 David Flanagan 0596805527 Rob 4
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 ... 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.]]> 4.08 1996 JavaScript: The Definitive Guide

author: David Flanagan
name: Rob
average rating: 4.08
book published: 1996
rating: 4
read at: 2012/11/19
date added: 2023/03/14
shelves: technical, 2009, on-going, javascript, always-on-my-desk, 2012
review:
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 ... 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.
]]> <![CDATA[Professional JavaScript for Web Developers]]> 6133658 840 Nicholas C. Zakas 047022780X Rob 5 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 )]]> 3.82 2005 Professional JavaScript for Web Developers

Professional JavaScript for Web Developers

author: Nicholas C. Zakas
name: Rob
average rating: 3.82
book published: 2005
rating: 5
read at: 2010/02/05
date added: 2023/03/14
shelves: javascript, technical, 2010, always-on-my-desk, on-going, 2011
review:
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 )
]]> PhantomJS Cookbook 22548529 304 Rob Friesel 178398192X Rob 5 4.38 2014

author: Rob Friesel
name: Rob
average rating: 4.38
book published: 2014
rating: 5
read at: 2014/01/01
date added: 2023/03/14
shelves: wrote-it, 2014, javascript, technical
review:

]]> <![CDATA[High Performance JavaScript: Build Faster Web Application Interfaces]]> 7008656

If you're like most developers, you rely heavily on JavaScript to build interactive and quick-responding web applications. The problem is that all of those lines of JavaScript code can slow down your apps. This book reveals techniques and strategies to help you eliminate performance bottlenecks during development. You'll learn how to improve execution time, downloading, interaction with the DOM, page life cycle, and more.

Yahoo! frontend engineer Nicholas C. Zakas and five other JavaScript experts -- Ross Harmes, Julien Lecomte, Steven Levithan, Stoyan Stefanov, and Matt Sweeney -- demonstrate optimal ways to load code onto a page, and offer programming tips to help your JavaScript run as efficiently and quickly as possible. You'll learn the best practices to build and deploy your files to a production environment, and tools that can help you find problems once your site goes live.

Identify problem code and use faster alternatives to accomplish the same task Improve scripts by learning how JavaScript stores and accesses data Implement JavaScript code so that it doesn't slow down interaction with the DOM Use optimization techniques to improve runtime performance Learn ways to ensure the UI is responsive at all times Achieve faster client-server communication Use a build system to minify files, and HTTP compression to deliver them to the browser ]]> 232 Nicholas C. Zakas 059680279X Rob 5 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' ): Finals are coming up in . 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: ★★★★ ]]]> 4.10 2010 High Performance JavaScript: Build Faster Web Application Interfaces

High Performance JavaScript: Build Faster Web Application Interfaces

author: Nicholas C. Zakas
name: Rob
average rating: 4.10
book published: 2010
rating: 5
read at: 2010/04/12
date added: 2023/03/14
shelves: javascript, always-on-my-desk, 2010
review:
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' ): Finals are coming up in . 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: ★★★★ ]
]]> Learning Ext JS 6023341 Learning Ext JS 299 Shea Frederick 1847195148 Rob 0 3.05 2008

author: Shea Frederick
name: Rob
average rating: 3.05
book published: 2008
rating: 0
read at:
date added: 2023/03/14
shelves: technical, abandoned, javascript, 2009
review:

]]> Pro React 16 43506094 What You’ll Learn
Who This Book Is For
JavaScript developers who want to use React to create dynamic client-side applications]]> 768 Adam Freeman 1484244508 Rob 3 2020, javascript, technical
• common patterns that show up in React applications
• pitfalls and anti-patterns to avoid
• companion packages (e.g., Redux, React Router)
• integrating with other common technologies (e.g., REST APIs, GraphQL)

Coverage of testing patterns seemed light to me, and I'd have liked to see the introduction to the topic earlier, and then sprinkled throughout -- but that is a personal nit-pick.

If you're already a competent developer with JavaScript, this book can help you get up and running with React and its surrounding ecosystem. Would recommend.]]> 4.14 Pro React 16

author: Adam Freeman
name: Rob
average rating: 4.14
book published:
rating: 3
read at: 2020/06/02
date added: 2022/01/27
shelves: 2020, javascript, technical
review:
Like with most of these kinds of technical books, you'll get more out of it if you're following along with the exercises -- either explicitly, or (maybe more so?) by applying the discussions to your own projects. Freeman does a good job of discussing React, but it's important to know that React's actual footprint is pretty small, and so most of the discussion is more accurately about:

• common patterns that show up in React applications
• pitfalls and anti-patterns to avoid
• companion packages (e.g., Redux, React Router)
• integrating with other common technologies (e.g., REST APIs, GraphQL)

Coverage of testing patterns seemed light to me, and I'd have liked to see the introduction to the topic earlier, and then sprinkled throughout -- but that is a personal nit-pick.

If you're already a competent developer with JavaScript, this book can help you get up and running with React and its surrounding ecosystem. Would recommend.
]]> <![CDATA[Understanding JavaScript Promises - Community Edition]]> 60180263 when to use them. All new asynchronous JavaScript APIs will be built with promises going forward,
and so promises are a central concept to understanding JavaScript as a whole. My hope is that this
book will give you the information you need to successfully use promises in your projects.]]> Nicholas C. Zakas Rob 4 2022, javascript, technical 4.53 Understanding JavaScript Promises - Community Edition

Understanding JavaScript Promises - Community Edition

author: Nicholas C. Zakas
name: Rob
average rating: 4.53
book published:
rating: 4
read at: 2022/01/06
date added: 2022/01/26
shelves: 2022, javascript, technical
review:

]]> <![CDATA[Effective Typescript: 62 Specific Ways to Improve Your TypeScript]]> 50204687
Author Dan Vanderkam, a principal software engineer at Sidewalk Labs, shows you how to apply these ideas, following the format popularized by Effective C++ and Effective Java (both from Addison-Wesley). You’ll advance from a beginning or intermediate user familiar with the basics to an advanced user who knows how to use the language well.

Effective TypeScript is divided into eight chapters:

Getting to Know TypeScript
TypeScript’s Type System
Type Inference
Type Design
Working with any
Types Declarations and @types
Writing and Running Your Code
Migrating to TypeScript]]> 250 Dan Vanderkam 1492053740 Rob 4 2020, javascript, technical
This book helped me better frame my thinking around the so-called “type space” vs. the runtime code, as well as how to best consider TS’s structural typing as a good fit for JS’s notoriously loose types.

There are still some places where I scribbled “looks like more trouble than it’s worth” in the margins (but not too many) and I STILL have some work to do to get fluent in generics… BUT I would recommend this to anyone that has either (1) been working in TypeScript for 6+ months, and/or (2) who is coming I to TypeScript with a proficiency in JavaScript (looking at you, Dreyfus skill model).]]> 4.36 2019 Effective Typescript: 62 Specific Ways to Improve Your TypeScript

Effective Typescript: 62 Specific Ways to Improve Your TypeScript

author: Dan Vanderkam
name: Rob
average rating: 4.36
book published: 2019
rating: 4
read at: 2020/10/13
date added: 2020/10/13
shelves: 2020, javascript, technical
review:
As a long-time JavaScript developer, but as someone relatively new to TypeScript, this book was the right thing at the right time for me. I didn’t need an introductory-level book — TS being a superset of JS, after all, and syntax being something you can muddle through — but what I DID need was something that spoke to what was (1) idiomatic and (2) could shine a light on some of TS’s… idiosyncrasies.

This book helped me better frame my thinking around the so-called “type space” vs. the runtime code, as well as how to best consider TS’s structural typing as a good fit for JS’s notoriously loose types.

There are still some places where I scribbled “looks like more trouble than it’s worth” in the margins (but not too many) and I STILL have some work to do to get fluent in generics… BUT I would recommend this to anyone that has either (1) been working in TypeScript for 6+ months, and/or (2) who is coming I to TypeScript with a proficiency in JavaScript (looking at you, Dreyfus skill model).
]]> <![CDATA[Data Structures and Algorithms with JavaScript: Bringing classic computing approaches to the Web]]> 21432513
Determine which data structures and algorithms are most appropriate for the problems you’re trying to solve, and understand the tradeoffs when using them in a JavaScript program. An overview of the JavaScript features used throughout the book is also included.

This book

Arrays and the most common data structuresStacks and more complex list-like data structuresLinked how they overcome the shortcomings of arrays storing data as key-value pairs good for quick insertion and retrieval useful for storing unique elements that appear only onceBinary storing data in a hierarchical mannerGraphs and graph ideal for modeling networks including those that help you sort or search dataAdvanced dynamic programming and greedy algorithms]]> 394 Michael McMillan 1449373941 Rob 3 Short version: using JavaScript, McMillan introduces a bunch of fundamental computer science concepts around how data are shaped, and how we work with those data (e.g., searching and sorting). The choice of JavaScript is a practical one because of its ubiquity, but it's probably not the best choice for most of these. He does some things that are strange (and a few that are arguably "wrong") -- but overall, it's decent, especially if you're a professional web developer with a few years experience of "doing this" but otherwise lacking that computer science background.

Full review is on my blog: ]]> 3.76 2014 Data Structures and Algorithms with JavaScript: Bringing classic computing approaches to the Web

Data Structures and Algorithms with JavaScript: Bringing classic computing approaches to the Web

author: Michael McMillan
name: Rob
average rating: 3.76
book published: 2014
rating: 3
read at: 2019/08/21
date added: 2019/08/21
shelves: javascript, 2014, technical, 2019
review:
Short version: using JavaScript, McMillan introduces a bunch of fundamental computer science concepts around how data are shaped, and how we work with those data (e.g., searching and sorting). The choice of JavaScript is a practical one because of its ubiquity, but it's probably not the best choice for most of these. He does some things that are strange (and a few that are arguably "wrong") -- but overall, it's decent, especially if you're a professional web developer with a few years experience of "doing this" but otherwise lacking that computer science background.

Full review is on my blog:
]]> <![CDATA[Understanding ECMAScript 6: The Definitive Guide for JavaScript Developers]]> 30024696
You’ll
–How ECMAScript 6 class syntax relates to more familiar JavaScript concepts
–What makes iterators and generators useful
–How arrow functions differ from regular functions
–Ways to store data with sets, maps, and more
–The power of inheritance
–How to improve asynchronous programming with promises
–How modules change the way you organize code

Whether you’re a web developer or a Node.js developer, you’ll find Understanding ECMAScript 6 indispensable on your journey from ECMAScript 5 to ECMAScript 6.]]> 352 Nicholas C. Zakas 1593277571 Rob 4 2016, javascript, technical
1. I'm not sure who consulted on the organization, but I'd have likely tried to consider what the key features are that people are looking to adopt when adopting ES6 to their stack, and then organize it that way. For example: modules before proxies (and before most other chapters, TBH). HOWEVER: this is nothing you can't fix by being willing to read things out-of-order and use the Table of Contents.

2. Some of the examples could have been more useful. For example: when presenting the Proxy and Reflect APIs, something more concrete than replicating the built-in behavior would have been good. HOWEVER: this is a pretty minor nit, as it doesn't take much imagination to come up with your own examples to use in experimenting.

Overall: highly recommended if you need a good reference that illustrates the new ES6 features.]]> 4.27 2016 Understanding ECMAScript 6: The Definitive Guide for JavaScript Developers

Understanding ECMAScript 6: The Definitive Guide for JavaScript Developers

author: Nicholas C. Zakas
name: Rob
average rating: 4.27
book published: 2016
rating: 4
read at: 2016/12/12
date added: 2016/12/13
shelves: 2016, javascript, technical
review:
If you have a solid JavaScript foundation and are looking to cut your teeth on the ES6 features, this is a great place to start. I've written many times before about how well Zakas presents material, and how he makes it easy to learn; there's no exception to that here. My criticisms are minor:

1. I'm not sure who consulted on the organization, but I'd have likely tried to consider what the key features are that people are looking to adopt when adopting ES6 to their stack, and then organize it that way. For example: modules before proxies (and before most other chapters, TBH). HOWEVER: this is nothing you can't fix by being willing to read things out-of-order and use the Table of Contents.

2. Some of the examples could have been more useful. For example: when presenting the Proxy and Reflect APIs, something more concrete than replicating the built-in behavior would have been good. HOWEVER: this is a pretty minor nit, as it doesn't take much imagination to come up with your own examples to use in experimenting.

Overall: highly recommended if you need a good reference that illustrates the new ES6 features.
]]> <![CDATA[Eloquent JavaScript: A Modern Introduction to Programming]]> 22843271
Eloquent JavaScript, 2nd Edition dives into the language and teaches you to write beautiful, effective code. By immersing you in example code and encouraging experimentation right from the start, the author quickly provides the tools you need to build your own programs. As you follow along with examples like an artificial life simulation, a simple programming language, and a platform game, you'll learn to:

Understand the essential elements of programming: syntax, control, and data
Organize and clarify your code with object-oriented and functional programming techniques
Script the browser and make basic Web applications
Harness node.js to build servers and utilities
Use the DOM effectively to interact with browsers
This new edition is thoroughly revised and modernized, and it’s full of brand-new material, including expanded content on recursion, closures, and more. All source code is available online in an interactive sandbox and has been updated to follow current JavaScript idioms. With Eloquent JavaScript, 2nd Edition as your guide, you'll be fluent in the language of the Web before you know it.]]> 478 Marijn Haverbeke Rob 4 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.]]> 4.32 2010 Eloquent JavaScript: A Modern Introduction to Programming

Eloquent JavaScript: A Modern Introduction to Programming

author: Marijn Haverbeke
name: Rob
average rating: 4.32
book published: 2010
rating: 4
read at: 2015/03/16
date added: 2015/03/16
shelves: javascript, technical, 2014, 2015
review:
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.
]]> <![CDATA[Interactive Data Visualization for the Web: An Introduction to Designing with D3]]> 16087610 270 Scott Murray 1449339735 Rob 4 2015, javascript
Happy charting.]]> 4.10 2013

Interactive Data Visualization for the Web: An Introduction to Designing with D3

author: Scott Murray
name: Rob
average rating: 4.10
book published: 2013
rating: 4
read at: 2015/02/06
date added: 2015/02/06
shelves: 2015, javascript
review:
Very solid introduction to D3.js. Written primarily for a non-technical audience, but includes just the right amount of information to get you oriented to the library without feeling like it's patronizing or too shallow. (And/but/so Murray uses a colloquial tone which was fine with me but can rub some people the wrong way.) Despite being so long, it's actually a quick read -- which is good because you really ought to get through *at least* the chapter on scales before you try and go do anything with D3.

Happy charting.
]]> If Hemingway Wrote JavaScript 21487480
The best authors are those who obsess about language—and the same goes for JavaScript developers. To master either craft, you must experiment with language to develop your own style, your own idioms, and your own expressions. To that end, If Hemingway Wrote JavaScript playfully bridges the worlds of programming and literature for the literary geek in all of us.

Featuring original artwork by Miran Lipova?a.]]> 192 Angus Croll 1593275854 Rob 5 House of Leaves may have been involved.

And I am reminded of my friends David and Jeffrey. Of our many lunches together and how they would veer wildly from one niche subject to another. Obsessive discussion of the high-precision clock in the Web Audio API lapses into puns cobbled together from pop songs which climb slowly into something about the Stoics.

And I am reminded, as I so often am, of that quote from Eric Miraglia in the foreword to Nicholas Zakas' Professional JavaScript for Web Developers . The one that describes front-end development as being stocked with "many liberal arts majors drafted into web-developer service during the dotcom boom". [^2] And it's with this intriguing lens that I focus as I step back from Angus Croll's If Hemingway Wrote JavaScript.

In some ways, this is the anti-Good Parts. A book that relishes in all of JavaScript's quirky crevices. All those confusing features and weird idioms and other "bad parts" that are so maligned and yet one assumes must exist for a reason. Croll puts these on display, dressing them up as though written by some of the world's literary luminaries. [^3] He puts them out there as a way of showing off JavaScript's expressiveness [^4] -- of the many ways to approach a given problem, and the many ways to solve it. (Or make a mess of it.)

And in this, it is delightfully illustrative. [^5] It shows those many approaches. It shows off those many language features. It shows off what one might accomplish with them. And in this, the astute reader [^6] will get some cheer from the light-handed (if overt [^7]) mockery Croll has made of The Good Parts -- but that same reader will also recognize the places where one's personal style and whimsy might become impenetrable to others. (But we'll acknowledge that those are all decisions we must make for ourselves, and at runtime.)

To Angus Croll: thank you for asking me to read this, and thank you for sharing it with the world. It's a real treat, and a book whose time has come.

And to the rest of you: go get a copy:

---

[^1]: The actual performance ranking of that particular store is apocryphal.

[^2]: And looking again at that quote, it maybe doesn't say exactly what I remember it. But the gist is basically the same. And I know an awful lot of front-end developers that are formerly (and/or aspiring) musicians or physicists or novelists or farmers or what have you.

[^3]: And the Fibonacci assignment is so well-executed it's almost absurd. (And did you enjoy that progression? And did you get the joke re: from Hemingway to Brown?)

[^4]: And in so doing, takes a little dig on Java and its verbosity and ceremony and its own idioms and maybe just maybe he's being just a little hard on Java in the introduction there, but it's still worth laughing aloud.

[^5]: It also has delightful illustrations.

[^6]: Undoubtedly an astute JavaScriptician!

[^7]: Though always good-natured.

---

See also: ]]> 4.09 2014 If Hemingway Wrote JavaScript

author: Angus Croll
name: Rob
average rating: 4.09
book published: 2014
rating: 5
read at: 2014/08/21
date added: 2014/10/20
shelves: 2014, javascript, parody, all-time-favorites
review:
Reading this book, I am reminded first of my friend Mike. Of an evening in Baltimore at a mutual friend's home. Of vodka consumed and books given conversational chase and perhaps not a small amount of hero-worship on my part as he accelerated into his chosen field and I languished behind a copy machine at the worst-performing Kinko's in the country. [^1] House of Leaves may have been involved.

And I am reminded of my friends David and Jeffrey. Of our many lunches together and how they would veer wildly from one niche subject to another. Obsessive discussion of the high-precision clock in the Web Audio API lapses into puns cobbled together from pop songs which climb slowly into something about the Stoics.

And I am reminded, as I so often am, of that quote from Eric Miraglia in the foreword to Nicholas Zakas' Professional JavaScript for Web Developers . The one that describes front-end development as being stocked with "many liberal arts majors drafted into web-developer service during the dotcom boom". [^2] And it's with this intriguing lens that I focus as I step back from Angus Croll's If Hemingway Wrote JavaScript.

In some ways, this is the anti-Good Parts. A book that relishes in all of JavaScript's quirky crevices. All those confusing features and weird idioms and other "bad parts" that are so maligned and yet one assumes must exist for a reason. Croll puts these on display, dressing them up as though written by some of the world's literary luminaries. [^3] He puts them out there as a way of showing off JavaScript's expressiveness [^4] -- of the many ways to approach a given problem, and the many ways to solve it. (Or make a mess of it.)

And in this, it is delightfully illustrative. [^5] It shows those many approaches. It shows off those many language features. It shows off what one might accomplish with them. And in this, the astute reader [^6] will get some cheer from the light-handed (if overt [^7]) mockery Croll has made of The Good Parts -- but that same reader will also recognize the places where one's personal style and whimsy might become impenetrable to others. (But we'll acknowledge that those are all decisions we must make for ourselves, and at runtime.)

To Angus Croll: thank you for asking me to read this, and thank you for sharing it with the world. It's a real treat, and a book whose time has come.

And to the rest of you: go get a copy:

---

[^1]: The actual performance ranking of that particular store is apocryphal.

[^2]: And looking again at that quote, it maybe doesn't say exactly what I remember it. But the gist is basically the same. And I know an awful lot of front-end developers that are formerly (and/or aspiring) musicians or physicists or novelists or farmers or what have you.

[^3]: And the Fibonacci assignment is so well-executed it's almost absurd. (And did you enjoy that progression? And did you get the joke re: from Hemingway to Brown?)

[^4]: And in so doing, takes a little dig on Java and its verbosity and ceremony and its own idioms and maybe just maybe he's being just a little hard on Java in the introduction there, but it's still worth laughing aloud.

[^5]: It also has delightful illustrations.

[^6]: Undoubtedly an astute JavaScriptician!

[^7]: Though always good-natured.

---

See also:
]]> <![CDATA[Mastering Web Application Development with AngularJS]]> 18070137 357 Paweł Kozłowski 1782161821 Rob 4 4.04 2013

Mastering Web Application Development with AngularJS

author: Paweł Kozłowski
name: Rob
average rating: 4.04
book published: 2013
rating: 4
read at: 2014/07/09
date added: 2014/07/09
shelves: 2013, technical, javascript, 2014
review:
Longer review coming later at some point, and/but/so short version: I skimmed some parts, I read and re-read some parts, I may have missed some other parts all together, but all in all it was good.
]]> <![CDATA[Client-Server Web Apps with JavaScript and Java: Rich, Scalable, and RESTful]]> 20578304 257 Casimir Saternos 1449369332 Rob 3

Long version: ()

Having just wrapped up Client-Server Web Apps with JavaScript and Java by Casimir Saternos (O'Reilly, 2014), I'd say that I mostly got out of it what I wanted, and that it serves as a good jumping-off point for developers that want to build "modern" web applications on top of the JVM. More than anything else, Saternos' book is a thumbnail sketch of the architecture and tools needed to build those kind of apps, but it does not go particularly deep on any one of those items. As it says in the preface, it's probably best suited for developers who primarily work in Java and want to build a scalable web application with modern technologies -- not that front-end developers don't stand to gain something as well, but they may have more catching up to do (more on this in a moment...).

Saternos' basic approach here is to describe "modern" web applications as RESTful, API-based back-ends that primarily serve JSON to a rich front-end that is built around something like AngularJS. However, he doesn't limit himself to just the API and front-end layers here. Even a glance at the table of contents will reveal that he goes for breadth in his discussion: there are chapters on REST fundamentals and API design, API implementation with tools like Jersey, testing strategies with JUnit and Jasmine, build and deployment tooling, virtualization strategies, and more. The book's coverage is fairly shallow, but Saternos provides many references to other sources for richer coverage, and he also provides sample code with example implementations for each relevant chapter.

Was there anything missing? Yes and no... Again: the book is a shallow survey of these technologies, and as such it elegantly fulfills its main mission: to give an overview of the technologies that you would use when constructing a modern web application in the JVM. And again: there are plenty of references to solid foundational texts for those instances where you need to go deeper on some particular subject. But there are also seem to be some gaps.

First, some front-end developers may feel a bit lost coming into this; working in the JVM can be a bit daunting to the new-comer, and piling dynamic languages on top of this can be a bit eyebrow-raising. Part of me thinks that this is absolutely the right move -- I know a lot of front-end developers that are right at home in Ruby or Python, and so using JRuby or Jython as the introduction to the JVM makes sense. But there are also esoteric complications that come along with that which are not really addressed in the book. Not that a survey such as this is the right place to cover that kind of edge-case trivia, but a footnote to that effect may have been useful.

Second, the chapter on "Packaging and Deployment" focused exclusively on the server side of the web application with no substantive mention of how to package the front-end assets. Where was the discussion of minification and concatenation? Considering the depth of the discussion on REST and HTTP earlier in the book, I would have expected to loop back around on that here for a discussion of CDNs or Expires headers. This seemed like a lost opportunity to me.

In the grand scheme of what Saternos set out to do however, those critiques are pretty minor. That he assumes the reader has more familiarity with the JVM than with front-end technologies is evident, but not a detriment. The book is a good look into what technologies and techniques make up a "modern" web application, and though there is plenty of room for disagreement about some of his recommendations, it is also a great "conversation-starter" for your project, and chances are that you'll learn about a thing or two that you'll want to chase down further.

DISCLOSURE: I received an electronic copy of this book from the publisher in exchange for writing this review.]]> 3.71 2014 Client-Server Web Apps with JavaScript and Java: Rich, Scalable, and RESTful

Client-Server Web Apps with JavaScript and Java: Rich, Scalable, and RESTful

author: Casimir Saternos
name: Rob
average rating: 3.71
book published: 2014
rating: 3
read at: 2014/04/28
date added: 2014/04/29
shelves: 2014, java, javascript, technical
review:
Short version: good survey of building modern web apps in the JVM eco-system, and/but more oriented toward Java developers, and hardly enough JS to put it in the title.

Long version: ()

Having just wrapped up Client-Server Web Apps with JavaScript and Java by Casimir Saternos (O'Reilly, 2014), I'd say that I mostly got out of it what I wanted, and that it serves as a good jumping-off point for developers that want to build "modern" web applications on top of the JVM. More than anything else, Saternos' book is a thumbnail sketch of the architecture and tools needed to build those kind of apps, but it does not go particularly deep on any one of those items. As it says in the preface, it's probably best suited for developers who primarily work in Java and want to build a scalable web application with modern technologies -- not that front-end developers don't stand to gain something as well, but they may have more catching up to do (more on this in a moment...).

Saternos' basic approach here is to describe "modern" web applications as RESTful, API-based back-ends that primarily serve JSON to a rich front-end that is built around something like AngularJS. However, he doesn't limit himself to just the API and front-end layers here. Even a glance at the table of contents will reveal that he goes for breadth in his discussion: there are chapters on REST fundamentals and API design, API implementation with tools like Jersey, testing strategies with JUnit and Jasmine, build and deployment tooling, virtualization strategies, and more. The book's coverage is fairly shallow, but Saternos provides many references to other sources for richer coverage, and he also provides sample code with example implementations for each relevant chapter.

Was there anything missing? Yes and no... Again: the book is a shallow survey of these technologies, and as such it elegantly fulfills its main mission: to give an overview of the technologies that you would use when constructing a modern web application in the JVM. And again: there are plenty of references to solid foundational texts for those instances where you need to go deeper on some particular subject. But there are also seem to be some gaps.

First, some front-end developers may feel a bit lost coming into this; working in the JVM can be a bit daunting to the new-comer, and piling dynamic languages on top of this can be a bit eyebrow-raising. Part of me thinks that this is absolutely the right move -- I know a lot of front-end developers that are right at home in Ruby or Python, and so using JRuby or Jython as the introduction to the JVM makes sense. But there are also esoteric complications that come along with that which are not really addressed in the book. Not that a survey such as this is the right place to cover that kind of edge-case trivia, but a footnote to that effect may have been useful.

Second, the chapter on "Packaging and Deployment" focused exclusively on the server side of the web application with no substantive mention of how to package the front-end assets. Where was the discussion of minification and concatenation? Considering the depth of the discussion on REST and HTTP earlier in the book, I would have expected to loop back around on that here for a discussion of CDNs or Expires headers. This seemed like a lost opportunity to me.

In the grand scheme of what Saternos set out to do however, those critiques are pretty minor. That he assumes the reader has more familiarity with the JVM than with front-end technologies is evident, but not a detriment. The book is a good look into what technologies and techniques make up a "modern" web application, and though there is plenty of room for disagreement about some of his recommendations, it is also a great "conversation-starter" for your project, and chances are that you'll learn about a thing or two that you'll want to chase down further.

DISCLOSURE: I received an electronic copy of this book from the publisher in exchange for writing this review.
]]> Jasmine JavaScript Testing 18430547 Jasmine JavaScript Testing 146 Paulo Ragonha 178216720X Rob 3 technical, javascript, 2013
If you’re unfamiliar with Jasmine, Ragonha will give you a solid foundation of the testing framework by the end of the second chapter. Less than 40 pages in and you’ll understand Jasmine’s approach to testing, as well as how to stand up a basic test suite. His coverage of the core functions and the collection of built-in matchers is concise and accurate. He builds on this foundation by demonstrating Jasmine’s abilities in testing everything from asynchronous code (Sinon.js!) to MVC components (Backbone.js!) to AMD modules (Require.js!).

Despite the title, Jasmine JavaScript Testing isn’t merely about the testing framework, or even just about testing. What Ragonha gives us is a book about how to write better code, using testability as the measurement of success. What is strongest about this book is how he uses a refactoring project as a frame-of-reference for telling the testability story. He’s not just talking about using Jasmine for writing tests; he’s talking about how to use it alongside the other tools and patterns that will make you a better front-end developer.

If you’re just getting started with testing JavaScript for the front-end, or if you want to see some good real-world examples, then I would definitely recommend this one.

Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.

[1] There was Mark Ethan Trostler’s Testable JavaScript; and then there’s Nicholas Zakas’ Maintainable JavaScript which, while not technically about testing, has at least the one chapter about it.

[2] Here I refer to Evan Hahn’s JavaScript Testing with Jasmine -- not to confuse anyone over titles or anything.]]> 3.44 2013 Jasmine JavaScript Testing

author: Paulo Ragonha
name: Rob
average rating: 3.44
book published: 2013
rating: 3
read at: 2013/09/26
date added: 2013/09/26
shelves: technical, javascript, 2013
review:
Packt Publishing recently released Jasmine JavaScript Testing by Paulo Ragonha (), and I just wrapped up reading it this morning. I’ve read a few books on JavaScript unit testing [1] and at least one other that was dedicated to , [2] and this one is a strong entry.

If you’re unfamiliar with Jasmine, Ragonha will give you a solid foundation of the testing framework by the end of the second chapter. Less than 40 pages in and you’ll understand Jasmine’s approach to testing, as well as how to stand up a basic test suite. His coverage of the core functions and the collection of built-in matchers is concise and accurate. He builds on this foundation by demonstrating Jasmine’s abilities in testing everything from asynchronous code (Sinon.js!) to MVC components (Backbone.js!) to AMD modules (Require.js!).

Despite the title, Jasmine JavaScript Testing isn’t merely about the testing framework, or even just about testing. What Ragonha gives us is a book about how to write better code, using testability as the measurement of success. What is strongest about this book is how he uses a refactoring project as a frame-of-reference for telling the testability story. He’s not just talking about using Jasmine for writing tests; he’s talking about how to use it alongside the other tools and patterns that will make you a better front-end developer.

If you’re just getting started with testing JavaScript for the front-end, or if you want to see some good real-world examples, then I would definitely recommend this one.

Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.

[1] There was Mark Ethan Trostler’s Testable JavaScript; and then there’s Nicholas Zakas’ Maintainable JavaScript which, while not technically about testing, has at least the one chapter about it.

[2] Here I refer to Evan Hahn’s JavaScript Testing with Jasmine -- not to confuse anyone over titles or anything.
]]> <![CDATA[Programming Javascript Applications: Robust Web Architecture With Node, Html5, and Modern Js Libraries]]> 15812614 300 Eric Elliott 1449320945 Rob 3 2013, technical, javascript
Elliott's book fits neatly into that category of JavaScript books that are about praxis -- books that are not about specific libraries or language features or programming paradigms, but about doing "real development" on "real teams". It is close kin with Nicholas Zakas' Maintainable JavaScript , and (to an only slightly lesser extent) Addy Osmani's Learning JavaScript Design Patterns . And like ...Design Patterns, I found myself thinking once or twice: This book is like that in that it is an excellent and timely example of "how to do it the right way" and/but it also feels like it might be looking too microscopically at specific libraries or techniques? and consequently is it going to feel dated in 6-12 months? [2]

If you're already fairly well-read in the "JavaScript praxis book" arena, then most of this is going to be review. Elliott covers functions as first-class objects and functional style JavaScript (see also Functional JavaScript , others); style and linting (see also Maintainable JavaScript , others); different approaches to the module pattern and separation of concerns (see also: Learning JavaScript Design Patterns , others); and some other subjects. [3] The one subject I saw in here that I hadn't seen anywhere else was on internationalization -- which is something that I was very glad to see and is one of the reasons that I'll be recommending this one to people looking to build "professional" applications.

The other thing I wanted to point out here was that Elliott goes back and forth between programming JavaScript for the browser and programming JavaScript for Node, and the transitions aren't always clear. I expect this will get cleaned up a bit as they work it through editing for the final printed version. In either case, I am glad that he gives coverage to both in the same book, rather than marginalizing one or the other to a ghetto chapter.

----

Footnotes:

[1]: To be fair: almost all of the technical book publishers that I know of are doing this lately -- i.e., releasing and and the like.

[2]: I go back and forth on this bit of critique. If you're "all theory" then you're potentially losing out on providing some value because you're discussion is too far away from the real problems; but if you're too close to "the real thing" then you're just talking about that specific situation or tool-chain and it winds up being about addressing that problem with that tool, and not really "that class of problem". Elliott is somewhere in the middle here, listing only slightly toward "too specific" and only in a couple of places.

[3]: The PDF I have of this book has a little more, and some slightly different content than the version I read on my Kindle. Again: "Early Access Editions" and all that...]]> 3.58 2012 Programming Javascript Applications: Robust Web Architecture With Node, Html5, and Modern Js Libraries

Programming Javascript Applications: Robust Web Architecture With Node, Html5, and Modern Js Libraries

author: Eric Elliott
name: Rob
average rating: 3.58
book published: 2012
rating: 3
read at: 2013/09/05
date added: 2013/09/06
shelves: 2013, technical, javascript
review:
Borderline four stars... and I think when it's completed and fully edited, it just might be. (Disclosure: I read an early access edition; O'Reilly [1] has been doing that a lot lately...)

Elliott's book fits neatly into that category of JavaScript books that are about praxis -- books that are not about specific libraries or language features or programming paradigms, but about doing "real development" on "real teams". It is close kin with Nicholas Zakas' Maintainable JavaScript , and (to an only slightly lesser extent) Addy Osmani's Learning JavaScript Design Patterns . And like ...Design Patterns, I found myself thinking once or twice: This book is like that in that it is an excellent and timely example of "how to do it the right way" and/but it also feels like it might be looking too microscopically at specific libraries or techniques? and consequently is it going to feel dated in 6-12 months? [2]

If you're already fairly well-read in the "JavaScript praxis book" arena, then most of this is going to be review. Elliott covers functions as first-class objects and functional style JavaScript (see also Functional JavaScript , others); style and linting (see also Maintainable JavaScript , others); different approaches to the module pattern and separation of concerns (see also: Learning JavaScript Design Patterns , others); and some other subjects. [3] The one subject I saw in here that I hadn't seen anywhere else was on internationalization -- which is something that I was very glad to see and is one of the reasons that I'll be recommending this one to people looking to build "professional" applications.

The other thing I wanted to point out here was that Elliott goes back and forth between programming JavaScript for the browser and programming JavaScript for Node, and the transitions aren't always clear. I expect this will get cleaned up a bit as they work it through editing for the final printed version. In either case, I am glad that he gives coverage to both in the same book, rather than marginalizing one or the other to a ghetto chapter.

----

Footnotes:

[1]: To be fair: almost all of the technical book publishers that I know of are doing this lately -- i.e., releasing and and the like.

[2]: I go back and forth on this bit of critique. If you're "all theory" then you're potentially losing out on providing some value because you're discussion is too far away from the real problems; but if you're too close to "the real thing" then you're just talking about that specific situation or tool-chain and it winds up being about addressing that problem with that tool, and not really "that class of problem". Elliott is somewhere in the middle here, listing only slightly toward "too specific" and only in a couple of places.

[3]: The PDF I have of this book has a little more, and some slightly different content than the version I read on my Kindle. Again: "Early Access Editions" and all that...
]]> <![CDATA[The Little Book on CoffeeScript: The JavaScript Developer's Guide to Building Better Web Apps]]> 13436471 58 Alex MacCaw 1449321054 Rob 3 javascript, 2013, technical
And that's where MacCaw's Little Book on CoffeeScript comes in.

It's short (62 pages!) and gets right to the point. And MacCaw is (by and large) eloquent about the subject, if a bit... provocative at times.

So...

Loved: I wanted to learn a couple of things about CoffeeScript and MacCaw gave us exactly that, and with no ceremony. "This is CoffeeScript. Yes, this is all there is to it. And we're done."

However: there were a few statements in the book that made me bristle a bit. Example:

The typeof operator is probably the biggest design flaw of JavaScript...

The Little Book on CoffeeScript: The JavaScript Developer's Guide to Building Better Web Apps

author: Alex MacCaw
name: Rob
average rating: 3.68
book published: 2012
rating: 3
read at: 2013/08/20
date added: 2013/08/22
shelves: javascript, 2013, technical
review:
As a developer who loves JavaScript, I am naturally curious about CoffeeScript. Now, I may be a bit late to the game, but I had decided after hearing all that ballyhoo (both laudatory and deprecatory) for the past couple years that it was worth at least a little academic exploration. Now I'd and but no academic excursion is satisfactory without a good book.

And that's where MacCaw's Little Book on CoffeeScript comes in.

It's short (62 pages!) and gets right to the point. And MacCaw is (by and large) eloquent about the subject, if a bit... provocative at times.

So...

Loved: I wanted to learn a couple of things about CoffeeScript and MacCaw gave us exactly that, and with no ceremony. "This is CoffeeScript. Yes, this is all there is to it. And we're done."

However: there were a few statements in the book that made me bristle a bit. Example:

The typeof operator is probably the biggest design flaw of JavaScript...

Hmm... I suspect that most folks would describe the leaky and dangerous global namespace JavaScript's biggest design flaw. But OK.

And there are a couple of other off-hand statements like this (e.g., about "classes" in JavaScript, about mixins) but for the most part, these are minor and do not detract from the crux of the book.

And the crux of the book is about CoffeeScript. And by the end of it, you'll know enough about that little language to form your own opinion of it. And that opinion is probably something like:

"Oh, that's pretty neat."
]]> <![CDATA[Functional JavaScript: Introducing Functional Programming with Underscore.js]]> 17623632
Written by Michael Fogus—a core contributor to Clojure and ClojureScript, and author of The Joy of Clojure (Manning)—this book is packed with not only the how of functional programming, but also the why. Each topic illustrated with pointed examples. You’ll also get a thorough reference to the Underscore.js library and its idioms, including:

Closures
Applicative programming
Laziness
Immutability
Higher-order functions
Purity
Combinators
Currying and partial application]]> 258 Michael Fogus 1449360726 Rob 5 2013, javascript, technical 4.09 2013 Functional JavaScript: Introducing Functional Programming with Underscore.js

Functional JavaScript: Introducing Functional Programming with Underscore.js

author: Michael Fogus
name: Rob
average rating: 4.09
book published: 2013
rating: 5
read at: 2013/08/18
date added: 2013/08/18
shelves: 2013, javascript, technical
review:

]]> AngularJS 16087709 194 Brad Green 1449344852 Rob 4 2013, technical, javascript how non-trivial that will be. Green and Seshadri have a clear and straightforward approach to presenting the material (no tricks!) and it (mostly) helps that they're both so deeply involved in the framework's development.

I had quite a few "ah-ha" moments while reading this one, enough to get me better engaged with "the Angular Way" and to see some mistakes and pitfalls I was making in my own apps. Unfortunately, despite how clear Green and Seshadri are throughout the text, there are still a few concepts that don't quite ring totally clear. In particular: (1) there is a whole chapter on directives and yet at the end of it, I was not sure that I understood them that much more than when I started [1]; (2) whither filters?; (3) I have a sneaking suspicion that they slyly snuck in a few of the kinda/sorta undocumented features of the core Angular libraries without really mentioning it. [2]

Overall, the book is well-structured, with clearly titled chapters, making it easy to jump around and cherry-pick what you need out of it. If you're new to Angular, I highly recommend this book and urge you to (at a minimum) read the first four chapters.

----

[1]: That being said: you can tell just how important Green and Seshadri think directives are, and also just how complicated they think they are. Directives are introduced pretty early on, and then they get their own chapter, and then there's another more detailed (and arguably more useful) illustrative example in the "Cheatsheet and Recipes" chapter. (Which, by the way, would have been better titled as "Case Studies" -- but I digress.) Anyway: I'm thinking that directives are just one of those things that's critical to "the Angular Way" but is also fairly complex (incidentally or otherwise?) and you just need to find your own "ah-ha" moment.

[2]: I say kinda/sorta because the Angular documentation (you may have noticed) is broken down into an "API Reference" and a "Developer Guide" and it isn't always clear which features are documented where. Or why something is documented in one but not the other (or else why it's in both...) So maybe I'm being a little unfair when I say "snuck in" and "undocumented" but... well: that's how it felt.]]> 3.56 2013 AngularJS

author: Brad Green
name: Rob
average rating: 3.56
book published: 2013
rating: 4
read at: 2013/07/24
date added: 2013/07/24
shelves: 2013, technical, javascript
review:
I would rate this one as a pretty solid introduction to AngularJS, covering the framework's philosophy, the core APIs, and getting into a few (but not all) of the nuts-and-bolts. By the time you get to the end of it, you should be able to build a non-trivial app in Angular -- though the jury's out on exactly how non-trivial that will be. Green and Seshadri have a clear and straightforward approach to presenting the material (no tricks!) and it (mostly) helps that they're both so deeply involved in the framework's development.

I had quite a few "ah-ha" moments while reading this one, enough to get me better engaged with "the Angular Way" and to see some mistakes and pitfalls I was making in my own apps. Unfortunately, despite how clear Green and Seshadri are throughout the text, there are still a few concepts that don't quite ring totally clear. In particular: (1) there is a whole chapter on directives and yet at the end of it, I was not sure that I understood them that much more than when I started [1]; (2) whither filters?; (3) I have a sneaking suspicion that they slyly snuck in a few of the kinda/sorta undocumented features of the core Angular libraries without really mentioning it. [2]

Overall, the book is well-structured, with clearly titled chapters, making it easy to jump around and cherry-pick what you need out of it. If you're new to Angular, I highly recommend this book and urge you to (at a minimum) read the first four chapters.

----

[1]: That being said: you can tell just how important Green and Seshadri think directives are, and also just how complicated they think they are. Directives are introduced pretty early on, and then they get their own chapter, and then there's another more detailed (and arguably more useful) illustrative example in the "Cheatsheet and Recipes" chapter. (Which, by the way, would have been better titled as "Case Studies" -- but I digress.) Anyway: I'm thinking that directives are just one of those things that's critical to "the Angular Way" but is also fairly complex (incidentally or otherwise?) and you just need to find your own "ah-ha" moment.

[2]: I say kinda/sorta because the Angular documentation (you may have noticed) is broken down into an "API Reference" and a "Developer Guide" and it isn't always clear which features are documented where. Or why something is documented in one but not the other (or else why it's in both...) So maybe I'm being a little unfair when I say "snuck in" and "undocumented" but... well: that's how it felt.
]]> <![CDATA[JavaScript Testing with Jasmine: JavaScript Behavior-Driven Development]]> 17165516 52 Evan Hahn 1449356370 Rob 3 2013, javascript 3.42 2013

JavaScript Testing with Jasmine: JavaScript Behavior-Driven Development

author: Evan Hahn
name: Rob
average rating: 3.42
book published: 2013
rating: 3
read at: 2013/05/03
date added: 2013/05/03
shelves: 2013, javascript
review:

]]> <![CDATA[JavaScript Enlightenment: From Library User to JavaScript Developer]]> 17152736 164 Cody Lindley 1449342884 Rob 2 tl;dr: It's a 150 page essay on auto-boxing, full of dangerous code examples and anti-patterns and soft warnings to "not do what I just did", and some 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.

JavaScript Enlightenment: From Library User to JavaScript Developer

author: Cody Lindley
name: Rob
average rating: 3.60
book published: 2012
rating: 2
read at: 2013/01/01
date added: 2013/01/02
shelves: 2012, javascript, technical, 2013
review:
tl;dr: It's a 150 page essay on auto-boxing, full of dangerous code examples and anti-patterns and soft warnings to "not do what I just did", and some 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.

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.
]]> <![CDATA[ClojureScript: Up and Running: Functional Programming for the Web]]> 15812003 113 Stuart Sierra 1449327435 Rob 4 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.]]> 3.20 2012 ClojureScript: Up and Running: Functional Programming for the Web

ClojureScript: Up and Running: Functional Programming for the Web

author: Stuart Sierra
name: Rob
average rating: 3.20
book published: 2012
rating: 4
read at: 2012/12/16
date added: 2012/12/17
shelves: 2012, technical, clojure, javascript
review:
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.
]]> <![CDATA[Testable JavaScript: Ensuring Reliable Code]]> 14514272 271 Mark Ethan Trostler 1449323391 Rob 3 javascript, technical, 2012
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.]]> 3.48 2012 Testable JavaScript: Ensuring Reliable Code

Testable JavaScript: Ensuring Reliable Code

author: Mark Ethan Trostler
name: Rob
average rating: 3.48
book published: 2012
rating: 3
read at: 2012/12/12
date added: 2012/12/12
shelves: javascript, technical, 2012
review:
Right off the bat: I read an early access edition, and in a lot of places... it shows. It'll come through editing and be a lot tighter by the time you 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.
]]> HTML5 and JavaScript Web Apps 13588654 169 Wesley Hales 1449320511 Rob 3 2012, javascript 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.)]]> 3.28 2012 HTML5 and JavaScript Web Apps

author: Wesley Hales
name: Rob
average rating: 3.28
book published: 2012
rating: 3
read at: 2012/11/24
date added: 2012/11/24
shelves: 2012, javascript
review:
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.)
]]> <![CDATA[Node for Front-End Developers: Writing Server-Side JavaScript Applications]]> 13227091 56 Garann Means 1449318835 Rob 3 javascript, 2012 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.]]> 3.09 2012 Node for Front-End Developers: Writing Server-Side JavaScript Applications

Node for Front-End Developers: Writing Server-Side JavaScript Applications

author: Garann Means
name: Rob
average rating: 3.09
book published: 2012
rating: 3
read at: 2012/11/20
date added: 2012/11/20
shelves: javascript, 2012
review:
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.
]]> <![CDATA[Learning Javascript Design Patterns]]> 14289134 227 Addy Osmani Rob 2 2012, technical, javascript 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.]]> 3.82 2011 Learning Javascript Design Patterns

author: Addy Osmani
name: Rob
average rating: 3.82
book published: 2011
rating: 2
read at: 2012/09/15
date added: 2012/09/16
shelves: 2012, technical, javascript
review:
카지노싸이트.com has a 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.
]]> <![CDATA[Web Workers: Multithreaded Programs in JavaScript]]> 13592438
If you have an intermediate to advanced understanding of JavaScript— especially event handling and callbacks—you’re ready to tackle Web Workers with the tools in this example-driven guide.

Start creating Web Workers and understand what they can and can’t do
Determine which browser versions support the API
Use dedicated Web Workers for tasks that consume a lot of CPU, such as data parsing
Explore use cases for creating inline Workers, such as encapsulating a web app in one page
Create a shared Worker to communicate multiple web app instances to the server, and other uses
Learn best practices for debugging Web Workers
Apply Web Workers within the server-side Node environment]]> 58 Ido Green 1449322131 Rob 3 2012, javascript, technical 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.]]> 3.16 2012 Web Workers: Multithreaded Programs in JavaScript

Web Workers: Multithreaded Programs in JavaScript

author: Ido Green
name: Rob
average rating: 3.16
book published: 2012
rating: 3
read at: 2012/07/08
date added: 2012/09/03
shelves: 2012, javascript, technical
review:
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.
]]> <![CDATA[Maintainable JavaScript: Writing Readable Code]]> 13591032 When you write code in a team setting, will other developers be able to understand what you did? Did you organize your code in such a way that it's easy to adapt and extend? Will your code survive once you're gone? Maintainable JavaScript doesn't just recommend a set of guidelines, it examines guidelines being used and recommended by others in the industry, so you get a feel for what's common in well-run JavaScript projects.
Save a copy of this book now. It's the only resource that focus solely on JavaScript conventions.]]> 238 Nicholas C. Zakas 1449327680 Rob 3 technical, javascript, 2012 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 ~~a lengthy appendix to~~ an expanded version of Chapter 24 of his 2012 [title: Professional JavaScript for Web Developers] (3rd edition). It's an opinionated book about formatting style, about programming conventions, and about ways of helping you (and your team) write code that is a lot less likely to blow up on you down the line.

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...]]> 3.87 2012 Maintainable JavaScript: Writing Readable Code

Maintainable JavaScript: Writing Readable Code

author: Nicholas C. Zakas
name: Rob
average rating: 3.87
book published: 2012
rating: 3
read at: 2012/05/23
date added: 2012/05/27
shelves: technical, javascript, 2012
review:
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 ~~a lengthy appendix to~~ an expanded version of Chapter 24 of his 2012 [title: Professional JavaScript for Web Developers] (3rd edition). It's an opinionated book about formatting style, about programming conventions, and about ways of helping you (and your team) write code that is a lot less likely to blow up on you down the line.

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...
]]> <![CDATA[jQuery UI: Learn How to use Dialogs, Autocomplete, and More]]> 13234065 225 Eric Sarrion 1449316999 Rob 2 javascript, technical, 2012 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.
]]> 3.33 2012 jQuery UI: Learn How to use Dialogs, Autocomplete, and More

jQuery UI: Learn How to use Dialogs, Autocomplete, and More

author: Eric Sarrion
name: Rob
average rating: 3.33
book published: 2012
rating: 2
read at: 2012/04/09
date added: 2012/04/09
shelves: javascript, technical, 2012
review:
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.

]]> <![CDATA[JavaScript Patterns: Build Better Applications with Coding and Design Patterns]]> 9422683 216 Stoyan Stefanov 0596806752 Rob 4 2010, javascript 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.]]> 4.18 2010 JavaScript Patterns: Build Better Applications with Coding and Design Patterns

JavaScript Patterns: Build Better Applications with Coding and Design Patterns

author: Stoyan Stefanov
name: Rob
average rating: 4.18
book published: 2010
rating: 4
read at: 2010/12/05
date added: 2010/12/05
shelves: 2010, javascript
review:
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.
]]>