TL;DR

The Build First philosophy will help you approach application building in a more disciplined way. Adopting a build-oriented mentality, designing large but maintainable JavaScript applications, and deploying from the command line are some of the key take-aways in the book.

Build First In a Pinch

As you might’ve read, this is a book about designing JavaScript applications in a build-oriented manner. To get a hint about the contents of Part I, on build processes, I’ve compiled a list with a few articles on the subject you can peek at. Part I is dedicated entirely to the build and deployment processes. You’ll learn how to automate integration testing, deployments, builds, and even development. Grunt (as a tool) is taught from scratch, but the concepts should stick with you even if you part ways with Grunt.

• Deploying Node Apps to AWS Using Grunt
• Continuous Development in Node.js
• Grunt Tips and Tricks
• Understanding Build Processes
• Managing Code Quality in Node.js
• Upgraded Asset Management

Part II is dedicated to complexity management in JavaScript applications. Here, chapters cover topics such as modularity and package management, asynchronous programming styles, unit and integration testing (again, in JavaScript). Solid JavaScript programming in general. I’ve also written a few relevant articles on the subject as well.

• The Angular Way
• Uncovering the Native DOM API
• Getting Over jQuery
• Fun with Native Arrays
• The Web Wars
• Taming Asynchronous JavaScript
• Pragmatic Unit Testing in JavaScript
• Information Hiding in JavaScript

Build First In a Nutshell

Build First is all about keeping a maintainable, modular code-base that can be continuously delivered in a consistent manner, from the very beginning.

The importance of #buildfirst stems from the fact that plugging a build process into an existing project is so hard. Some things just have to be baked into a project starting with its inception, if they are to succeed. Have you tried refactoring a website written without a client-side MVC framework, entirely dependant on jQuery, into using Angular.js? It’s an extremely hard thing to do. It’s even harder to do it right, not leaving the project as a half-baked zombie which is really just jQuery with cream on top, turning it into the awful kind of dessert you most definitely don’t want to be eating.

The absence of build processes presents similar complications. If we abstain from implementing an automated build and deployment process, we might be putting our business at risk. I can’t really come up with a reason not to implement one, other than dramatic attempts to attain “gold sinking powerhouse” status. Regrettably, not all of us are playing an RPG with our business, some of us can’t have the luxury of that kind of risk.

You are probably going to need a build process at some point, regardless. Even if you argue your way out of automated, one step deployments, you are still going to need to do simply things such as bundling and minifying your static assets, or more advanced stuff like cache busting, appending hashes to your filenames (e.g: /js/ad161513.all.js) so that you can set far-future Expires headers.

Aren’t you just tired of adding icons to that spritesheet and updating the relevant CSS all by yourself? You should automate those things!

The other side to Build First is concerned with actually building out the application. Not everything is in the process, obviously. A modular architecture with good separation of concerns is also key in keeping your code testable, and easily understandable across your team. Together, we’ll explore different frameworks that can help us build a cleanly structured application, while staying away from tightly coupled, jQuery-intensive code. Dependency resolution, asynchronous or otherwise, also gets covered.

Asynchronous flows might represent a problem if you’re not that well versed in JavaScript programming, other than your first-level callback. I invite you to explore different approaches to tackle this problem, such as Promises, the async control flow library, and ES6 Harmony generator functions.

Reference Links

In the book there are various places where I reference articles other authors have written, and this presented two problems. Links are hard to type if you are holding in your hands a print copy of a book. I know because I’ve been there. I was also worried about link rot (links no longer working, because Internet). These are the reasons why bevacqua.io, the website that hosts the promotional landing page for the book, was originally conceived. It started out with a small JSON file with all the links referenced in the book, and a short identifier which you could actually type into the browser by hand.

For example, one of the first links that appear on the book is bevacqua.io/bf/knight, which is way more convenient to type by hand than, say, pythonsweetness.tumblr.com/post/64740079543/how-to-lose-172-222-a-second-for-45-minutes. Later on, I figured I could put all of that relevant material regarding topics that are at the core of my book to good use. So, the site slowly started progressing, and with a few descriptions and icons, the #buildfirst Resources page was born.

