Lua is better optimized because it is smaller. It's been the right decision to keep Lua small given where it specializes. Given where JavaScript specializes it's been the right decision to not keep it small but to evolve it. JavaScript is big because it can be big; it has the resources to make it so.
You're wrong.
I think this is fundamentally wrong. I think you're confusing the language itself with how the language has been implemented.
Speed is entirely separate from the language. It's possible to write two different JS interpreters: one very fast and one very slow, both of which meet the language standard set by ECMA.
These days JS generally gets JIT compiled and a tremendous amount of work has gone into improving the popular compilers. Lots of tricks are involved. These tricks are quite clever (though sometimes inelegant) and result in significant speedups. But they have nothing to do with the language itself.
If so, you're basically agreeing with parent, in parent's disagreement with this from further upthread:
JS semantics are garbage... for optimizations
Of course the semantics of a language can impact how easy/hard it is to write a fast implementation for that language. And as far as I know, there isn't anything special about the ECMA specification that makes it any harder to speed up compared to other languages in the same space (dynamic languages, whose specifications were written with an interpreter approach in mind).
Still, in my mind, speeding up any sufficiently dynamic languages with eval and metaprogramming without straying at all from the language spec is like "fitting a square peg inside a round hole." And I think that has been done successfully with JS, at the cost of making it harder to reason about how the compiler is going to treat my code.
I currently do JS for a living, and I don't hate it, but most of the reasons to DO javascript coding have nothing to do with quality of language and instead have to do with how unlikely a viable competitor is to come about anytime soon.
So why M$ and Google cannot beat poor javascript?
Some things can't be solved by throwing money at them.
The amount of work that went into today's JS engines is just insane.
Which dynamic languages are slower than Node? (Other than Python which is incredibly slow) How is it 'most'?
I'm not looking for a language war. I'm a polyglot who will always gladly use the right tool for the right job.
But Node has a ways to go before being one of the fastest JITs around.
Ion, jsc, and v8 are in similar boats.
Those languages chose slower semantics to give better programming experience - it's a design trade-off - JS has the worst of both worlds.
If anything the kind of breadth JS ecosystem has shows just how hard to maintain other people code is.
Since you brought up the left pad thing, yes there is a small minority within the JS community that takes the Unix philosophy of "only do one thing and do it well" to an absolute extreme. But that isn't indicative of the JS ecosystem as a whole.
Mind naming some ? I work on Angular 2, React and TS front end in my day job - those libraries are a joke compared to similar libraries in other languages. For example Angular 2 Dart is a huge productivity improvement - having done a prototype with ng2 Dart and implemented a full app in TS having a language with sane semantics, actual standard library and a build system built by someone who knows what they are trying to do vs someone who hacked something themselves and everyone kept piling on. React compared to something like Clojure + Reagent is a similar comparison although CLJS tooling is much less mature than Dart - just dealing with immutability in JS/TS is so tedious and full of boilerplate.
Just recently I had to find a library that will let me pattern match URLs and extract parameters (eg. 'foo/:a/:b(?foo=:c&bar=:d)' => {'a':..., 'b':..., 'c':..., 'd':...}) - and every option out there failed to work with anything beyond basics and the implementations were horrible - and this is JS core competency.