We don’t need no stinking prologs!
Part of the proposal adds another prolog,
"use strong";, in addition to the current
Build Stronger and Smarter
Strong mode would automatically imply strict mode plus:
- Removing support for
var, instead using only
- Accessing missing properties throws
- Strong Objects are not extensible
classprototypes are frozen
- Arrays are non-sparse
calling with too few arguments throws
- No implicit coercion
These are potentially some fundamental changes to a lot of source code, but there is nothing I personally see in this list that I disagree with when you have the full benefits of ES6 and TypeScript. In many ways, using strong mode forces you to move your code towards ES6/ES2015 standards. For example, if you need a sparse array, you should be using
Map instead. If you want to mutate your classes after you have declared them, you are being illogical and you should be refactoring your code instead of plastering over cracks.
The second part of strong script is run-time types based on TypeScript’s type annotations. This is incremental opt in, in that if you assert a type, the compiler will enforce it at run-time. The TypeScript team have started looking at what it might take to pass through your TypeScript code so it can be emitted in strong mode. There are some challenges in that what the V8 team propose and the semantics of TypeScript don’t quite align, but hey, we all know how to iterate, don’t we?
Yes, but what is in it for me?
Many of the things that strong mode is proposing are already patterns we should (or could be) following. So why have the browser enforce them at runtime? Why not just have a linting tool check our code, because having code that throws an error at runtime is never a good thing as it is usually being used by someone who didn’t write it. Well, ultimately the
"use strong" prolog is a contract between the developer and the JIT compiler that says “I promise to not do anything silly” and therefore the JIT compiler can run your code through an optimized code path that performs faster, meaning better code. Consider not having to manage the
arguments variable on every function call, or not being entirely sure if someone is going to declare a
var on you or not. These are very tricky things for a run-time compiler to manage and tricky equals less performance.
So what is ultimately in it for the developer is better, faster, stable and more maintainable code. That can’t be a bad thing, can it?
Ok, you sold me, I want it NOW
You can experiment with both Chrome Canary, Traceur and Node.js (io.js 2.3+, Node.js 4+). In Canary, you will need to start it with
--js-flags="--strong-mode", with Traceur you will need to use the strong mode branch, and with NodeJS you will need to use the
The modern web is cool, but what do I do now?