Moving To MRN

I’m very excited to announce that I’m joining the web team at the Mind Research Network as a software engineer. MRN is non-profit focused on academic research of mental illness and brain disorders. They’re based in Albuquerque, New Mexico, but I shall remain in Portland as a remote employee.

These transitions are always tough. I’m leaving Electric Pulp, one of the oldest web firms in the country. I recognize this last year’s projects to be some of my very best. I’m fortunate to have met and worked with such talented people.


Client work can be wearying. Constant context changing, rapid timescales, concerned clients…it’s a lot of things to juggle. There’s rarely a chance to revisit and improve on old work. Agency front-end developers build up a very particular set of skills: proficiency typically results in less challenging work. I’ve done it for four years, and I’m ready to try something new.

What Now

MRN’s web team works on a researcher-facing web app that’s fairly large and, frankly, showing its age. The team plans to restructure the app and update the design. I’ll help by fixing bugs, testing code, and developing front-end features (thus the recent JavaScript reads). I’m especially thrilled to put my design experience to use and assist with user interface design. There’s much to do, and I’m excited to get started.

Jeremy Keith on the Style Guide Podcast

The Style Guide Podcast, hosted by Anna Debenham and Brad Frost, is quickly becoming one of my favorites. They interview designers from organizations and teams that utilize, predictably, a style guide in their work.

The most recent episode features Jeremy Keith of Clearleft. It’s great episode because Jeremy is able to profoundly put into words the struggle of designing for web in the present day. While I highly suggest listening to the entire episode (41 minutes), here’s part of the conversation that I found particularly provoking (starting at 11:55):

Anna: Do you tend to work straight in code, or do you kind of come up with mockups first and then get them built?

Jeremy: There’s nearly always mockups first. I guess the question is how long you spend refining those mockups…

There’s three reasons a mockup could exist. One is that it’s for buy-in. It’s basically for sign-off. You’re mocking something up to present it to a decision maker who then says thumbs up or thumbs down…

Use number two is its a deliverable for a front-end developer, so in other words it’s something a visual designer gives to a front-end developer to get turned into code. That’s a separate use case. Now here’s problem number one is that mockups made for the first use case end up getting used for the second. So if you’re designing for sign-off everything’s perfect. Everything lines at the top and the bottom…everything looks beautiful…Well, everyone’s just going to get disappointed, right? The developer’s going to get frustrated because it’s not accurate, the designer’s frustrated because, “hey, that doesn’t look like my mockup,” and the client is frustrated because that doesn’t look like what they were presented with…

And then there’s a third use of a mockup which is for a visual designer to think…they have a tool that they’re comfortable with, like PhotoShop, Sketch, Illustrator, whatever, and its the fastest way for them to get ideas down is to create a mockup.

I think that’s extremely insightful. Everyone agrees that a mockup isn’t the website, but this artifact has different purposes in the process. Jeremy continues:

They’re three very different use cases…[A]nd yet what happens is a single mockup will end up kind of doing all three…

So this is the problem…we found in general is that there’s this mismatch, I guess, of expectations. And this is why I love Dan’s [Mall] idea of deciding in the browser…Yeah, you do stuff in PhotoShop or Sketch or whatever you’re comfortable with. It’s more about that third use case, use whatever tool is comfortable with you. But you don’t go to the client and say approval or not approval until you’ve got it in web browsers until you’ve got it in code. Because that’s just so much more accurate to reality.

Wow. Jeremy puts into words the things that we struggle with so well. While even he admits that they’re still refining their process, I think it’s a step in the right direction. The approach sounds more true to the medium.

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.

On JavaScript Enlightenment

Keeping with the theme of JavaScript books, I recently read JavaScript Enlightenment by Code Lindley. He writes:

It was my intention to write a book to give the reader an accurate JavaScript worldview through an examination of native JavaScript objects and supporting nuances: complex values, primitive values, scope, inheritance, the head object, etc.

Indeed, the book is all about objects. O’Reilly released the first edition in January 2013. It targets ECMAScript 3, which is becoming increasingly outdated. However, a lot of the book’s content touches on the fundamentals of the language. It’s still relevant, especially for beginners. Here’s my thoughts and learnings:

  • Mr. Lindley shows many examples with primitive constructors (String, Number and Boolean). This can be confusing, because these aren’t often seen in the wild. Using them can have unwanted effects:

    var myString = new String('hello');
    console.log(typeof myString); // "object"

    JavaScript uses the String primitive in the background to coerce strings to act like objects, which is why one can write myString.length.

  • Constructor functions are unique in that they return an object (unless otherwise specified.) JavaScript makes the object behind the scenes; this in a constructor is that object.

  • The book drills home the importance of the prototype chain. All the complex values inherit from Object. Mr. Lindley writes:

    The Object() constructor function in JavaScript is special, as its prototype property is the last stop in the prototype chain.

    Therefore, it’s bad form to alter Object’s prototype.

  • Using the Function() constructor doesn’t create a closure. Fun, impractical fact.

  • A function’s length property is the number of expected arguments.

  • This is a self-invoking function:

    !function sayHi(msg) {console.log(msg);}('Hi');
  • Regarding the “head,” or global object:

    Being explicit [e.g., window.alert() versus alert()] costs a little bit more with regards to performance…It’s faster if you rely on the scope chain alone.

  • Here’s a concise version of inheritance with constructors (page 101):

    var Person = function (){ = 'bar'}; = 'foo';
    var Chef = function(){ = 'goo'};
    Chef.prototype = new Person();
    var cody = new Chef();
    console.log(; // logs 'foo'
    console.log(; // logs 'goo'
    console.log(; // logs 'bar'

    Setting Chef’s prototype to new Person() is what makes inheritance possible. ES6’s class and extends is syntactic sugar for this pattern.

  • The null type in JavaScript is meant for a placeholder on object values. Running typeof null results in object.

Overall, the book reinforces important facts about objects, prototypes and inheritance in JavaScript. The writing is easy to understand, and it’s a fast read. It’s a great starting point and knowledge refresh on the language.