isntitvacant

In both examples, the function is only allocated once, no matter how it's instantiated.

Where you have to be careful is if you have a function that's being called repeatedly and it contains a function instantiation -- that function will be reallocated each time.

   [1,2,3].forEach(function(x) {
     return (function(a, b) { return a * b })(x, 2)
   })

Will repeatedly allocate that inner multiplication function, vs:

  mul = function(a, b) { return a * b }
  ;[1,2,3].forEach(function(x) {
    return mul(x, 2)
  })

Will only allocate that multiplication function once.

In this case, it's not language lawyering. All JavaScript environments "do the right thing" with regards to ASI -- it works in all target environments as of the present day. JSMin is not a target environment, it is a minifier that happens to express some strongly-held opinions of its author.

That said, it's hard to program to a spec that does not (officially) exist yet, and doubly so if there's not clear "opt-in/out" path for future versions. Since, as a developer, I can't control what the committee adds or removes from the spec, or what they might break, I can only do the best I can with the language as it is -- not breaking existing code in future versions of the language is the committee's job.

I'm increasingly a fan of local named functions in JS, vs. pulling callbacks entirely out of scope. An example:

    function compile(filename, ready) {
      return fs.readFile(filename, make_fn)

      function make_fn(err, data) {
        if(err) return ready(err)

        ready(null, new Function(data))
      }
    }

Which neatly addresses the desire to retain closures, while avoiding unnecessary nesting.

Also, whenever possible, I like to nix callbacks by using Function#bind:

    res.on('data', accum.push.bind(accum))

    // vs:
    res.on('data', function(data) { accum.push(data) })

Yes and no -- it's not absolutely necessary; I could've written it similarly without turning the callback-accepting functions into emitter-returning functions. It would have felt gross to do so, though. The downside I see with using straight callbacks that accept error and data arguments is that they conflate the logic of what that callback is actually attempting to do with the error-checking of the calling function. For example, my `baseDirOkay` method shouldn't care whether or not the calling `fs.stat` function succeeded or failed -- it should only care that the data it was passed is or isn't a directory. It shouldn't be called at all if the path was not valid. With an EventEmitter api, I can rely on the emitter itself to tell me whether or not to even call my `baseDirOkay` function, instead of having to conflate that logic with my method.

This seems like a tiny gain in readability, but it means that I don't have to make a decision between putting the error/success logic of `fs.readFile` in my method (where it does not go) and my calling function (where it probably does not go, and where it would incur unnecessary nesting -- and the finagling of the `this` variable that that incurs).

This may just be my taste -- but I find designing around (and reasoning about) EventEmitter-type API's much easier.

something like this:

  var session = require('session'),
      models = require('models'),
      template = require('template');

  function main(request,response){
    session.start(
      models.getEntries.bind(models,
        template.render.bind(template, 'blog',
          response.write.bind(response))));
  }

would be easy to put together with node.js; it's functionally equivalent to the above (though it assumes that data comes into the template.render call as the last argument(s)), and neatly avoids too much nesting.

Hi -- this is chrisdickinson.

One of Wilson's goals is to be comfortable for Djangonauts who, for whatever reason, need to write Node.js code. To that end, the ORM, view layer, and template system are similar to Django to ease use in that particular case.

The other boon to having a largely cross-compatible template language is that it allows a bit of bootstrapping to occur for Wilson projects -- Wilson could conceivably make use of Django's admin templates at some point, if that's the direction it's going to head.

However, Wilson does diverge pretty rapidly from Django in other areas -- it borrows Django's concept of apps, but in Wilson apps are designed to be pluggable; you can install a single app multiple times under multiple aliases, reopen app instances from the project level and change their settings and models before they're finalized, etc. Within the context of an app, you interact with other apps through "externals" that are resolved at project-level.

The other major difference is that wherever possible, I'm hoping to keep the libraries that constitute Wilson separate -- and wherever it makes sense, to make them also operable in-browser. To that end, Platoon (the testing framework), Plate (the template language), Escaperoute (the router), Pieshop (the ORM), and postpie (the ORM adapter to Postgres) are all kept as separate libraries; Pieshop and Plate are actually designed to be run in-browser as well, in preparation for the eventuality of needing to interface nicely with a Wilson app from the client-side.

So in summary: Wilson isn't a one-to-one port of Django -- it's heavily Django-inspired -- but aims to diverge wherever it is sensible to do so.