5 ms·

If you're using a bundler and transpiler, ES modules are already in strict mode.

nailer 10y ago
Like most folk I don't use TC39 modules, just npm/commonjs modules. I guess when/if npm and node (and all the frontend tooling that uses npm and node) starts using TC39 modules they'll get popular.
- z3t4 10y ago
  Es6 modules suck because they will litter the global scope, while commonjs/nodejs modules can be required locally.
  - allover 10y ago
    ES6 modules are great because they're statically analysable, whilst CommonJS modules aren't.
    - z3t4 10y ago
      just parse it like any other js code
      - tomatsu 10y ago
        Declarations can be analyzed statically. Declarative stuff is convenient that way. If you have to execute code, things get messy.
      - allover 10y ago
        By that do you mean you can 'just parse' CommonJS modules? (If so) CommonJS allows you to dynamically alter module.exports anywhere within your module. You can't determine what those exports are just by parsing, you'd need to execute the code.
        nailer 10y ago
        > CommonJS allows you to dynamically alter module.exports anywhere within your module It's certainly a risk, but that isn't a common practice.
        z3t4 10y ago
        There's also ... if(Math.round(Math.random()) === 1) { export let foo = bar; // have fun debugging! } I think it would also be fine to execute modules to see what's in module.exports, while some modules might have side effects like writing to /etc/passwd without calling any method, it's not the norm.
        allover 10y ago
        > There's also ... [...] (I assume you meant to write your example in CommonJS style, because that's not valid a ES6 export, they must be top-level). Doesn't your example highlight exactly why even executing the code wouldn't even help you there?
        z3t4 10y ago
        Didn't know you could only export at the global scope. Wanted to show that you could do stupid, hard to analyze things in ES6 modules too. But maybe you can't !? Although I don't want a committee to not only decide what is stupid or not, but also hard code it into the spec so I can't do some things even if I have very good reasons to. Like being able to require modules locally to make the code easier to reason about, and easier to delete, copy, share, reuse and manage. It's what made NodeJS so popular, because it's so easy to use, reuse and share modules.
        bakkoting 10y ago
        > Wanted to show that you could do stupid, hard to analyze things in ES6 modules too. But maybe you can't !? You can't, at least not in this way. A module's imported and exported names are statically determined. Of course, you can just export a single object, and then make that object arbitrarily complex depending on runtime behavior. > Like being able to require modules locally Not sure what this means.
    - lhorie 10y ago
      You can statically analyze CommonJS modules (and they are most often used in a statically optimizable way), they just aren't statically optimizable in the general case.

Like most folk I don't use TC39 modules, just npm/commonjs modules. I guess when/if npm and node (and all the frontend tooling that uses npm and node) starts using TC39 modules they'll get popular.

z3t4 10y ago
Es6 modules suck because they will litter the global scope, while commonjs/nodejs modules can be required locally.
- allover 10y ago
  ES6 modules are great because they're statically analysable, whilst CommonJS modules aren't.
  - z3t4 10y ago
    just parse it like any other js code
    - tomatsu 10y ago
      Declarations can be analyzed statically. Declarative stuff is convenient that way. If you have to execute code, things get messy.
    - allover 10y ago
      By that do you mean you can 'just parse' CommonJS modules? (If so) CommonJS allows you to dynamically alter module.exports anywhere within your module. You can't determine what those exports are just by parsing, you'd need to execute the code.
      - nailer 10y ago
        > CommonJS allows you to dynamically alter module.exports anywhere within your module It's certainly a risk, but that isn't a common practice.
        z3t4 10y ago
        There's also ... if(Math.round(Math.random()) === 1) { export let foo = bar; // have fun debugging! } I think it would also be fine to execute modules to see what's in module.exports, while some modules might have side effects like writing to /etc/passwd without calling any method, it's not the norm.
        allover 10y ago
        > There's also ... [...] (I assume you meant to write your example in CommonJS style, because that's not valid a ES6 export, they must be top-level). Doesn't your example highlight exactly why even executing the code wouldn't even help you there?
        z3t4 10y ago
        Didn't know you could only export at the global scope. Wanted to show that you could do stupid, hard to analyze things in ES6 modules too. But maybe you can't !? Although I don't want a committee to not only decide what is stupid or not, but also hard code it into the spec so I can't do some things even if I have very good reasons to. Like being able to require modules locally to make the code easier to reason about, and easier to delete, copy, share, reuse and manage. It's what made NodeJS so popular, because it's so easy to use, reuse and share modules.
        bakkoting 10y ago
        > Wanted to show that you could do stupid, hard to analyze things in ES6 modules too. But maybe you can't !? You can't, at least not in this way. A module's imported and exported names are statically determined. Of course, you can just export a single object, and then make that object arbitrarily complex depending on runtime behavior. > Like being able to require modules locally Not sure what this means.
  - lhorie 10y ago
    You can statically analyze CommonJS modules (and they are most often used in a statically optimizable way), they just aren't statically optimizable in the general case.