> Static checking will be limited anyway. If you want to go this way you shoud > use typescript.
If you don't want static checking you should stick with ES3. Fixed that for you. Yes big projects are possible with JS, I work on them everyday. It would be nice if the language made them easier, that's what we are talking about. Big projects are possible with C, why bother with any other language? With sufficient rigor Assembly will do the trick. Just have good code reviews and test. > ability to dynamically import modules in addition to static imports. IMO this > should be packaged as an async API I think this is already possible using the loader. > hooks for transpilers. This should also be an API Ditto. > Usually, I obtain the same benefit running the tests (and more, test that > were the product of TDD workflow) I can forsee many people writing tests where they configure the module loader to load mocks instead of true dependencies. This could result in tests passing while there is a breakage in the application. If the language can make some of these problems go away then we are better off. It's just like tests, code review and linting, it's another type of verification. > I think that a possible compromise that can still make the ES6 module system > more compatible with both AMD and CommonJS modules The ES6 module system is compatible with CommonJS and AMD, I'm happily mixing the two together with libraries like SystemJS https://github.com/systemjs/systemjs/ For example https://github.com/briandipalma/flux-es6/blob/master/src/Store.js The Emitr class here is imported from a CommonJS module > It is important to focus the design on loader issues and keep things > orthogonal. The Loader is quite solid and well designed, I've not heard any major issues with it. What does it have to do with this discussion? > import {foo} from './foo'; > var foo = require('./foo.js').foo; I though those two statements weren't comparable? The import statement can only be present at the module top level while the require can be written in any code block. That leaves it open to the random number require issues which makes static checking impossible. As you pointed out it's not a language standard so I'd imagine that's another reason why tooling is so weak. > Rather than point towards type-checking, I think we should focus on the > actual checks offered by the module design. > It seems that these would come with a small cost quite unlike type-checking. Unless I'm misunderstanding Kevin I think we've both talking about exactly that. I guess people saw "static" and automatically added "type". Just static checking of import and export bindings. A much smaller scope feature then static type checking. This discussion has veered off track, it's about a new ModuleImport form, which grew into questioning if default imports/exports was the real problem. I'd be interested in knowing if it's possible that instead of changing the ModuleImport form the default import/export idea could be postponed instead. It could be added in later if there really was need for it. As far as I can tell libraries like SystemJS can smooth over issues caused by importing from legacy module systems like CommonJS and AMD. Leaving default imports/exports an odd third way to import that was added based on some notion of backward compatability that wasn't needed. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
