On Human JavaScript

I just read Human JavaScript by Henrik Joreteg. It’s available as a $39 ebook, but you can also read it online for free.

Some context is important. Mr. Joreteg defines a web app:

  1. They are separate from the API.
  2. They don't work at all if someone has JavaScript turned off.
  3. A modern browser with a modern JavaScript engine is a minimum system requirement.

And so on. He separates this API – the data, business logic, authentication, etc. – from the client, which could be a native iOS or Android application. Or, of course, something that runs in the browser. He also remarks on the concept of “real time,” and its effect on users’ expectations:

Facebook with its chat, live comments, and push notifications is already conditioning an entire generation of users to expect realtime updates. I believe that knowing how to build realtime apps is a crucial skill for web developers who want to stay at the top of their field.

Unfortunately, a majority of the book delves into implementation examples with Ampersand.js, &yet’s modular fork of Backbone.js. The foreword was written in September 2013, so it’s understandable that the content is a bit dated. Nevertheless, here’s what I gathered:

  • A team should strive for consistent, readable code. precommit-hook is suggested to codify this practice.
  • Continual refactoring is essential:

    Entropy is inevitable in a codebase. If we don’t continually modify, simplify and unify the existing code along with the new code that’s being written, we can easily end up with a really big, messy app.

  • Views and state should be separated. Don’t tie state to class names:

    Your view (the DOM) should just be reacting to the model state of your application.

  • Investing in tooling is key. Mr. Joreteg suggests moonboots for running a development server, templatizer for shipping compiled templates to the client, and clientconfig for retrieving application configuration on the client.

  • A sane directory structure is important. He outlines his preferred folders in Chapter 4, but I think a team-wide agreement is the most important thing. It could change from application to application.

  • He hangs important functionality on a global app variable, and relies on CommonJS modules for nearly everything else. For example, navigation is an application-level concern, so he adds a app.navigate(url) method that defers to the router. Certain frameworks are more prescriptive than others, of course.

  • Event-based architecture makes for a good way to decouple modules, keeping code simple:

    Exporting objects and classes that inherit from some type of event emitter means that the code using your module can specify what they care about, rather than the module having to know.

  • Models are a good way to encapsulate data:

    The idea is simply that we create some data structures in the browser, separate from the DOM, that hold the data that we got from the server as well as any client specific data or state.

    He advocates putting view and session state information on the model itself, which seems questionable. But, MVVM.

As someone who’s interested in newer, better technologies (like React and Ember) this book doesn’t completely serve my needs. Surely Mr. Joreteg has knowledge that transcends a particular library; a book that focuses more on best practices and patterns would have been a stronger work.

But, it’s a quick read. I find the fact that the &yet team builds its own tools quite inspiring. And, if you’re looking for a primer on Ampersand.js, it’s the best.