3 ms·
Well, the biggest issue with using "require" (commonjs) is it is by definition synchronous. That works okay for server side when files are accessible (not best
by matthewbauer 11y ago
Well, the biggest issue with using "require" (commonjs) is it is by definition synchronous. That works okay for server side when files are accessible (not best practice though) but it gets really difficult with network resources. JS modules are supposed to be a way to get the advantages with aynchronous module loading (as in require.js) without all of the callback hell.
- awalGarg 11y agoAgain, that is just an issue with the current implementation of the commonjs require. You can, for example, have a require implementation which runs your code inside a `GeneratorFunction` instead of a regular `Function` and use `yield require(...)` instead of just `require`, where `require` returns a promise and is async, and use something like `co` or bluebird's `coroutine` etc.. There is also AMD which is by definition async and gives you the same static export/import as ES6, leave for the new syntax. It really is just that JS land hacked up something together and it worked great. Had the community went to lengths as much as people in the TC, we would have had much better everything, but it is a problem already solved enough that people don't care much.
- esailija 11y agobut you would still have to be executing the file as code before knowing what it will require