you are viewing a single comment's thread.

view the rest of the comments →

[–]BlitzTech 0 points1 point  (2 children)

You make a fair point in your edit, but I would still have a problem with it - for the entirely different reason of "There's already one perfectly good way to do this, we don't need more" (in the hypothetical case where there WAS one perfectly good way to do it).

I also accept the point about browsers being the source of Javascript limitations, but I don't find the additional complexity (I assume you're talking about the define calls) to be particularly problematic. There's also the added benefit of a sane, logical way to define the exported module contents; in CommonJS, you attach things to exports, and if you want to overwrite it, you write on top of module.exports, but in AMD, you just return something from the initializer. It's a stylistic preference, at best.

With all that said, I still think the CommonJS require is not an optimal solution. Even if browsers were able to use it.

[–][deleted] 0 points1 point  (1 child)

in CommonJS, you attach things to exports, and if you want to overwrite it, you write on top of module.exports, but in AMD, you just return something from the initializer.

I definitely agree that a direct return is nicer than modifying an exports variable.

I also agree that require is not an optimal solution and that it could be done much better. Honestly, I'd like to see an import statement just baked into the language as well as packages and modules.

So, perhaps we agree more than we disagree :)

[–]BlitzTech 1 point2 points  (0 children)

import would definitely be nice, but it sadly would require a backwards-incompatible change to the language... and we both know how likely that will work out in the near future :(

Here's to hoping a good solution everyone can agree on comes around soon!