In the book, Eric presents his Stampit library as a way to combine the "best of" features surrounding object relationships in order to create an approach that easily allows for encapsulation, prototypal inheritance, and privileged methods. I've spent a few hours reading through the Stampit source code (you should check it out) and it does some very interesting and clever things. But, I'm still having a hard time thinking about creating objects without constructors.
Take, for example, trying to create a Stream that also exposes a Deferred value. Without a constructor function, who creates that deferred value that's associated with the stream? Not the developer consuming the stream - we definitely don't want the consumer to worry about the object properties at that level. So, maybe one of the "enclose" functions then (part of Stampit)? Of course, if we start using the enclose functions to set up state, aren't we just using a constructor function and calling it a different name?
I suppose that we could also create a factory function that encapsulates the use of Stampit. That way, the factory function could create the Deferred value and then inject it into the instance as an override to the .create() method (which will override the default, prototype state).
But, even if we go that route, I think we still come up missing a little something. Setting up the Deferred value is one thing; but, we also need to set up event handlers that wire stream events into promise events (ie, translating emitted events into Deferred resolution and rejection). Who does that? The factory function?
On the "let" keyword in ES6. I personally do not understand the "let" keyword at all. It feels like it's trying to solve a problem that I don't have. As such, seeing this tip was very comforting:
TIP: The desire to use block scope can be a good code smell that indicates that it may be time to break a function into smaller pieces in order to encourage readability, organization, and code reuse. It's a good idea to keep functions small. (Page 47)
On handling the node_modules folder. This passage will, without a doubt, be highly controversial. But, my gut feeling is that Eric is correct when he says:
Since you'll be deploying this app, you should consider all of the code it uses to be part of the app, including its dependencies. You don't want those dependency versions shifting around under your feet during your deploy step. The less uncertainty and moving parts you have in a deploy step the better. For that reason, you're going to want to check in your node_modules directory (don't add it to .gitignore). (Page 158)
For me, there are two big reasons why this makes sense:
- I might have to go in and patch some code in a vendor library. Whether it be buggy or just lacking something that I need, I would have to be able to check-in the vendor code in order to get it deployed in production.
- I would think this gives us a great opportunity to de-dupe dependencies (though, huge caveat, I haven't yet written any production Node.js applications ... yet).
Let it crash. Processes crash. Like all things, your servers's runtime will expire. Don't sweat it. Log the error, shut down the server, and launch a new instance. You can use Node's cluster module, forever (a Node module available on npm), or a wide range of other server monitor utilities to detect crashes and repair the service in order to keep things running smoothly, even in the face of unexpected exceptions. (Page 221)
Coming from a ColdFusion / J2E background, Node.js feels like a laughably brittle environment. As such, it's good to see that seasoned developers can embrace this nature rather than fear it. Now, I don't think Eric means that all errors should bubble up into exceptions; but, rather, that an application shouldn't be expected to gracefully recover from every single error that it encounters.
There's really way more in this book than I could cover in a single review. It has a good deal of stuff in here that I wish I had known about (or known to think about) when I started building more complex web applications. I would say that it is definitely worth the read.