Why don't we spend effort on building an ES:Harmony -> ES3 compiler rather then a CoffeeScript -> ES3 compiler.

It's more worthwhile future facing project.

Maybe you should take your opinions about not using client-side code back to 1998

Agreed, the codebase is a mess.

The ideas are nice, the implementation is absolutely horrible.

For the record, I didn't write this library because I thought I could do it better.

I wrote it because I didn't know about these other utilities / tools.

super is a nightmare to emulate and get "right". It has a bunch of weird edge cases you don't really want to think about.

I promote code like

    var Cat = Object.make(Animal, {
      constructor: function() {
        Animal.constructor.apply(this, arguments);
        ...
      },
      walk: function() {
        Animal.walk.apply(this, arguments);
        ...
      }
    });

Now compare:

- Animal.walk.apply(this, arguments);

- this.super.apply(this, arguments);

- this.super.walk.apply(this, arguments);

Using super doesn't fix verbosity, it only fixes hard coupling of Child class name to Super class name.

For the complexities, edge cases and performance penalties a super implementation gives, it's simply not worth fixing this hard coupling.

If you know of a super implementation that _just works_ please [Leave an answer on StackOverflow](http://stackoverflow.com/questions/8032566/emulate-super-in-...)

I've been getting along fine with nothing but util.inherits from NodeJS.

Are there any real advantages to the "set the prototype to this object" approach versus building it up by assigment?

    function Animal(legs) {
        this.legs = legs;
    }
    Animal.prototype.speed = function() {
        return legs * 10;
    }
    
    util.inherits(Dog, Animal);
    function Dog(name) {
        this.constructor.super_.call(this, 4);
        this.name = name;
    }
    
    Dog.prototype.speed = function() {
        // I don't disagree that more sugar here would be good
        return this.constructor.super_.prototype.speed.call(this) * 2;
    }

What your showing is ES3 OO sugar.

The problem I have is that the notion of a constructor function goes against prototypical OO.

In prototypical OO we just have objects and objects inherit from objects. there is no notion of a constructor function.

Also note that pd.make returns an object rather then a function.

It's simply a programming style I like, to think of my "class" object not as the constructor function but as the prototype object.

Not to mention that `x.prototype.foo = ...` is ugly.

    var Animal = {
        constructor: function () {
            this.legs = legs; 
        },
        speed: function () {
            return this.legs * 10;    
        }
    };
    
    var Dog = pd.make(Animal, {
        constructor: function (name) {
            Animal.constructor.call(this, 4);
            this.name = name;
        },
        speed: function () {
            return Animal.speed.call(this) * 2;    
        }
    });

Yeah, it gets really hairy, really quickly.

Beyond the need for calling the constructor (which I'm currently viewing it as an unnecessary hidrance [objects are already initialized]), Object.getPrototypeOf may provide a way out - but maybe not the way you intended. Have you considered it?

    Object.getPrototypeOf(Child).constructor.apply(this, arguments);

Works, but is even more verbose. However if you use Object.getPrototypeOf on this you fail the recursive problem in nest super calls. Read the stackoverflow euestion

I was deliberately excluding the constructor situation. I should have made that clearer in my previous comment. I think the way out of the constructor mess is not to require them at all.

I do think the Object.getPrototypeOf approach is feasible for methods.

the method fails for the exact same reason.

If a single method calls a super method and that method calls another super method then it fails.

    Object.getPrototypeOf(this).method

Always have one value and only one value, calling it more then once leads to infinite recursion.

You need all three I'm afraid.

We need an easy way to mixin/extend objects.

   var obj = protoObj <| mixin({ ... properties ... }, mixinA);

We also need a solid way to create instances.

   object.create(obj);
   obj.constructor();

is just too verbose. There is some talk around making `new` work with object exemplars which would be great.

That's the whole point. Most requests have the same order of magnitude.

If you have two sets of requests that have different orders of magnitude then put these two sets on their own node worker process behind your load balancer.

As long as you send your requests to the worker process that handles requests of a similar order of magnitude you will never have the faster requests being stuck behind slower requests problem.

Is Java faster then JavaScript? Yes.

Is it easier to write performant code with node.js vs Java Async IO? Subjective.

Java is faster than Javascript on V8? This is accepted fact? Can you provide a reference?

Java AIO

  $ ab -n 30000 -c 300 http://127.0.0.1:8080/
  Concurrency Level:      300
  Time taken for tests:   4.908 seconds
  Complete requests:      30000
  Requests per second:    6112.65 [#/sec] (mean)

Node (January 2011)

  $ ab -n 30000 -c 300 http://127.0.0.1:8124/
  Concurrency Level:      300
  Time taken for tests:   8.140 seconds
  Complete requests:      30000
  Requests per second:    3685.69 [#/sec] (mean)

http://www.olympum.com/java/java-aio-vs-nodejs/

It's pretty well known that Java hovers around 1.1x the speed of C where as JS hovers around 2-3x the speed of C.

So yes Java is faster.

{ 'offtopic' : "

I totally agree with you, but i just want to draw your attention to the phrase 'the speed of C'. You almost make it seem like it's a global constant, like the real C-for-celeritas speed of light, some unobtainable blazingly fast mirage accessible only to quantum physicists and unix greybeards.. but we don't need a particle accelerator to beat the performance of C, just better JITters. There's not really anything in the language stopping the performance from being reached (okay, well for JS there's the type system.)

" }

When I say the speed of C. I'm really comparing various language X compilers to the GCC compiler under the assumption that the GCC compiler is the best.

No it's not a magical constant but I think for a baseline comparison "how close your compiler X is to GCC" is a fair thing to compare.

I also doubt V8 or spidermonkey can get better then GCC _on average_

Thanks for the replies. I wasn't aware that JS was that much slower than Java, and I also wasn't aware that Java had closed the gap so significantly vs C.

3. child_process API and bolting C++ extensions onto node allow you to do this.

Please take your troll attacks of JavaScript elsewhere.

Thank you.