Why? Because the initial parser is relatively cheap. This makes all of the code available, even if a stray eval() calls something unexpected.
The real resource expense comes when it's time to JIT a hotspot. But a hotspot is by definition code you use for sure. And code you use a lot.
JS engines use tracing JIT. Tracing allows JIT compilers to see how code runs in practice, and compile THAT to machine language. How it's organized on the file system etc is entirely irrelevant.
So basically in a trace JIT system, code that isn't hot is interpreted, and code that is hot is JIT-ted (and code that's very hot, gets JIT-ted with higher optimization).
Interpreting is the new "tree shaking". It saves the compiler a lot of work, but also it won't crash your app (unlike bad tree shaking).
Java… you want Java. And so the cycle continues!
We started with Java. It didn't gain any traction for browser scripting. They took "Java" out and called it JavaScript. Now we take the "script" out and call it WebAssembly. If someone in 1995 made Java a DOM-editing thing instead of an applet thing, we could have saved 25 years of running around in circles :)
(Going back even further, we all connected to a mainframe with a dumb terminal. The desktop revolution happened... and now we're back to dumb terminals attached to a mainframe. But we call it "The Cloud" instead, and the dumb terminal fits in your pocket.)
Maybe the past wasn't as dumb as we think it was. We just weren't smart enough to understand it at the time.
Overall it's hard to say how Sun could have won here, perhaps acquiring macromedia and using Flash technology to make a browser that ran those cool portals out of the box, and hey scripted first-class in Java too btw ;-)
> In 1995, Netscape hired Brendan Eich with the promise of letting him implement Scheme (a Lisp dialect) in the browser.
How JavaScript Was Created - http://speakingjs.com/es5/ch04.html
---
> Whether that language should be Scheme was an open question, but Scheme was the bait I went for in joining Netscape. Previously, at SGI, Nick Thompson had turned me on to SICP.
> ..The diktat from upper engineering management was that the language must “look like Java”. That ruled out Perl, Python, and Tcl, along with Scheme.
<script type=“text/scheme”>
Meanwhile, WebAssembly suffers from there not being a good programming language that compiles to it natively. I think the Go support is great, but there's no library support for building the webapps that people get paid to build (React, Apollo, etc. all exist for a reason, however much you hate that reason). AssemblyScript was supposed to be this language, but it's just a Typescript-inspired programming language, it's not Typescript and the npm ecosystem.
I don't know what the details of this implementation are, but the direction I'd like to see web development move is having a statically typed language that compiles to VM bytecode. This sounds like the first step for removing Javascript as a Typescript intermediary. Once that happens, then modern programming language features can be bolted on, people can add good compiler optimizations that result in minimal bytes output for users to download, the module system can be made stricter (like "go mod"), etc. Javascript is just a little bit more dynamic than anyone really wants, and it makes the build/deployment tooling complicated and, frankly, kind of bad.