7 ms·

> I do like the idea presented of having a transpiler track and a JS engine track. Keep the ES spec for the JS engines simpler and hoist all the syntactical sug

> I do like the idea presented of having a transpiler track and a JS engine track. Keep the ES spec for the JS engines simpler and hoist all the syntactical sugar onto the transpilers. Alternatively, if you focus on getting web assembly up to speed, you can compile any flavor of JavaScript you want directly to web assembly. You wouldn't need transpilers at all except for backward compatibility (which would eventually fade). At least that's the future I'd like to see.

crooked-v 8y ago
That would be my preference too. It feels like there are so many possibilities for performance gains and better tooling stuck behind WASM's lack of DOM integration and other native browser libs.
RussianCow 8y ago
Everyone keeps saying this, but it doesn't make sense to compile JavaScript to WebAssembly. Even if WASM had enough built-in APIs to allow you to implement JS without also implementing its runtime, you would lose all of the JIT performance optimizations. There is literally no benefit, aside from being able to implement non-backwards-compatible features (which doesn't feel like a strong reason to me, given the cost).
- BinaryIdiot 8y ago
  > you would lose all of the JIT performance optimizations I don't follow. Why would losing optimizations from one language prevent optimizations from being done in an IL? Are you saying that Web Assembly can't be as fast as JavaScript? If so, why? > There is literally no benefit, aside from being able to implement non-backwards-compatible features You ignored the benefit I outlined above. Why would you want a single scripting language to be the only one to ever be used in a web browser? Heck, web assembly can even make the ECMAScript iteration loop tighter if you really wanted to. I'm having trouble seeing the downsides to this approach.
  - MikeHolman 8y ago
    Browsers are already very optimized for JS. Wasm is not currently a good target for managed languages (you would need to implement your own GC on top of wasm memory), and AOT compilation in general is not good for languages as dynamic as JS.
  - RussianCow 8y ago
    Years of development have gone into making JavaScript in the browser really, really fast. If you re-implement a JS engine on top of WASM, you lose all of that work—unless you do something crazy like compile V8 into WASM, but then the client is going to have to download an enormous payload just to run your app. Even if WASM had APIs for GC, interaction with the DOM and browser APIs, interop with JS, etc, you would still have to compile the JS ahead of time into a static binary, and so the browser would not be able to apply its JIT magic to your code. I'm all for the dream of running any arbitrary language in the browser, but it's simply not realistic for any language that has a large runtime, which is most dynamic languages.
    - pjmlp 8y ago
      Google just discussed WebAssembly 2.0 at IO, those APIs are coming. They also unveiled Autocad running on WebAssembly.
      - Jasper_ 8y ago
        I haven't seen any work from any browser implementers working towards host-bindings or GC. I just skimmed through the I/O talk, as well: AutoCAD was running in a 2D canvas through emscripten in a WebWorker, while the rest of the code was a custom-built React/TypeScript app. Hardly the desktop AutoCAD everyone is thinking of... ... and I didn't spot any mention of "WebAssembly 2.0", whatever that might mean...
        pjmlp 8y ago
        Then watch it properly, pay attention to the announcement of the upcoming APIs like direct references to DOM nodes, bypassing JavaScript. Or how the Autocad guy explains the C++ code is exactly the same as on the core product. We might loose the battle against Electron, but in the end the browser will be just yet another general purpose VM.
- jerf 8y ago
  I believe the .Net world does its JITing based on a bytecode that is at the conceptual level a lot like web assembly. They're not the same, of course, but the point is you can JIT on that sort of thing OK. I won't promise you won't lose some performance, but there's other ways in which that might still be a long-term win as you may be able to gain in other ways relating to exploiting the language you start with. (In the long run, and to be honest even today, if you really deeply care about performance, you don't want a dynamic language. They're slow. We've invested crazy amount of effort into optimizing them, made tons of progress in that optimization vs where we started... and they're still slow. At this point smart money has to be put on that not changing.)
  - Jasper_ 8y ago
    They're nowhere near the same. WASM is based on linear memory and has no concepts of objects and methods. CIL bytecode as used by .NET has a full runtime which has objects, methods and GC. Even with the GC proposal, as currently spec'd, it would not be able to handle .NET's object model. The only similarity, really, is that they're both binary formats.
    - pjmlp 8y ago
      That doesn't stop Microsoft to keep improving Blazor.
      - Jasper_ 8y ago
        Blazor is a .NET interpreter written in C++ that's compiled to WebAssembly. You can think of it as being comparable to Duktape or another JavaScript interpreter being compiled to WebAssembly and running some JavaScript code. It won't JIT anything.
        pjmlp 8y ago
        No it isn't JITing, but you missed the part they are improving CoreRT to use AOT compilation to WebAssembly instead. Just like Unity is already doing with their Lightweight Components and HPC#.
megaman22 8y ago
At that point there's no point in using JavaScript at all, anywhere, so that's a future I'd like to see.
- krapp 8y ago
  At the very least, there would be no point in taking "compiling to javascript" seriously anymore, which is the future I'd like to see.
  - pjmlp 8y ago
    See the Autocad demo at Google IO.
wwwigham 8y ago
JS took over not just because it ran everywhere but also because of the network effects of everyone learning it because it ran everywhere. wasm has no such benefits, as an intermediary format. Nobody's ever going to get a job as a "wasm expert" building anything other than a wasm build pipeline. wasm may afford us more freedom, but that very freedom is in opposition to its broad adoption. It'll certainly be interesting to watch it play out over the next few years. Oh, and: > Alternatively, if you focus on getting web assembly up to speed, you can compile any flavor of JavaScript you want directly to web assembly You can already compile any flavor of JavaScript to... JavaScript. It even maps better than wasm. wasm really doesn't help there. Today's ecosystem _is_ that ecosystem. Except there's some hope that some variants become future core language, unlike if you were using wasm, where you wouldn't even have such a thought because you'd be using a compiler forever. But... If you're ok with that, why wouldn't you be ok with transpiling forever?

