ModuleImport

Brian Di Palma offler at gmail.com
Fri Jun 27 10:46:46 PDT 2014


I'm echoing Kevin here.

I'd hope ES6 modules would offer me, a programmer working on large
complex JS web apps, something more then what CommonJS/AMD offers.
I work with codebases of 1K+ JS classes, 200K+ LOC and with many
dependecies that are updated frequently.
When our teams update depedencies the more static fast failures we can
get compared to silent bugs the better.

I will eat my hat if in 10 years people will be doing greenfield
development using CommonJS/AMD instead of ES6 modules.

Provide the language users with something *better* then what we have,
don't just match it.

I like CommonJS, npm, node as they offer great solutions given their
constraints.
This is the language level though, the expressive power and
constraints are different.

Knowing the name of a module export is not an issue, it's not an issue
for people using global scripts or any other module systems/languages.
I'd prefer a "real" module system.
Especially considering that classes are being added and when you are
building front end applications with a lot of state classes fit well.
I can see many applications being mainly composed of modules with a
single class exported and the most logical export name would be the
classname.
I've tried to use default exports for these situations and they don't
seem to offer much value at all.

import {MyClass} from './myclass';

The value of default exports seems low here.


More information about the es-discuss mailing list