Const(ant) Craving

“Humans avoid change unless they see immense and immediate personal benefit. const isn’t about personal benefit or immediate benefit. It’s about long term benefit to others—those that read your code.”

Prologue (before const)

While const has been available in both Chrome (20) & Firefox (13) since summer 2012, it didn’t become part of my core JS vocabulary until Mr. Schlueter announced Node v0.10 in the spring of 2013.
I’d seen const on MDN when I was still using Node v0.6, but:

  1. I wasn’t eager to fill my JS with the constraints I had when programming for iOS (types, static, private, et al)
  2. I was introduced to isomorphic JS early on and didn’t want to use transpilers for client-side code for what amounted to a minor readability aide

Why I Turned to const

In 2013 I started to not only use Node.js for important production apps, but I began preaching the good word of proper Node.js programming to Sony employees in both San Diego, USA and Tokyo, Japan. Being tasked with teaching, as well as producing modules that’d end up maintained by others, led me to reach for new levels of readability in my JavaScript code. My journey toward the ultimate readability lead to increased specificity in several areas of my code. Many of these were informed by things I read during my days as an iOS programmer. My colleagues at Sony had plenty of input as well. Examples include:

  1. Naming variables in such a way that, if entered into Google Translate, would make sense in another language. I was teaching Japanese developers that weren’t fluent in English, and this is just a good way to train yourself to write meaningful variables for folks that speak English as a first language as well!
  2. Always, always, always putting requires, constructors, prototype declarations, exports and other common statements in the same place in each module
  3. Taking (what I would call) full advantage of linters and style tools
  4. Endeavoring to unite approaches between client and server. This led to several new practices, but Browserify was perhaps the most important of those
  5. Creating or consuming documented modules for all repeated tasks. From checking if something is an Array, to connecting to a CouchDB instance, let’s keep things DRY, sharable & effortlessly learnable
  6. Most importantly, an overall guiding principle. That is, always side with code decisions that lead communicate more information over code decisions that decrease typing effort or simply impress others in their syntactic athleticism

Make Nostradamuses Out of Your Team (or how to write predictable code)

Nostradamus Yodamus
Number 6 above is where const comes in. Quite simply, var makes code harder to read (harder to predict) than const does. JavaScript developers have (unfortunately) often misused var by re-using pointers like it’s 1982 and they need to hoard them like Qualudes in Jordan Belfort’s basement. The result is, when you see foo somewhere, it’s pretty tough to know if it’s what it was when var foo = 'FOO' or something else it got assigned to somewhere else in your app’s codebase. With const, that’s not true. While that is a seemingly minor change, the culmination of using const everywhere that it’s appropriate is that your entire app is more predictable. It is, in part, for this same reason that using immutable data structures makes code more readable.

The Little Revolt (against constants in JavaScript)

Most JavaScript developers, even those at the top of our industry, have been using var exclusively for a long time. Thus, my practice of using const has met some resitance. And hey, it’s natural. Humans avoid change unless they see immense and immediate personal benefit. const isn’t about personal benefit or immediate benefit. It’s about long term benefit to others—those that read your code. Anyway, I’ve consistently heard a small set of arguments against using const. They are:

  1. What if I want to change the value later? I want my pointers to stay flexible
  2. const doesn’t freeze the object. That’s confusing!
  3. const is harder to type than var
  4. Won’t const fail on most browsers?

The Rebuttal

Each of those arguments / questions are unbelievably easy to address. In order:

  1. a) We don’t program for “just in case” b) You can create a new pointer or change const to let later
  2. That’s a fundamental misunderstanding of computer science / how memory works. Ignorance of the law is not an excuse ;)
  3. Really? If you will never have your code read by someone else, then feel free to save yourself 2 chars a line :)
  4. This is the most valid question. If you’re programming for Node, just use it. It works at least as far back as v0.6. Any remotely recent version of FF or Chrome supports it, but IE didn’t support it until 11. Now if you’re using any ESNext|ES6 features via Babel or related tools, you can certainly use const as well


Strict mode

It’s important to note that, in some JavaScript engines, you need 'use strict' to be off to use const, in some engines you need 'use strict' to be on! The good news is, your chosen JS engine will loudly let you know when this is the case either way.

To SyntaxError is to be human

In most engines const initially didn’t throw a SyntaxError when you attempted to reassign to the pointer! The assignment statement would return the value you attempted to assign as if it worked, but when you accessed the value the const actually points to, it’d be the original value.

(As)sign on the line

It’s specified that a const statement must contain an actual assignment, unlike let and var statements, which can be empty. In earlier implementations of Firefox’s Spidermonkey (and perhaps other engines?), an error was not raised when a const declaration didn’t end with a value assignment.

Hopefully this has explained why I have Constant Craving!
K.D. Lang

Falcor & why you should care about your Bithound score

Falcor has been extremely successful.

Falcor core was immediately considered one of the main JavaScript modules and it’s sister modules are well-liked as well. As part of helping Falcor be as successful as possible, I want to raise awareness of Bithound scores (which are already being used by the Falcor project), and point out why they matter.

What influences your Bithound score?

  • The security of packages used
  • Adherance to semver (Falcor doesn’t adhere)
  • (Up|Out)dated packages
  • Adherance to consistent style
  • Whether or not issues are addressed within a timely matter

  • Most everyone knows the above are important to the success of an open source module.

Weaknesses of the Bithound score (Falcor’s score should be higher)

While all of the above are important, they are less important (by far) for devDependencies than for dependencies proper. While Falcor locks down the few deps it has (this is shockingly rare but good on the Falcor team), dev deps are with the caret and some of the modules used are way out of date. In other words, I think the Falcor score should be higher than it is.

