Probably the problem with your perspective is that you're still thinking about JS "interpreters", when we don't generally have those any more - we have JITs that compile JS to machine code.
`new Foo()` is faster because it can be compiled to more efficient code today and probably always will be. Your argument is a bit like the "given a sufficiently intelligent compiler" one, I don't care about what JS engines of the future might do, I care about my code's performance today.
I said there are few absolutes, not that there are no absolutes :)
`new Foo` has simpler semantics than `Object.create(FooProto)` and therefore I believe it will always be faster. That performance gap can of course narrow, but I think `new` will always be the fastest. Happy to be proved wrong.
Comments
Probably the problem with your perspective is that you're still thinking about JS "interpreters", when we don't generally have those any more - we have JITs that compile JS to machine code.
`new Foo()` is faster because it can be compiled to more efficient code today and probably always will be. Your argument is a bit like the "given a sufficiently intelligent compiler" one, I don't care about what JS engines of the future might do, I care about my code's performance today.
I find it odd that you rail against absolutes and then immediately turn around and defend your own.
If you meant that new is faster today, say so. That's not the same as "will always outperform".
I said there are few absolutes, not that there are no absolutes :)
`new Foo` has simpler semantics than `Object.create(FooProto)` and therefore I believe it will always be faster. That performance gap can of course narrow, but I think `new` will always be the fastest. Happy to be proved wrong.