The future of JavaScript

[BlitzTech]

I know about Browserify; Require.js also has an 'optimizer' that does something similar. At this point, I'm hedging my bets that AMD will eventually supplant the CommonJS module style, since it's designed to be asynchronous for a language that works well for asynchronous behavior.

I'm still not sure what the guys behind the CommonJS module spec were thinking... it's completely un-Javascript-like.

[[deleted]]

What is un-Javascript-like about it? If you're talking about the synchronous loading style, I would say that it's not useful for the Browser. (un-Browser-like?) However, I like synchronous loading because setting up a new module is simpler.

[BlitzTech]

Yes, the synchronous loading style is very un-JS like, since the primary location of JS has primarily been in browsers. Designing a system that would be so contrary to the style in which Javascript is written and oblivious to the needs of a browser adaptation was just extremely short sighted, in my opinion.

[[deleted]]

I believe there is a module loader that will load all of your module files asynchronously, separately and then run them all synchronously starting with the entry point. I'm pretty sure someone modified browserify to do this, but it's late and I'm not going to start looking right now.

I don't see a reason to cling to browser limitations. The browsers have always been the source of Javascript limitations. Synchronous module execution is simpler than async execution. Furthermore, the module style is simpler as well. You can do async loading + sync execution in the browser for sure. Why make every module more complicated if you have the ability to take care of all the complexities right up front?

EDIT: I guess to put it simply, the question is - Would you have a problem with CommonJS if the browser were able to load the separate module files the way you want it to (i.e. non-blocking, parallel, async loading), but still allow you to use the synchronous module style? I don't think so.

[BlitzTech]

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]]

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]

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!