Only Pseudo Node.js Support?

[apoc]

hey guys,
I must say I'm really confused on how this all works with node.js/
CommonJS (I've not even looked at client side). Are you really
proposing we should define our classes like this?

FooClass = JS.Class(...);

But if thats the case, why even bother with all the dependency
management in the manifest? This defines it in the global scope and it
is (once required someplace) accessible everywhere (in any other file
of the project).
To me this sounds like a step back in structuring your code compared
to regular commonjs/nodejs.

[James Coglan]

Sorry for the delay -- in case you're still interested, my response below.

On 21 April 2012 22:47, apoc <ap...@sixserv.org> wrote:

hey guys,
I must say I'm really confused on how this all works with node.js/
CommonJS (I've not even looked at client side). Are you really
proposing we should define our classes like this?

FooClass = JS.Class(...);

Yes (except you need a 'new' before 'JS.Class'). Or, more accurately, it depends. It depends which platform I'm shipping something to. If it's Node-specific, then I use the Node module system. For stuff that needs to be portable, it's more complicated.

I actually mostly use JS.Class for its test framework these days, i.e. I use JS.Test for projects not written using JS.Class. I also use JS.Packages extensively for organizing web apps, where globals are the norm.

http://blog.jcoglan.com/2012/01/23/organizing-a-project-with-js-packages/

But if thats the case, why even bother with all the dependency
management in the manifest? This defines it in the global scope and it
is (once required someplace) accessible everywhere (in any other file
of the project).

This is also true of CommonJS and AMD -- neither of them prevents or protects against global variables. The reason I do this for big web apps is that it's just about the only thing that works in pure JS that works everywhere (i.e. in the app, on test pages, in the console for headless tests, etc) without compiler tooling like browserify, r.js, etc. Having the deps in one place, in code totally isolated from anything that might access the DOM, makes it much easier to do static analysis to figure out which files you need when bundling for production, as the above blog post explains.

To me this sounds like a step back in structuring your code compared
to regular commonjs/nodejs.

It's an approach that works for some sets of constraints. If you want more of the rationale for it, I recommend reading: http://blog.jcoglan.com/2011/04/16/on-the-role-of-js-packages/. I'm not claiming this is the quote-unquote best option for all projects, but it works very well for the stuff I use it for.

--
James Coglan
http://jcoglan.com
+44 (0) 7771512510

[James Coglan]

On 21 April 2012 22:47, apoc <ap...@sixserv.org> wrote:

If you're interested, a patch just landed that makes all the modules export their API via CommonJS on supported platforms. Worth noting that to remove *1* global variable, while keeping support for all existing platforms and not breaking the JS.Packages system, required a 1000+ line patch:

https://github.com/jcoglan/js.class/commit/78e95d132200841170b672b5c290b4e13d541328