8 ms·

> the synchronous loading and node-style resolution doesn't work well over a network answered below in https://news.ycombinator.com/item?id=11491590 https://ne

> the synchronous loading and node-style resolution doesn't work well over a network answered below in https://news.ycombinator.com/item?id=11491590 https://news.ycombinator.com/item?id=11491590 > and the scoping doesn't work out-of-the-box in a browser sorry, didn't get you on this one. Example? > Tree-shaking and static analysis are only possible with CommonJS/AMD if you strictly limit them to declarative-style use: imports at the top-level only, exports as a literal, etc. Deviate from that and tools trip up. In that case, it's better to have a new, clear, declarative-only syntax. Agreed with the former part, but I am not sure how the new syntax is better and clear. Infact the new syntax imposes limitations. The old regular would just not optimize in some cases. You won't lose anything or any optimization. Further, the "top-level" only is a bit of an itch. I want to be able to do this: if (DEBUG) { import 'something'; } which is a common usecase and something the builder can easily remove at build time. But ES treats that as a syntax error. The "old" way doesn't have this limitation. Surely the builder's grammar can be extended to support this with the new syntax, but it just feels more magical and weird. You/someone might very well have an answer for that - honest question, not mocking :)

nostrademons 11y ago
Replace your debug versions of libraries with stubs that contain no-ops. So in your code, just do: import 'something'; And then create separate versions of 'something.js' for debug and release, where your release version just has stubs: export function debugPrint(msg) {} While the debug version might use console.log or winston or whatever. If you compile your JS and the compiler provides tree-shaking, the calls will get optimized out entirely. Even if you don't, you can deploy the no-ops to prod and it'll use minimal bandwidth and no CPU time. And the best part is that it keeps the syntax of your code very clean; you don't have to litter your code with "if (DEBUG)", you just have it do what it needs to and those calls will equal doing nothing in prod.
- drewgross 11y ago
  (Not OP) Usually when I am using this technique it's for some 3rd party library that provides a useful debugging tool. To use your suggestions I'd need to create a wrapper that calls through to the 3rd party library in dev. Sounds like a huge pain.
  - WorldMaker 11y ago
    You should be able to use Loader config for some of this: With the right plugin to your Loader you could do things similar to AOP/injection in debug/dev with a suitably complex Loader or set of Loader plugins. Arguably things like this are part of why standardizing the Loader APIs has been so complex. But eventually it may pay out by letting you do some nice things very simply and in a way that is configurable for different environments and also transparent from your configuration how complicated or not your libraries and plugins may be set up. (Whereas dynamic rewriting in memory and dynamic loading and lots of scattered if() blocks can feel much more opaque.)
colinramsay 11y ago
You'll be able to do that with System.import, kind of. It's async, and it returns a promise, which is sensible but it makes code a bit more complicated. The ECMAScript wiki appears to be down but this polyfill has a good overview: https://github.com/ModuleLoader/es6-module-loader https://github.com/ModuleLoader/es6-module-loader

nostrademons 11y ago

Replace your debug versions of libraries with stubs that contain no-ops. So in your code, just do: import 'something'; And then create separate versions of 'something.js' for debug and release, where your release version just has stubs: export function debugPrint(msg) {} While the debug version might use console.log or winston or whatever. If you compile your JS and the compiler provides tree-shaking, the calls will get optimized out entirely. Even if you don't, you can deploy the no-ops to prod and it'll use minimal bandwidth and no CPU time. And the best part is that it keeps the syntax of your code very clean; you don't have to litter your code with "if (DEBUG)", you just have it do what it needs to and those calls will equal doing nothing in prod.

drewgross 11y ago
(Not OP) Usually when I am using this technique it's for some 3rd party library that provides a useful debugging tool. To use your suggestions I'd need to create a wrapper that calls through to the 3rd party library in dev. Sounds like a huge pain.
- WorldMaker 11y ago
  You should be able to use Loader config for some of this: With the right plugin to your Loader you could do things similar to AOP/injection in debug/dev with a suitably complex Loader or set of Loader plugins. Arguably things like this are part of why standardizing the Loader APIs has been so complex. But eventually it may pay out by letting you do some nice things very simply and in a way that is configurable for different environments and also transparent from your configuration how complicated or not your libraries and plugins may be set up. (Whereas dynamic rewriting in memory and dynamic loading and lots of scattered if() blocks can feel much more opaque.)

colinramsay 11y ago

You'll be able to do that with System.import, kind of. It's async, and it returns a promise, which is sensible but it makes code a bit more complicated. The ECMAScript wiki appears to be down but this polyfill has a good overview: https://github.com/ModuleLoader/es6-module-loader https://github.com/ModuleLoader/es6-module-loader