10 ms·
Finally, a reason to go into JavaScript development with a background in compilers! I can see the need for cross-compiling tools and certain special skills for
by xigency 11y ago
Finally, a reason to go into JavaScript development with a background in compilers! I can see the need for cross-compiling tools and certain special skills for performant web development in the future, especially since even with complete adoption of WebAssembly this will still create a split between browsers that support it and browsers that don't.
From glossing over the wasm spec, it seems it's designed for C++ compilation, which in the environment I do development, is totally impractical. It sounds like a TypeScript to WebAssembly compiler isn't on Microsoft's radar. In that case, it might be time to work on some tools for analyzing syntax and start annotating types, because compiling from ECMAScript to WebAssembly would be a great boon in production.
- geon 11y agoWhy 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/
- 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
- azakai 11y ago> compiling from ECMAScript to WebAssembly would be a great boon in production. That's not going to work well, I'm afraid. JavaScript is a highly-dynamic language, and as a result, requires JITs that do runtime type profiling, type inference, and type-specialized code generation, in order to be fast. WebAssembly is a low-level, statically typed language. It's like a portable C with a small binary footprint. Even if you annotate and/or detect some of the JavaScript types at compile time, if you don't have them all, that means compiling JavaScript to WebAssembly will result in code that everywhere does "if this type, do that; if that type, do this". That's going to be bigger in code size than JavaScript currently is. It's also going to run much slower. If you did type every single thing in your JavaScript program, somehow, then that might work well. But that's not really JavaScript anymore (or even TypeScript, etc.).
- bcheung 11y agoWebAssembly is a binary representation of the Javascript AST. Optimizations usually happen AFTER it is parsed. That's all WebAssembly is -- the parsed result. Targeting WebAssembly from Javascript is the most natural fit that could possibly exist.
- azakai 11y agoNot quite. WebAssembly is not a representation of general JS. It can just represent a small subset of it, very similar to the asm.js subset.
- bcheung 11y agoGood to know. So it doesn't implement any of the ES6 concepts then I take it.
- esailija 11y agoThe format is just an AST in general, nothing to do with JavaScript. You can even see all the possible instructions here to confirm [1]. 1. https://github.com/WebAssembly/design/blob/master/AstSemantics.md https://github.com/WebAssembly/design/blob/master/AstSemanti...
- skybrian 11y agoIf you want to target WebAssembly, I suggest starting with Rust or some other language that doesn't require a garbage collector. WebAssembly doesn't have a garbage collector (yet) which is essential for JavaScript and many other high-level languages. Shipping a garbage collector compiled to WebAssembly is going to make downloads much larger, and it's likely going to perform worse than the native garbage collector. A compiler for a garbage-collected language is probably better off targeting JavaScript, not WebAssembly. There are already lots of languages that do this: GWT, Dart, Kotlin, ClosureScript, Elm, etc. There was already plenty of work to do for a compiler expert even before WebAssembly came along.
- xigency 11y agoThe purpose is to limit the number of steps in development. If only 50% of users are running the WebAssembly version of a product, and 50% are running the JavaScript version of the product, then both need to be stable. Developing in an unrelated language is unlikely to help.