ES6 modules are privileged over other module systems

[othiym23]

One of the properties of ES6 modules that the module champions use to sell the value of them is that they provide static checks upon import that a corresponding name has been declared for export. So if you attempt to import a name from a module that it doesn't export, that's an error at compile time, rather than deferring the check to runtime (where, to be clear, it would generally cause an eventual failure because the value of the corresponding name to be undefined).

This is interesting mostly because it's unusual for JavaScript, which will almost always take the dynamic (runtime) path when presented with a choice between static and dynamic behavior. It also shows that the ES6 module syntax is more than just sugar around a more traditional JS module pattern.

It looks like we were both right about the distinction between module compilation and module loading (or, looked at in a less awesome way, we were both wrong). In addition to module compilation and module loading, there's also module linking, which is when the static checks for conflicts and missing values are applied. All three of these stages happen at compilation time, though, which preserves the idea of fast failure on typos or other common errors and is a kind of behavior that can only show up if it's baked into the language at design time.

I think you're right that to get too into the details of modules would probably be beyond the scope of what you're getting at in your discussion of closures -> modules, but it might be worth pointing out that ES6 modules are different just by virtue of living inside the static semantics portion of the language, which (in part) justifies making them part of ES6 in the first place.

I should also point out, I guess, that I'm ambivalent about this aspect of modules, given that static checking of various kinds could be justified as useful all over the place in JavaScript. The primary rationale offered for making imports static is "If import declarations were resolved dynamically, then imported variables would be dynamically scoped. Harmony will not have any dynamic scoping..." which makes sense from a formal design perspective (David Herman and Sam Tobin-Hochstadt are meticulous when it comes to their PLT!), but still feels weird in the almost-always dynamic JS environment.

[getify]

Thanks for the suggestion! :)

My instinct after thinking about it is that I will add a simple note that mentions how modules provide extra verification checks which would be difficult or impossible to replicate manually, but not really dive into how that happens, or even particularly why.

If I do an ES6 title (I'm 50/50 on that so far), then this would deserve a full complete discussion.

[getify]

Actually, once I got to writing it, I figured a way to add more detail without being too deep or confusing. :)