Remove dependencies on core CanJS and DOM libraries to increase Node compatibility

[rjgotten]

While such dependencies are fine if you can work with a global Node.js installation and a working npm install of jsdom (and crucially; contextify), it completely bombs when trying to integrate with existing build-chains.

This is a problem in particular for MSBuild-driven builds such as is the case with Visual Studio or TFS build server.

How hard would it be to use only the EJS compiler itself to produce the template and nothing else? (Or alternatively; how hard would it be to shim a minimal underlying DOM library on which to build up CanJS?)

[daffl]

I'm not sure I understand what the problem is. If you

npm install can-compile -g

it should be possible to run can-compile with any build tool as an external command.
can-compile has been specifically build as a Node tool with JSDom. The actual compilation
is literally only the two lines at https://github.com/daffl/can-compile/blob/master/lib/compile.js#L49
and should work with any other DOM library and JavaScript runtime environment (Steal still uses
Rhino and EnvJS).

[rjgotten]

I'm not sure I understand what the problem is.

Flexibility and the lack thereof.

npm install -g only works if you have a global Node.js installation. It's not something you typically have available on build servers, especially MSBuild ones, and not something a user account running builds should typically have access to run. At best, it requires a priori set-up on a build server by a developer. At worst said developer won't have the permissions necessary to do so yet, will have to go through the proper channels to get said permission and ultimately won't get it because a sysadmin won't allow it.

Morever, even if you are able to set this up on a build server; can-compile leans on jsdom and jsdom in turn leans on contextify, which has to be built as a native module for the platform in question. (I.e. it requires even more additional set-up to have the contextify native module compile.)

All of this places some rather annoying restrictions on integrating view pre-compilation into existing build chains.
(Anyone using Visual Studio and TFSBuild is basically screwed unless they feel like jumping through hoops.)

And actually; you can do a lot better than that.
Yesterday I went ahead and did my own implementation of a shimmed DOM library glue layer similar to the MooTools or YUI ones, but for Node.js. It only implements the array helpers and type helpers, which is really all the EJS view compiler seems to need. (I'm not interested in Mustache, personally.)

Loading CanJS on top of this fake DOM library worked just fine for me without having to rely on jsdom or similar. Infact; it meant I could write a RequireJS loader plugin and have the whole thing integrate directly with its optimizer build tool: it just loads the EJS file during development and compiles it in-browser, but it loads CanJS serverside and inlines a precompiled view definition into the optimized JS files in production builds.

Really simple to use as well. E.g.

//  app/controls/MyControl.js
define([ "can", "ejs!../views/MyControl.ejs" ], function( can, viewId ) {
  return can.Control.extend({
    init : function() {
      var me = this;
      can.view( viewId, {}, function( frag ) { me.element.append( fragment ); });
    }
  });
});

Really; doesn't that feel a lot more flexible than fudging things with having to hook up additional grunt tasks?

[daffl]

I think this is exactly what PR #3 addresses. The problem is providing the shimmed CanJS version (without having to modify it with every release). Any suggestions there or a pull request with your implementation would be really helpful because you are right, there is no need for a DOM when compiling the views - plus it would allow to finally finish the RequireJS view loader.

[daffl]

This is closed by moving to can-simple-dom via #45