3 ms·
> JavaScript and HTML are a lot more bloat than machine language code written to the wire. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-java
by bzbarsky 13y ago
> JavaScript and HTML are a lot more bloat than machine language code written to the wire.
http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... suggests otherwise in a head-to-head comparison: C code compiled to both a platform-native binary blob and JavaScript, then both gzipped (standard practice for any large JS file on the web).
And if you're talking platform-dependent machine code, that's likely _worse_ on the wire in practice, because unlike a platform-independent representation you can't do edge caching or other sorts of intermediate caches. But maybe you meant a virtual machine (i.e. what people ask for when they want a common bytecode)?
- kenjackson 13y agoThat's not how you measure bloat. There's a huge runtime associated with that JS code, and you ignored performance.
- bzbarsky 13y agoAh, you mean client memory bloat, not transfer bloat (i.e. pageload time). That part was not very clear at all. You still need a nontrivial runtime (a la PNaCl) if you're going to provide the sort of sandboxing guarantees for the code people want for code that runs without explicit user opt-in. Or is that a non-goal in your case? In that case, I'd like to understand the problem you're trying to solve, since it sounds different from the one JavaScript in web browsers is solving. I agree that things like asm.js have a performance hit compared to just running an unsafe binary blob. So does PNaCl (though the hit there is different from the asm.js hit: it has somewhat faster steady-state, but worse startup performance). Again, if you're not talking about something that has the same safety guarantees as JS and PNaCl you're comparing apples to oranges.