You'd be surprised
But then many people pooh-pooh'd me in a similar way when I said I could make Ruby 10x faster which was my project for the last few years, so best of luck to you!
so essentially it's likely "JavaScript-like compiler" rather than "JavaScript compiler"... similar to how Crystal is Ruby-like but not really Ruby.
However, apart from that, I don't see what can't be done: you can simply look at what functions get called, with what parameters, and generate code for each fundamental type (doubles, strings, …) used. It's like making C++-style templates for all function parameters.
The flip side is awful compilation times on large projects, and (I expect) poor results on maths for which JS VMs detect small ints.
I actually wanted to do something like this as a follow-up from my experiments with JS type inference, but I lacked time…
A simple example would be something like `x = (isUserOnMars() ? "foo" : 1)`. The type of `x` depends on if the user is on Mars. In practice they never will be, but a compiler can't tell that and so must consider that case and make code appropriately generic. A JIT however can see that it always appears to be false, and optimise around `x` tending to be a number, with bailout if it's wrong (which it likely never will be). Then the use of `x` may propagate a long way through the program in all sorts of places, extending the effect.
Profile-guided optimization seeks to do this for compiled languages like C++, but you also have a boatload more data to do it with. And, y'know. You're profiling the application. You're running it.
My first guess for the chopping block would be the functionality of franken-objects like Function.arguments (especially properties like arguments.callee).
Moreover, you can carry out heavy static analysis that can often narrow down the possible types for a and b. The main problem with this is that static analysis that is good enough will run very slow, hence it not an option for the web-browser.