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 neeAs 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)....more
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 (mayLike 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....more
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 timIf 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....more
Very solid introduction to D3.js. Written primarily for a non-technical audience, but includes just the right amount of information to get you orienteVery 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.
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 convReading 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.
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 puShort 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....more
Short version: using JavaScript, McMillan introduces a bunch of fundamental computer science concepts around how data are shaped, and how we work withShort 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.
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 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....more
Packt Publishing recently released Jasmine JavaScript Testing by Paulo Ragonha (), and I just wrapped up reading it this morning. I’ve readPackt 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.
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]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......more
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 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:
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 notI 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....more
tl;dr: It's a 150 page essay on auto-boxing, full of dangerous code examples and anti-patterns and soft warnings to "not do what I just did", and sometl;dr: It's a 150 page essay on auto-boxing, full of dangerous code examples and anti-patterns and soft warnings to "not do what I just did", and some of the wording is not-wrong-but-not-quite-right, but hey there are some decent parts, I guess.
Cody Lindley's JavaScript Enlightenment has an awesome title, and I wanted very much to like it--but I think I'm going to have a hard time recommending it to anyone. Maybe.
Lindley states that the target audience for his book is (effectively) JavaScript dilettantes. In his words:
...it is my hope that the material in this book will transform you from a JavaScript library user into a JavaScript developer.
I interpretted that statement to mean that he is looking at the designers and the junior developers and the programmers coming at JavaScript from other languages--all the ones out there that have been using jQuery and/or ExtJS and/or Dojo with effectiveness (or at least competence) and now they're interested in digging into the guts of their favorite library, and perhaps even getting their heads around that thorny beast called JavaScript.
This is an admirable goal, and one that I fully support. But when I got to the end, I scratched my head and wondered aloud: "Did I just finish a 150 page essay on ?"
Understand objects and you will understand JavaScript.
This is (more/less) Lindley's thesis statement for the rest of the book. From there, we have a lot of discussion and exposition about JavaScript's types, including quite a bit of examination into how the various primitives are coerced (behind the scenes) into their wrappers and then back down again. Lindley is right, this is important stuff to know if you want to have a deep understanding of JavaScript--but if you're at the point with JS libraries that you're taking a wrench to the plumbing, then you've probably already gotten this information on your own already. (Or else have learned how to look it up in or or the .) But my skepticism about this might be totally unfounded--perhaps there is a big audience for this kind of book. (Most of the ratings on 카지노싸이트 are 5 stars.)
But... My biggest issue comes from what I perceive to be a... almost reckless or dangerous approach to presenting the material. What I mean by this is that while many of the code examples are technically correct, they are not idiomatic -- in other words, you wouldn't see code like that "in the wild." (Or shouldn't, anyway.) Sure, you can use the String constructor to create strings -- but this almost never offers you any advantage over simply creating a string with literals. (Most of the time it will hurt you, or confuse the typeof operator, or lead to some other language quirk that will catch a JavaScript novice off-guard.) Granted, to Lindley's credit, he states in numerous places in the text that "no one really does this" or "you should just use the primitive/literal form of this" -- but after also asserting (right at the very beginning) that the reader should pay more attention to the code... Well, I'm fearful that those same readers will pick up hard-to-break bad habits.
And I think that's why my reaction was to think: "This is a dangerous book."[^1] As an author, you're in a powerful position as a teacher and role model--so if you're demonstrating "weird" code or error-prone techniques or calling things by the wrong name[^2], then you might wind up influencing a bunch of developers into those bad habits--even if you didn't mean to, even if you warned them against those exact methods.
Perhaps I'm over-reacting a little bit, but believe strongly that these things matter.
"Comma-first" or abusing is one thing... But using Number where you should be using parseInt is quite another.
I had other criticisms as well (e.g., talking about "associative arrays" is always a sketchy proposition when your target audience is JS novices; e.g., making no mention of strict mode whatsoever[^3]) but they're really just pale variations on "the big one" above.
So where do I land on this book? For all my critique of it, I am not sure that I have a recommendation that fills quite the same niche. Addy Osmani's Learning JavaScript Design Patterns came to mind first--but then I thought about how that might actually be a follow-up read to JavaScript Enlightment. If Osmani's Patterns book is out, then so is Stefanov's JavaScript Patterns. And Lindley more/less explicitly calls out Crockford's JavaScript The Good Parts as the kind of book that would scare off his target audience. Nicholas Zakas' new book, Principles of Object-Oriented Programming in JavaScript, is very similar in what it covers, and has more/less the same thesis... According to my survey, that's the closest contender. (And each offers something that the other does not so...)
I guess my final verdict is that I'd recommend Zakas' Principles of Object-Oriented Programming in JavaScript, and if it scares you too much then back-track to JavaScript Enlightenment -- but with the caution that you need to be disciplined in how you approach it, because we can't have you littering your code with new Number(1).
----
[^1]: I had a similar reaction when I reviewed .
[^2]: For example: not calling "auto-boxing" by name. For example: calling it a "self-invoking anonymous function" instead of an .
[^3]: The omission of seems like a major oversight to me. I realize that Lindley's discussion was germane to ES3 and not ES5--but 'use strict' is out there in the wild, and it can dramatically alter some of the behaviors described in this book. If the target audience really is people that are diving into the plumbing of their essential libraries, then some of them are going to see this and not realize the significant implications it might have w/r/t/ some bug they're trying to trace.
[^4]: Perhaps even too colloquial from time to time. "Grok"? Seriously? We need a moratorium on this so-called word.
----
Disclosure: I received an electronic copy of this book from the publisher in exchange for writing a review....more
Nicholas Zakas has a new (and short!) book out on Leanpub called Principles of Object-Oriented Programming in JavaScript. Remember the OOP coverage frNicholas Zakas has a new (and short!) book out on Leanpub called Principles of Object-Oriented Programming in JavaScript. Remember the OOP coverage from his Professional JavaScript for Web Developers? It’s like a deep-dive version of that. Recommended.
I had the privilege of getting some early looks at this book and am glad he pulled the wraps off of it to share with everyone.
Zakas goes into the gritty details of the various OOP patterns that are available and idiomatic in JavaScript. After some technical introduction into some of JavaScript's low-level details (mostly around the primitives and reference types), he gets in to the different patterns, touching on the tried-and-true (if flawed) methods that we relied on from back in the ECMAScript 3 days, through to the new and native ECMAScript 5 methods. He also gets into mixins and scope-safe constructors.
Right off the bat: I read an early access edition, and in a lot of places... it shows. It'll come through editing and be a lot tighter by the time youRight off the bat: I read an early access edition, and in a lot of places... it shows. It'll come through editing and be a lot tighter by the time you read it. I promise.
Putting that aside, I had some mixed feelings about this book. I'll try to explain it as follows:
Rebecca Murphey did a talk during the 2012 JavaScript Summit (put on by E4H) which was titled "Writing Testable JavaScript". Early on in that talk, she impressed upon us that she was going to talk about how to write testable JavaScript, and not how to write JavaScript tests, nor how to test JavaScript. These are important distinctions. Writing tests (in a way) is this weird hybrid of somehow both writing more code and writing documentation. And testing your code is ... well, it's the act of putting your code through the accompanying tests to see if they pass muster. But writing testable code is about adopting a certain style wherein your code becomes easier to test. And the argument goes that if your code is easier to test, then it is also easier to reason about. (Insert functional programming rant here.)
Anyway...
Trostler talks about this, but not nearly at the length I was hoping for. Whereas Murphey kept her talk (albeit, it was a one hour talk) focused on adopting testable styles, Trostler's book manages to be about writing testable code, writing tests, and running tests. Given the title, I was expecting more about that functional style, more about decomposing functions into discrete units, more about how to reason about problems etc. And it wasn't even that this was missing, just that he was more/less finished talking about that by (say...) Chapter 3.
From there, he takes us on a tour of the rest of Test Town: writing unit tests, writing integration tests, code coverage, performance testing, load testing, debugging, linting and code quality, and how to bundle it all up and automate it. Somehow this is both too much information and not nearly enough at the same time. For example: there is a whole chapter dedicated to code coverage, and yet I walked away from it not really sure if I knew how to do that kind of instrumentation, nor if I fully understood the value. For example: integration testing, performance testing, and load testing are all jammed in to one chapter, and should probably have been split up in to separate chapters, and/but he also starts talking about things (e.g., generating HAR reports) which are... not strictly testing JavaScript.
I think maybe that's where I got my first real taste of those mixed feelings. I've been looking at a lot of front-end performance stuff lately, and so I'm very interested in it. But talking about "wire weight" is not what I think about when I see a book titled Testable JavaScript.
At any rate, lest this turns in to an off-color and off-topic rant: I reconcile my mixed feelings about the book in a mostly positive manner. The things that are outside the scope that's implied by the title are all things that any front-end engineer worth her semicolons should be fussing about anyway -- so that's all well and good. And I see here in my notes a snarky remark about "suggested alternative title: Testing JavaScript with Y.Test" -- but that's a little unfair of me. Overall, this book (and books like it) need to be written for front-end engineers. We need this badly, and I'm happy to start seeing these books crop up. This is the sort of thing that we need to see more of in our discipline.
My hat is off to Trostler for furthering the conversation; and/but: his editor has some work ahead of them both....more
Loading...