5 ms·
Browser Javascript suffers from not producing a single "binary" as its build system output. You do get one bundle, but none of the parts know anything about ea
by jrockway 5y ago
Browser Javascript suffers from not producing a single "binary" as its build system output. You do get one bundle, but none of the parts know anything about each other, and it limits the ability to optimize. (It is a lot more like the C preprocessor, rather than a C compiler.) Methods that can't possibly ever be called end up being sent to each user, for no reason other than "well someone could write an eval() that needs that". (I was surprised how poorly tree-shaking works in practice, and how even "light" frameworks like Svelte ship a huge runtime to every user, unrelated to what features the code actually uses.)
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.
- slver 5y agoTree shaking works poorly, but is also thankfully not that important, unless you're terrible with managing dependencies. 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).
- uncomputation 5y ago> the direction I'd like to see web development move is having a statically typed language that compiles to VM bytecode. Java… you want Java. And so the cycle continues!
- christophilus 5y agoOr preferably, F#.
- naruhodo 5y agoYou could add some kind of security manager to sand box it and have little apps running in the browser. Maybe call them "applets".
- jrockway 5y agoThat's a really good point. What we wanted all along was the JVM with a DOM API. 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.
- 5y ago
- atatatat 5y ago> WebAssembly suffers from there not being a good programming language that compiles to it natively Is Grain insufficient for some reason?