“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)

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

Gotchas

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!