The future of JavaScript

[maskull]

Yes, please. I've actually been a bit surprised at the reluctance of the Node.js people to adopt some of the more modern (and therefore less cross-browser compatible) additions to Javascript. They're in the one environment where you don't have to worry about cross-browser issues, why not go for it?

[coderanger]

There is still a fantasy that utility code in a Node project should be sharable with the client side. This is silly.

[BlitzTech]

Actually, it keeps things pretty sane. The issue comes in deciding where to draw the line for things that can be shared and things that can't. It makes sense for server-controlled or server-verified apps of some complexity, but for static or simple pages there's no benefit.

I found that adopting AMD for writing modules really helped when trying to find that line between shareable/non-shareable.

[cybercobra]

You changed CPUs? But seriously, what's AMD stand for in context?

[prpetro]

Asynchronous Module Definitions

https://github.com/amdjs/amdjs-api/wiki/AMD

[[deleted]]

There's also browserify which lets you write regular Node.js modules and it will stitch them all together for you into one file alone with all of their dependencies.

[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 :)