crooked-v 8y ago

That would be my preference too. It feels like there are so many possibilities for performance gains and better tooling stuck behind WASM's lack of DOM integration and other native browser libs.

RussianCow 8y ago

Everyone keeps saying this, but it doesn't make sense to compile JavaScript to WebAssembly. Even if WASM had enough built-in APIs to allow you to implement JS without also implementing its runtime, you would lose all of the JIT performance optimizations. There is literally no benefit, aside from being able to implement non-backwards-compatible features (which doesn't feel like a strong reason to me, given the cost).

BinaryIdiot 8y ago
> you would lose all of the JIT performance optimizations I don't follow. Why would losing optimizations from one language prevent optimizations from being done in an IL? Are you saying that Web Assembly can't be as fast as JavaScript? If so, why? > There is literally no benefit, aside from being able to implement non-backwards-compatible features You ignored the benefit I outlined above. Why would you want a single scripting language to be the only one to ever be used in a web browser? Heck, web assembly can even make the ECMAScript iteration loop tighter if you really wanted to. I'm having trouble seeing the downsides to this approach.
- MikeHolman 8y ago
  Browsers are already very optimized for JS. Wasm is not currently a good target for managed languages (you would need to implement your own GC on top of wasm memory), and AOT compilation in general is not good for languages as dynamic as JS.
- RussianCow 8y ago
  Years of development have gone into making JavaScript in the browser really, really fast. If you re-implement a JS engine on top of WASM, you lose all of that work—unless you do something crazy like compile V8 into WASM, but then the client is going to have to download an enormous payload just to run your app. Even if WASM had APIs for GC, interaction with the DOM and browser APIs, interop with JS, etc, you would still have to compile the JS ahead of time into a static binary, and so the browser would not be able to apply its JIT magic to your code. I'm all for the dream of running any arbitrary language in the browser, but it's simply not realistic for any language that has a large runtime, which is most dynamic languages.
  - pjmlp 8y ago
    Google just discussed WebAssembly 2.0 at IO, those APIs are coming. They also unveiled Autocad running on WebAssembly.
    - Jasper_ 8y ago
      I haven't seen any work from any browser implementers working towards host-bindings or GC. I just skimmed through the I/O talk, as well: AutoCAD was running in a 2D canvas through emscripten in a WebWorker, while the rest of the code was a custom-built React/TypeScript app. Hardly the desktop AutoCAD everyone is thinking of... ... and I didn't spot any mention of "WebAssembly 2.0", whatever that might mean...
      - pjmlp 8y ago
        Then watch it properly, pay attention to the announcement of the upcoming APIs like direct references to DOM nodes, bypassing JavaScript. Or how the Autocad guy explains the C++ code is exactly the same as on the core product. We might loose the battle against Electron, but in the end the browser will be just yet another general purpose VM.
jerf 8y ago
I believe the .Net world does its JITing based on a bytecode that is at the conceptual level a lot like web assembly. They're not the same, of course, but the point is you can JIT on that sort of thing OK. I won't promise you won't lose some performance, but there's other ways in which that might still be a long-term win as you may be able to gain in other ways relating to exploiting the language you start with. (In the long run, and to be honest even today, if you really deeply care about performance, you don't want a dynamic language. They're slow. We've invested crazy amount of effort into optimizing them, made tons of progress in that optimization vs where we started... and they're still slow. At this point smart money has to be put on that not changing.)
- Jasper_ 8y ago
  They're nowhere near the same. WASM is based on linear memory and has no concepts of objects and methods. CIL bytecode as used by .NET has a full runtime which has objects, methods and GC. Even with the GC proposal, as currently spec'd, it would not be able to handle .NET's object model. The only similarity, really, is that they're both binary formats.
  - pjmlp 8y ago
    That doesn't stop Microsoft to keep improving Blazor.
    - Jasper_ 8y ago
      Blazor is a .NET interpreter written in C++ that's compiled to WebAssembly. You can think of it as being comparable to Duktape or another JavaScript interpreter being compiled to WebAssembly and running some JavaScript code. It won't JIT anything.
      - pjmlp 8y ago
        No it isn't JITing, but you missed the part they are improving CoreRT to use AOT compilation to WebAssembly instead. Just like Unity is already doing with their Lightweight Components and HPC#.

megaman22 8y ago

At that point there's no point in using JavaScript at all, anywhere, so that's a future I'd like to see.

krapp 8y ago
At the very least, there would be no point in taking "compiling to javascript" seriously anymore, which is the future I'd like to see.
- pjmlp 8y ago
  See the Autocad demo at Google IO.

wwwigham 8y ago

JS took over not just because it ran everywhere but also because of the network effects of everyone learning it because it ran everywhere. wasm has no such benefits, as an intermediary format. Nobody's ever going to get a job as a "wasm expert" building anything other than a wasm build pipeline. wasm may afford us more freedom, but that very freedom is in opposition to its broad adoption. It'll certainly be interesting to watch it play out over the next few years. Oh, and: > Alternatively, if you focus on getting web assembly up to speed, you can compile any flavor of JavaScript you want directly to web assembly You can already compile any flavor of JavaScript to... JavaScript. It even maps better than wasm. wasm really doesn't help there. Today's ecosystem _is_ that ecosystem. Except there's some hope that some variants become future core language, unlike if you were using wasm, where you wouldn't even have such a thought because you'd be using a compiler forever. But... If you're ok with that, why wouldn't you be ok with transpiling forever?