Companion Code

Good companion code makes a world of difference when it comes to technical books that are supposed to be teaching you how to write better code. I’ve spent enough time reading books to know just how important good quality code samples can be. Quality code samples should be properly documented, available online on a GitHub repository which is periodically updated, and sufficiently structured so it isn’t unthinkable to look up a particular snippet of code.

I’m really happy with the effort I’ve poured into developing documentation for these code samples. For instance, this code sample, showing how to automate database related tasks is barely mentioned in the book, because the content isn’t really relevant to the context where it is mentioned in. Still, the code sample fills the content gap, connecting the sample with what’s discussed in the book, and highlighting aspects that are not discussed elsewhere.

Here’s a few other ones I had fun coding and documenting:

• Encrypt your configuration with RSA keys, easter egg included!
• Build First, Deploy, Build Again
• Deploying to Amazon EC2

Trivia you probably don’t care about

This is actually the first thing I wrote about, because it’s what drove me to write the book. I then moved it to the bottom, because you would’ve probably skipped it anyways. If you’re enthusiastic about this book, you might find these facts to be a tad more interesting.

When I originally pitched the book to Manning, I had a book about Node.js in mind. Over the months, the focus changed to code quality, development workflow, and build process optimizations. Here is an excerpt taken right from the proposal I sent to Manning, listing of topics I was entertaining back in May.

I’d like to write about how to set up an effective development environment, and how to architect a coherent application in JavaScript, both for the front-end and the back-end.

Topics the book might cover would include:

• Node fundamentals, common patterns, I might want to spend 2-3 chapters in introducing some of the lesser known aspects of JS development
• Web Application Architecture, I would separate this in two, back-end and front-end, talk about architecture in Node, architecture in the back end, how to keep them loosely coupled, and how to let them communicate. I wouldn’t stay high level but give actual practical advice or examples, such as efficiently using Express and AngularJS
• Environments, how to set up an environment that favors productivity, mastering everyday tools, such as text editors, consoles, and git
• Testing, a quick glance over the different types of testing, tools, and how to automate it
• The Build Process, why one step builds are important, how everything comes together when building, different tools you can use

Their publisher replied to my proposal the next day, and we began dancing around the proposal, putting together a table of contents. As time went on, I progressively realized I literally had no freaking idea how to write a book. That’s where Manning’s editors came in, they’ve been great so far, I’ve learned a lot about the process and book writing itself, and I believe I’m becoming better at pushing keys in the appropriate order on my keyboard.

The book was originally named Build-First JavaScript Applications, which was pretty confusing. After a call where we first discussed the topics I’d be writing about in the book, I put together a formal proposal, where the description still roughly matches the book in its current form.

Book Description

Build-First JavaScript Applications has a two-headed mission. It will teach the reader how to tackle application development using a well thought-out build process from the get-go. On a second level, readers will gain insight into applying these concepts to JavaScript and Node applications.

The book sets the bar with a section about build processes. The reader will learn what a build process is, and why he should be interested in implementing one. He’ll be introduced to tasks, environments and deployments, and learn how to keep a productive development environment.

A second section of the book focuses on managing complexity in JavaScript, introducing topics such as asynchronous programming and dependency management. We’ll look at keeping our code testable, and learn strategies for testing our modules.

These concepts are put to test in the third section, application design. This section will describe and design a moderately complex application, and guide the reader through its development. Eventually, we will have applied all the knowledge gathered in the previous chapters into a tangible application that can be accessed online, and the reader will have embraced that knowledge.

The table of contents has been reworked quite a bit by now. Node has been relayed to the background, mostly regarded as a dependency for Grunt. However, parts of the book which require a back-end use Node for that. Deployments are also explained using Node. Testing, however, is mostly dedicated to front-end efforts.

Etcetera

There’s a lot more coming, and I couldn’t be more thrilled to see this project moving forward! I’m sure I’ll write an update about the book as I make progress through parts II and III in the book. I’m really happy with the feedback I’ve read so far on Twitter, HN, et al. I hope the feedback keeps pouring in!

If you want to comment on anything related to this project, you can email me at buildfirst@bevacqua.io, or just drop a comment here.