8 ms·
Why on earth would you want to compile javascript (which is what typescript essentially is) to wasm?
by geon 11y ago
Why on earth would you want to compile javascript (which is what typescript essentially is) to wasm?
- tomjen3 11y agoGame dev here. Speed. Oh and memory - if I could optimize it so that all our vectors, matrices and logic code did only stack allocations I would be a happy camper.
- anthk 11y agoEven Pascal from FreePascal + Lazarus gets better speed than JS with a JIT :S Why don't you compile into native platforms?
- nfriedly 11y agoIf nothing else, it results in a smaller download than minified js. (I believe that's true even today.) And, in theory, it should be able to run a bit faster also. Not sure if that one's true yet. Update: Here's a quote from the Microsoft announcement: "Despite being an early implementation, the demo starts-up significantly faster than just using asm.js as the WebAssembly binaries have a smaller file size and parse more quickly than plain JavaScript that needs to be parsed in the asm.js case." https://blogs.windows.com/msedgedev/2016/03/15/previewing-webassembly-experiments/ https://blogs.windows.com/msedgedev/2016/03/15/previewing-we...
- xigency 11y agoYes, it would be faster.
- AgentME 11y agoWhy would bundling a Javascript engine in a webpage be faster? I guess it's likely if someone were to make an improved Javascript engine, but their effort would be better spent improving the Javascript engines in browsers (affecting all webpages) rather than bundling it as a many-megabyte download into their own webpages.
- xigency 11y agoIt really depends on the code. This whole topic is for webpages with scripting that have reached performance bottlenecks, not just an obscure exercise in torture.
- geon 11y agoDonHopkins pointed out that wasm will eventually support serialization of arbitrary js. So you wouldn't need to include the js runtime at all, but still get a much quicker download and parsing. https://news.ycombinator.com/item?id=11291997 https://news.ycombinator.com/item?id=11291997
- jhpriestley 11y agoYou are misunderstanding. A C++ application compiled to wasm is smaller than a C++ application compiled to a subset of javascript. A javascript application compiled to wasm doesn't really make sense. Javascript isn't a compiled language. The best you could do would be to store some kind of compressed representation of the source code, along with a JIT compiler to run that source code. It isn't a sensible thing to do.
- xigency 11y agoSure it does. Do you know that Lisp and Scheme have compilers? They target assembly even as dynamic languages, like JavaScript. These are totally sensible. Look at: http://www.call-cc.org/ http://www.call-cc.org/
- RussianCow 11y agoBut the point is, if you want to compile your JavaScript code ahead of time, you have to ship your own GC and JIT compiler, because you no longer get it "for free" from the browser's JS implementation. There's absolutely no benefit from doing this.
- geon 11y agoThat will soon not be true. Exposing the js gc is on the roadmap. ...which will also make it feasible to use other gc:ed languages without shipping an enormous runtime.
- xigency 11y agoPerformance. Looking at dependencies for certain key Javascript libraries makes me skeptical now that this is possible.
- PeCaN 11y agoWhy would AOT compiled JS performance be better than the highly advanced JIT compilers that are _designed_ to run JS efficiently?! AOT compiling highly dynamic languages gives you very little room for optimizations.
- vcarl 11y agoIf you compile ahead of time, you can tune your optimizations. With the right tooling you can tell the compiler that a certain path is hot and should be optimized from the beginning, or catch deoptimizations better, or just get rid of the compilation cost. Right now I'm not sure how much practical benefit there is, but there's a lot of potential.
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- xigency 11y agoBecause even a just-in-time compiler is slower than native performance quite frequently. A just-in-time WebAssembly compiler can be guaranteed to be as fast as V8 in practice. Branch prediction on a CPU can be quite helpful, but if a program stops hitting the same branches it can impact performance. The point of a just in time compiler is that it compiles on the fly, which does take a certain amount of time. That could be loading time for your application. In any case, the purpose of this development would be to design something that is faster than V8. And I'm specifically speaking of compiling with inferred types or from asm.js or TypeScript, not embedding a VM or a garbage collector or an emulator. This compiler might only accept programs that would be faster.
- mason55 11y ago> Why on earth would you want to compile javascript (which is what typescript essentially is) to wasm? Similar to asking why would you want to run JavaScript on the server? There's something to be said for having your code in a single language. People can move to different parts of the project more easily and if you need to run the code in multiple places then you can do so with (mostly) a single codebase. The real question is why WOULDN'T you compile all your JavaScript to wasm assuming the build process is easy enough. For complex site that already have a build pipeline I don't see any reason to publish minified JavaScript instead of just building it all into wasm for performance reasons (assuming mature debugging tools of course). The only question I'd have is whether you get that much gain by going from JavaScript to wasm or if the browser's JIT compiler can do a good enough job.
- gliptic 11y agoCompiling JavaScript into WASM is most likely not going to result in better performance unless you make an extremely good static optimizing compiler, and probably not even then. It's very hard to do the kind of optimizations that JIT compilers do ahead of time, in one single static binary.
- xigency 11y agoPull the developers (or poll them) from V8 and ask them what they think. All of the "just-in-time" optimizations can be done ahead of time. Which saves [that much run time x that many users] in computer time.
- gliptic 11y agoI don't know why you refer to V8. V8 isn't doing AOT compilation of general JavaScript.
- jfbastien 11y agoEveryone on V8 would disagree with you :-) Type tracing in particular is the big win, and with a dynamic languages you simply can't prove enough to do it ahead of time. There's also startup time that you're paying with AOT and avoiding with JIT.
- omarforgotpwd 11y agoOnce webassembly is widely supported, why would we ever write JavaScript again?
- jensvdh 11y agoBecause DOM manipulation in C++ sounds like a nightmare to me.
- omarforgotpwd 11y agoI was thinking more about Ruby, Python, or go
- geon 11y agoIf you want it to be fast, you probably shouldn't touch the dom.
- twistedpair 11y agoC++ speed in the browser... just be sure not to touch the browser.
- rspeer 11y agoTo the contrary, I think everyone should touch the DOM when they need the DOM. If this is going to be a platform for more than ads and shitty games, it will need to be able to use the browser's exquisitely engineered ability to do text rendering and layout. Just like Flash or the JS game platforms that are stupid hacks on top of the canvas element, if people have to implement text rendering without the DOM, it'll encourage putting poorly-rendered text in unusable layouts with squirrely scrollbars. We can do better.
- geon 11y agoI mean you would do it the react way and only manipulate an abstract representation of the dom.
- 11y ago