Optional Strong Typing

David Bruant bruant.d at gmail.com
Sat Aug 24 04:57:21 PDT 2013

Le 23/08/2013 19:38, J B a écrit :
> So the defacto response for large scale JS development will always be: 
> Use X?
Even if so, why would it be a big deal?

Just to clarify a point, I read interesting definitions of what "weak", 
"strong", "static" and "dynamic" typing means [1]. Not sure how they are 
grounded with more formal definitions.
Anyway, according to this definition, JavaScript is dynamically strongly 

I imagine your question is then "why can't we have optional static 
typing in JS?". And I'm not entirely sure what the benefits would be for 
the entire language. Static typing has huge benefits at development time 
(early errors, errors more meaningful than "undefined is not a 
function"! Had a 5 week experience with TypeScript on a real-life 
project that'll ship soon. That made a difference). The downside of JS 
types is that JS engines will have to verify them and that adds to total 
runtime cost, especially load time, which we don't need to be slower 
than it is now (something about a 1000ms time to glass barrier [2]).
Just to be clear, the main problem isn't JS engines ability to compile 
JS with optional static type, but more our practice to load too much 
code (that will have to be verified before running). Hopefully that 
trend will change, but the web isn't ready to add another static 
verification step I believe.

If the JS engine had knowledge of static types, *maybe* they could go 
faster (after the slower load time). But how much faster? Current JS 
engines go really fast after doing type inference when the code is type 
stable. The interesting part is that the instrumentation/JIT-compilation 
costs only for long-running code (and not all the code we've loaded! 
especially not the unused paths!!), but practice shows that the cost is 
very small compared to the gains it provides.

On a related note, I've recently been asked whether TypeScript compiled 
more efficient JS (cc'ing Luke Hoban to be sure I'm not spreading 
misinformation). My answer was that no, it doesn't by itself. TypeScript 
is very respectful of the input JS (and that's a feature!). However, the 
JS subset the TypeScript compiler encourages to write to has stable 
types and has a very strong chance to run faster in current engines.

An interesting approach to static typing is asm.js. The interesting part 
is that the statically compiled part is very localized (and not 
whole-language-scoped), so its cost is localized. Brendan suggests [3] 
that ahead of time compilation can only provide better performance. I 
wonder what's the cost of the static verification is and how much it 
hurts load time. I'm especially wondering whether this cost will not 
hurt performance too much when people will load lots of unnecessary 
asm.js code (cc'ing Dave Herman in case he has answers on that topic), 
which is obviously not measured by current benchmarks.

Anyway, whole-language static typing sounds like a bad idea and "use X" 
seems to be to good way forward. The compile-to-JS battle has just 
started. Let's be patient.


[2] https://www.youtube.com/watch?v=Il4swGfTOSM

More information about the es-discuss mailing list