We should still improve the little things that matter

In terms of adherence to Node & NPM best practices however, Falcor core can improve. A quick comparison using Bithound.

Falcor Path Utils (another falcor project)

KeyKey (an insignificant project of my own)

Falcor core

Size is part of this, and stats aren’t everything. However, in my modules I’ve found a strong correlation between my maintenance of them and what the Bithound score ends up being.

I’m going to open some issues & PRs to address this, and I encourage other, both inside of Netflix and without, to do so as well.


Failure to Componentize (plus Stylescope & ModCSS)

Back in Aug 26 2015 I posted hopefully about the future of web components in Netflix’s Digital Supply Chain. Since then, all fans of the open web have sided with expediency (and therefore React). You can’t stop the mob’s forward march :). Seeing this coming a year ago, I offered Reactive Elements as the virtually cost-free way to bridge the gap ‘tween React and WC, but interop be damned I guess. The group recently had the joy of bringin’ on Tim Branyen from Bocoup—I hope he’ll help folks “see the light”.

Scoped CSS

As a side note, I’m developing an answer to one of the main open questions. It’s tentatively called Stylescope and serves as a more traditional (but versatile) companion to ModCSS.


ModCSS assists in modularizing styles by enabling CommonJS-like system to pull in Stylus or CSS files as JSON. The primary use so far in Netlix has been assigning to style in JSX.


Stylescope assists in modularizing styles by enabling one to reliably assign style information to an HTMLElement with 100% security that style won’t affect other elements. The pain of an Enterprise front-end developer attempting to add their own flair to a large CSS cascade is traumatizing and I’m here to prevent others from experiencing the same fate :)

Stylescope is early alpha, but it already works well for one-deep style trees in its Mochify tests. For next steps, I plan to demonstrate distributing and sharing styles via ModCSS and then consuming them in a Web Component via Stylescope. I’ll need to locate a module containing all viable HTML tags to implement parent-child style relationships in Stylescope…

Hello Japan

We changed a few things at to prepare for our new Japanese friends:

  • Image-Based Subtitles to support vertical text, furigana (rubies), bouten (emphasis). This also sets us up for subtitles in other languages that don’t use a Latin script
  • On-Screen Keyboard for Darwin (user selects kana, yielding kanji suggestions)
  • Search tokenizes input (no spaces in Japanese), normalize to two possible search scripts
  • Typographic differences (bold and italic not used)
  • Multi-Language box art
  • Metadata length
  • First / last name order in sign up
  • Studio Copyright attribution

Points written by Joubert Nel

Weberize ALL the components

Some folks in Netflix’s Digital Supply Chain have agreed that Web Components are a good interop container. I also (perhaps controversially) believe people should also use WCs whenever effective as it’s simply native to the web. Telling someone to not use WCs is like telling someone not to use document.querySelector or Array::forEach. The war against React zealots is treacherous and ongoing.

Asynchronous communication

I was at a company called Amco a few years ago. It was my first Senior position outside of running my own company. The VP of Engineering there (Jason King) taught us something he called “asynchronous communication”. It’s the concept that sharing information globally and digitally is more efficient than individually & physically. By sharing with more people, and in a way that they can respond as convenient to them, you optimize the quality and quantity of feedback you can receive. When everyone does this, it make everyone better. It definitely made me better and I think Netflix will get better if we all start practicing asynchronous communication. Ways we can do this are:

  • Remote pair programming tools that support multiple people
  • Google Docs
  • Frequent pull requests

Viewing images right inside iTerm 2.9

Call me crazy, but viewing images from a CLI app can be pretty cool.
Yes, we have the ancient art of ASCII (and that will not go away)
but why not use a real image in some cases?

Now the nice folks behind iTerm 2 have made that possible in versions
of iTerm post-2.9. I do not claim this has not been done before, but
I am unaware of this capability in Terminal. Anyway, on to the goods:

Steps for ZSH Users

[ iTerm & ZSH, great together ]

  • mkdir ~/Projects/iterm/imgcat && cd !$
  • wget
  • wget -O hacf.jpg
  • Change $PATH to include ~/Projects/iterm/imgcat
  • Reload your shell
  • imgcat hacf.jpg

Halt and Catch Fire


Hello friends! Are you tired of this message:

There is no tracking information for the current branch.

I am too! So I searched the OhMyZSH repo for set-upstream-to and re-discovered this command: ggsup. Calling ggsup with the name of the branch you want to track will get you to the place you want to be. W00t!

To recap. Call

ggsup master
``` track `master`. Call

ggsup dev
…to track dev. Get trrrrrracking team!

Definition: The Zone (Programming)

(The) Zone


The state in which all resistance to progress is non-present. Easy flow of information from subconscious to conscious mind, characterized by clarity of purpose, speed of achievement and the full architecture of your project being held intact at the front of your mind. “Peak zone” is typically sustainable for 2-4 hours but takes 15-30 minutes to “boot up” into and is easily knocked down like a deck of cards if the “zonee” is disturbed by someone outside the zone.

Dev Letters: TMZ for Developers

Some of the most useful and lasting content has come from letters between colleagues. In this tradition, I
will post some developer insight that’s shared between myself and other developers.


You’ve sent out some good stuff lately [on our JavaScript DL]. What’s your source? Is there a site I can check daily—a TMZ for developers?


  1. I’ve decided to share even when I’m really “in the zone”, whereas previously I shared when I was bored
  2. I make liberal use of IFTTT. I let the computers monitor the web and ping me when something “interesting” happens. E.g. I have Facebook’s Github profile monitored for new repos
  3. I listen to the “5 Minutes of JavaScript” podcast. 3/4 of their content is too junior, but the 1/4 that’s not is worth it