Single Page Web Applications: JavaScript end-to-end First Edition

MVC can be implemented by hand (roll your own), but as your application grows (with perhaps tens of states to manage) it quickly becomes unwieldy to continue to do so. Therefore, just as there are various frameworks/libraries for facilitating server-side MVC, many JavaScript frameworks/libraries have emerged for enabling client-side MVC, including Knockout, Backbone, Ember, and Angular. However, what sets this book apart is that the authors argue against using a client-side MVC framework. Having used several client-side MVC frameworks over the past few years, I can appreciate the stance taken by the authors.Just a couple of years ago, Knockout and Backbone were considered de facto standards for client-side MVC. Then, almost out of nowhere, came Angular, supported by Google’s seemingly infinite programming and marketing resources. But Angular is new and is still undergoing radical changes from release to release. As a result, documentation is often lagging and there are multiple ways to do the same thing: legacy approaches often co-exist with newer approaches, as if to see what sticks. Furthermore, each of these “automatic two-way data binding” frameworks requires the programmer to accept some rigidity in exchange for convenience.In case you’re wondering, it’s clear that the authors aren’t “roll your own” advocates. It’s just that they don’t want to invest in an immature or rigid client-side MVC framework. Although Angular is gaining traction, as of now there are no client-side MVC frameworks that can reasonably be termed as mature. As evidence of the authors’ level-headedness, consider their testing approach, detailed in Appendix B. Here, the authors write, “Node.js has many test frameworks that have years of use and refinement. Let’s be wise and use one instead of hacking our own.” The key here is the framework’s maturity. Since there are several reasonably mature JavaScript testing frameworks, the authors do not shy away from using them. After briefly describing jasmine-jquery, mocha, nodeunit, patr, vows, and zombie, the authors decide to go with nodeunit and describe how to set up a JavaScript testing framework for their SPA. Similarly, the authors use jQuery, which is another highly mature JavaScript framework for document object model (DOM) manipulation. Additionally, the authors use a pure JavaScript stack, with Node.js and MongoDB on the server side.One upside of not using a client-side MVC framework is that you’re left with little choice but to become an expert at JavaScript. This book certainly helps with that as it goes step-by-step, building an SPA end to end. One of the book’s highlights is its overview of JavaScript in chapter 2. The authors do a tremendous job of explaining concepts like variable scoping and variable and function hoisting and closure, and provide new insights into the inner workings of JavaScript, such as the execution context object. As a complement to chapter 2, the authors present a useful set of coding standards in Appendix A.In closing, here’s a sampling of some of the interesting approaches used in this book:-The HTML file is merely a shell with no content at all. All of the HTML is converted to JavaScript strings (using regular expressions) and embedded within the JavaScript code.-The use of callbacks is reduced via the use of jQuery global custom events.-The book recommends feeling a lot less guilty about using pixels since browsers have started implementing pixels as relative units and pixels are often more reliable than traditional relative units like em or percent.-The book recommends testing views and controllers manually (although user interface (UI) testing automation frameworks have matured and I’ve had considerable success with the combination of Protractor, Jasmine, and AngularJS).-The authors discourage the use of embedded template libraries like Underscore.js, but encourage the use of toolkit-style template systems such as those provided by Handlebars, Mustache, and Dust.

I wrote my first computer program in 1974 (on punched cards). In 1975 I actually soldered together a computer built from transistors (because motherboards didn't exist yet). I've written code in dozens of languages, many of which most developers today have never heard of (WATFIV or SNOBOL, anyone?). I've done Master's level work in Computer Science, including writing an operating system in a VM assembly language and writing a compiler for a high level language. I understand code. Javascript is the only language I've used in the last 20 years that I simply could not master just by reading and tinkering with existing code, and maybe reading a little doc here and there. I can get by in Javascript: I can tweak scripts, I can handle jQuery pretty well, I can even write some basic functionality from scratch. But there is good quality, professional grade Javascript code out there that I simply cannot read. I read it and I have no idea what it does or why it's doing it. So I can't tweak it. That is highly unusual for me, not to mention extremely frustrating.Chapter 2 of this book, Reintroducing Javascript, has lifted the veil, opened my eyes, and revealed to me Javascript's true nature. It very clearly, very simply describes what's different in Javascript vs. every other language I've ever used. Here are the concepts I now genuinely understand:+ Every other language I've used scopes variables lexically, i.e. based on the lexical blocks (not functions) in which the variable's declaration is nested. Javascript scopes variables dynamically, i.e. based on the functions (not blocks) that are on the runtime stack at the time the function is defined (not run).+ Because variables are scoped dynamically (based on the runtime stack), Javascript requires "closures", which "close over" the stack and save the runtime states of variables deeper in the stack for functions defined on that stack but (potentially) run later with a different stack state. Javascript creates closures automatically, but programmers often explicitly use (to my eyes) peculiar syntax to force closures they know they'll need.+ Every other language I've used defines objects using classes (blueprints). Javascript defines objects using prototypes (examples).Having these differences explicitly called out and explained so clearly and concisely has truly changed my (professional) life. I get Javascript now. I now not only recognized the "immediate function" syntax, but I understand why it was written that way. Eureka! Really. Eureka!The book probably also helps you build single page web applications. I'm manually typing in the examples and working through the code. I've made it through Chapter 3, and I can imagine by the end of the book I'll end up with a handy little chat app. But I truly don't care what comes later in the book - they could spend the whole rest of the book telling me stories about their pets. I got double my money's worth from Chapter 2, and that's worth 5 stars to me. Thanks, Michael and Josh! Thanks tons!