Kevin Smith zenparsing at
Sat Jun 28 11:51:25 PDT 2014

>> Static checking of imports and exports has well-known advantages and
>> would help the long-term viability of the language.
> Enumerating these specific advantages would inform this discussion.  These
> advantages are not well-known. Many developers have experienced the
> disadvantages of complex systems of rules and thus favor simple solutions
> over ones with theoretical advantages. Explaining the benefits concretely
> would help them balance the well-known costs.

So pretty much everything in Javascript is dynamic, which is one reason why
IDE support for Javascript has always lagged behind.  You simply can't know
what anything is until you actually run the program.  Statically verifiable
exports gives us the ability to inspect and analyze code without having to
run it.  There are two big benefits that this affords us:

## Early Errors and Warnings ##

Let's say that you want to deprecate and remove an exported member from a
module within a large JS code base.  With static imports, the system will
generate an error at compile time if something on the other side of that
codebase is importing it.

For exported function declarations that use default parameters to indicate
optional parameters, we can generate build-time warnings when such an
function is imported and called with too few arguments.

For exported classes, we have even more static information at our hands.
 Without having to run the program, we know the number of arguments for the
constructor and we know the list of methods for class instances.  We can
generate warnings when we see an instance using a misspelled method name,
for instance.

## Computer Aided Coding ##

The information used above to generate lint-like warnings can also be used
to give the developer in-editor feedback.  Reliable code-completion for
imported function and class declarations becomes possible.  Again, for
exported classes we can also do code completion for instance methods.

These advantages may not seem like a big deal now, but imagine writing JS
in a large team five years from now.  Do you want the power of static
analysis at your team's fingertips, or do you want to be stuck with
"anything goes so anything can break" CommonJS modules?

Does that do it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list