7 ms·
"Precompiling JavaScript? Every few years, it’s proposed engines offer a way to precompile scripts so we don’t waste time parsing or compiling code pops up. Th
by hacker_9 10y ago
"Precompiling JavaScript?
Every few years, it’s proposed engines offer a way to precompile scripts so we don’t waste time parsing or compiling code pops up. The idea is if instead, a build-time or server-side tool can just generate bytecode, we’d see a large win on start-up time. My opinion is shipping bytecode can increase your load-time (it’s larger) and you would likely need to sign the code and process it for security. V8’s position is for now we think exploring avoiding reparsing internally will help see a decent enough boost that precompilation may not offer too much more, but are always open to discussing ideas that can lead to faster startup times."
Surprised there was no mention of webassembly, which does exactly this.
- tomdale 10y agoWebAssembly doesn't give you access to DOM APIs, so it's not like you could rewrite Angular in wasm, for example. Most load time/parse time discussions are in the context of web frameworks, but they're typically not able to benefit from the performance improvements of WebAssembly, particularly given the overhead of moving data into and out of the wasm context.
- stupidcar 10y agoAccess to DOM APIs isn't part of the MVP, but it is listed as a high-level goal[1] and is specced as a future feature[2]. [1] https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/HighLevelG... [2] https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md
- tomdale 10y agoI'm excited for this and eagerly look forward to adopting it in Ember as soon as it's mature, but I'm guessing this is still at least a few years out.
- Bahamut 10y agoEven when it's out and mature, there is some complexity around gracefully degrading when it is not available - it is going to increase frontend complexity dramatically I suspect, at least until browser support dictates that graceful fallback isn't necessary for the feature.
- callahad 10y agoMost current WebAssembly compilation paths produce asm.js as an intermediate artifact. In the near term, backwards compatibility should be relatively simple: save both and load the asm.js code as a fallback.
- mrec 10y agoOr you can do it on the client side by hooking into the module loader and decompiling the wasm back into asm.js. See for example the https://github.com/lukewagner/polyfill-prototype-1 https://github.com/lukewagner/polyfill-prototype-1 PoC mentioned in the wasm FAQ.
- stupidcar 10y agoPerhaps, but I've been surprised at how fast WASM support has moved already, and how committed all the browser vendors has been. Usually there's at least hold-out. I feel like there may be enough internal pressure from groups in Apple, Google and Microsoft to get DOM integration available, so that they can experiment with compiling the likes of Swift, Dart and C# to it, that it will become a priority once the MVP has shipped.
- dualogy 10y agoWell such object references and also string handling (not first-class representation in asm.js/current-wasm either) is just a lot of pointer munging really --- realistically I don't see many of today's framework writers re-expressing their visions at that level, plus in the browser context you need them to be "safe pointers"/"references" managed carefully etc.. can of worms. wasm/asm.js' prime use cases are certainly in high loads of real-time numerical calculations, I'm not just talking games or shader-helpers (and sciency/other simulations whether in academia or commercial solutions) but also envisioning faster, neater in-browser apps evolving for all sorts of media (pics/vids/audio/360°/etc) handling/editing/munging etc.
- s_m_mcguire 10y agoNot first class access, but you can call arbitrary JavaScript via FFI. An approach that worked fine for me was to use a simple object which holds your DOM handles via incrementing numeric IDs and pass them back to your Rust (or C++) code. I found the FFI overhead to be non-existent compared to the actual DOM work as well.
- munificent 10y ago> a simple object which holds your DOM handles via incrementing numeric IDs and pass them back to your Rust (or C++) code. How do you know when to release those handles so the GC can clean them up?
- s_m_mcguire 10y agoIn my case I knew when the owning Rust struct was destroyed, and it was guaranteed to be the only thing holding the element handle so I would just free the DOM node during the destruction logic. For something more general purpose I'd probably just use a destructor (whether C++ or Rust) with the same guarantee of single-ownership of the underlying ID, and the DOM node will automatically be freed once the native handle goes out of scope. Edit: Of course, you'd have to prohibit copies on the native side.
- falcolas 10y ago> need to sign the code and process it for security If they don't do this for JavaScript, why would they start doing this for compiled code? Unless they're expecting platform specific byte code, in which case V8 becomes superfluous (perhaps another win for consistency).
- zwetan 10y agosurprised about this specific part "bytecode can increase your load-time (it’s larger)" how come bytecode is larger than plain text? I don't know the specifics of the V8 bytecode, but for the AVM2 which load pre-compiled ActionScript as bytecode, the load time is faster, faster than the JVM for example.