16 ms·

What seems most important about WebAssembly is that it is essentially a universal language runtime. It's not that what it brings to the web is unimportant, just

What seems most important about WebAssembly is that it is essentially a universal language runtime. It's not that what it brings to the web is unimportant, just that it seems like we're also getting a way to do truly cross-platform language deployment as a bonus. Am I wrong about this?

randiantech 10y ago
Well, Java bytecode already does that. The cool thing about WebAssembly is that runs (or will run) on any browser.
- kuschku 10y ago
  Maybe they should have just used Java bytecode as WASM format? Then we’d have an entire existing ecosystem available.
  - futurix 10y ago
    Not with Oracle being litigious pricks.
    - dawidloubser 10y ago
      Hear hear! Java was on a great trajectory before being stagnated by corporations and politics. Such a pity, because now we have to re-invent it. The silver lining, is that many things usually get better the second time around. Let's see what WASM hold - it's pretty limited in its current form.
      - kuschku 10y ago
        *The third time around FTFY. The second time around is usually so troubled by politics that there's an entire Wikipedia page about the topic of the second-version syndrome. And WebASM is in every way inferior to Java still.
- deleted 10y ago
  [deleted]
- q3r3qr3q 10y ago
  Like how Java used to?
- ajross 10y ago
  Java bytecode already did that too. The cool thing about WebAssembly is that we all think it might actually happen this time.
- throwawaysbdi 10y ago
  Is it just me or do Java applets seem like they were way the hell ahead of their time? If the sandbox didn't have so many holes in it Java applets were arguably better for webapps than the unholy mess we've cobbled together over the last ten years to replace them. It's sad to me that Java fell out of the browser and was replaced with a slow non standardized single threaded shit language for almost ten years just because Java didn't have DOM access. JavaScript is just nearing Java feature parity and still not anywhere close for performance. And I'll tell you what Java didn't have. A unfathomable clusterfuck of module systems, transpilers, shit build tools and IDE support, crazy syntax gotchas, unholy and inconsistent exception handling systems. God dammit what have we done. Shakes cane at neighborhood kids
  - wybiral 10y ago
    The performance of JS these days, for such a dynamic language, is actually very impressive. If Java were our only option I assure you we'd have come up with all kinds of crazy alternative systems of doing things. Plus, targeting the JVM for weird transpiled language was what all of the cool kids did before doing it in JS became cool. This isn't unique to JS. It's probably unique to any language with that much adoption.
  - orangecat 10y ago
    do Java applets seem like they were way the hell ahead of their time? Pretty much. If Sun had made a decent plugin instead of expecting every browser to roll their own VM, and if AWT had been a lot less buggy, it could have worked. A unfathomable clusterfuck of module systems, transpilers, shit build tools and IDE support, crazy syntax gotchas, unholy and inconsistent exception handling systems. Amen. It's ridiculous how many millions of engineer-hours have been spent trying to turn JS into a usable environment.
    - wybiral 10y ago
      > Amen. It's ridiculous how many millions of engineer-hours have been spent trying to turn JS into a usable environment. It's not just JS: https://en.wikipedia.org/wiki/List_of_JVM_languages https://en.wikipedia.org/wiki/List_of_JVM_languages
muizelaar 10y ago
WebAssembly is not a universal language runtime. Currently it really only handles C style Ahead-Of-Time compiled languages. e.g. if you wanted to implement a JS JIT or really any other kind of JIT on top of WebAssembly you're going to have a really bad time.
- cm2187 10y ago
  What's the problem with running a CLR within webassembly?
  - jeswin 10y ago
    I don't think it has GC at the moment. It might be alright if the GC doesn't show up for a few years; languages like Rust can demonstrate bare-metal, stutter-free performance on the Web.
    - cm2187 10y ago
      But wouldn't the CLR run its own GC?
      - cormacrelf 10y ago
        You'd have to compile the CLR itself into wasm first, which I'm guessing wouldn't necessarily run that well. Language runtimes often provide stuff like os-independent threading or green threads, which have to be implemented all over again for wasm's threading model (I'm not sure it even exists yet). Some CLR features would be redundant, like the security model or the profiling API... and then you'd need to compile your C#/VB/F# down to managed CLR code without using the .NET Framework at all, since so much of .NET depends on having stuff wasm can't provide (not even .NET Core has few enough features to run on wasm). Either you make '.NET Core Core Web Edition Preview 3' and make library developers explicitly target this new framework subset so you can use it, or you just give up and recognise that without most of .NET it's not that worthwhile having C# in the browser. The difficulties for language developers are on two fronts really. #1 is producing WASM in a compiler backend, instead of LLVM IR / Java bytecode / bare machine code. #2 is getting the language small enough to be possible and not wasteful to implement in wasm. You don't have a filesystem, or really anything a regular OS provides, so you have to be able to strip those language / stdlib features away. Rust is often cited as a go-to because it can already do #2 easily: #![no_std] strips out the os-dependendent standard library and essentially all of the already tiny stack-unwinding 'runtime'. #1 can be done with an LLVM backend, though it's still a bit of a hack and Rust would prefer to skip LLVM and that whole redundant optimisation phase entirely. Most importantly, CLR and .NET are just too heavyweight for anyone to bother writing any wasm code in. What are the uses for wasm as it stands? There's basically no DOM interaction yet, so just really fast optimised code that has no OS interaction for crypto and other CPU-heavy tasks. You can't write a game targeting wasm, but you could outsource your ray-tracer there. Plain C++ and Rust are good at that. CLR/.NET is pretty quick when JITing x86 but wouldn't be worth the tremendous effort to port to wasm when you already have C++ and Rust, and they'd still be quicker in the end anyway. Lastly there's the question of how to run a JIT at all within wasm. I don't think there is a way of creating executable memory regions (ie x86) within wasm, because wasm is independent of who's running it. You would have to instead generate executable wasm regions, which would need to be parsed again... all of which sounds fairly impossible too, as far as I know.
jtth 10y ago
We are hurtling faster and faster towards this talk every day https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- Ajedi32 10y ago
  I kinda see the future in that talk as that as a worthwhile goal. If we could get all the security and interoperability advantages of the web but with native-level performance, support for multiple languages, and backwards-compatibility with legacy software that'd be huge.
munificent 10y ago
Every Turing complete language is a universe language runtime. The interesting question is whether it's a good universal language runtime, and what kind of languages it's best for. Today, WASM doesn't support GC, which means it's unlikely to be a good runtime for any language that wants to automatically manage memory and interact with the DOM (which needs to have its own GC).
- throwawaysbdi 10y ago
  So wasm is a bytecode format like Java or C#'s IL except it basically has no runtime? Why don't we just use an existing bytecode format and skip all the pointless design? LLVM? Android DEX? Java Class or C# IL formats aren't enough? Hell if we use one of those bytecode formats we could reuse the runtime too! I'm sure there's probably 20+ bytecode formats and I'm rolling my eyes that we need yet another for the web....
  - Rusky 10y ago
    This has been brought up several times in this thread, but none of those bytecodes is sufficient. LLVM is not platform-agnostic, JVM/IL are sub-optimal for languages like C++. None of those platforms' security models are as good as the web's, either, nor are their runtimes able to work well in that context.
  - legulere 10y ago
    Java (including dex) and IL bytecodes are too high level. They assume that everything is laid out in garbage collected classes. This basically means that programming languages usually have to be specially designed for them. There's ironpython, but it's not fully compatible with python for instance. LLVM IR is designed as a compiler IR and hardly useful for this usecase, as it is unstable, target-specific and has a complicated largely undocumented bitcode format (I don't know any reimplementations). It has been tried with PNaCl and the original SPIR, but both projects abandoned LLVM-IR/ were abandoned.
  - coldtea 10y ago
    >Why don't we just use an existing bytecode format and skip all the pointless design? LLVM? Android DEX? Java Class or C# IL formats aren't enough? Because the major browser devs that designed WebAssembly are not smart enough to have thought this /s
dawidloubser 10y ago
Kinda like the Java VM, 20 years ago :-)

randiantech 10y ago

Well, Java bytecode already does that. The cool thing about WebAssembly is that runs (or will run) on any browser.

kuschku 10y ago
Maybe they should have just used Java bytecode as WASM format? Then we’d have an entire existing ecosystem available.
- futurix 10y ago
  Not with Oracle being litigious pricks.
  - dawidloubser 10y ago
    Hear hear! Java was on a great trajectory before being stagnated by corporations and politics. Such a pity, because now we have to re-invent it. The silver lining, is that many things usually get better the second time around. Let's see what WASM hold - it's pretty limited in its current form.
    - kuschku 10y ago
      *The third time around FTFY. The second time around is usually so troubled by politics that there's an entire Wikipedia page about the topic of the second-version syndrome. And WebASM is in every way inferior to Java still.
deleted 10y ago
[deleted]
q3r3qr3q 10y ago
Like how Java used to?
ajross 10y ago
Java bytecode already did that too. The cool thing about WebAssembly is that we all think it might actually happen this time.
throwawaysbdi 10y ago
Is it just me or do Java applets seem like they were way the hell ahead of their time? If the sandbox didn't have so many holes in it Java applets were arguably better for webapps than the unholy mess we've cobbled together over the last ten years to replace them. It's sad to me that Java fell out of the browser and was replaced with a slow non standardized single threaded shit language for almost ten years just because Java didn't have DOM access. JavaScript is just nearing Java feature parity and still not anywhere close for performance. And I'll tell you what Java didn't have. A unfathomable clusterfuck of module systems, transpilers, shit build tools and IDE support, crazy syntax gotchas, unholy and inconsistent exception handling systems. God dammit what have we done. Shakes cane at neighborhood kids
- wybiral 10y ago
  The performance of JS these days, for such a dynamic language, is actually very impressive. If Java were our only option I assure you we'd have come up with all kinds of crazy alternative systems of doing things. Plus, targeting the JVM for weird transpiled language was what all of the cool kids did before doing it in JS became cool. This isn't unique to JS. It's probably unique to any language with that much adoption.
- orangecat 10y ago
  do Java applets seem like they were way the hell ahead of their time? Pretty much. If Sun had made a decent plugin instead of expecting every browser to roll their own VM, and if AWT had been a lot less buggy, it could have worked. A unfathomable clusterfuck of module systems, transpilers, shit build tools and IDE support, crazy syntax gotchas, unholy and inconsistent exception handling systems. Amen. It's ridiculous how many millions of engineer-hours have been spent trying to turn JS into a usable environment.
  - wybiral 10y ago
    > Amen. It's ridiculous how many millions of engineer-hours have been spent trying to turn JS into a usable environment. It's not just JS: https://en.wikipedia.org/wiki/List_of_JVM_languages https://en.wikipedia.org/wiki/List_of_JVM_languages

muizelaar 10y ago

WebAssembly is not a universal language runtime. Currently it really only handles C style Ahead-Of-Time compiled languages. e.g. if you wanted to implement a JS JIT or really any other kind of JIT on top of WebAssembly you're going to have a really bad time.

cm2187 10y ago
What's the problem with running a CLR within webassembly?
- jeswin 10y ago
  I don't think it has GC at the moment. It might be alright if the GC doesn't show up for a few years; languages like Rust can demonstrate bare-metal, stutter-free performance on the Web.
  - cm2187 10y ago
    But wouldn't the CLR run its own GC?
    - cormacrelf 10y ago
      You'd have to compile the CLR itself into wasm first, which I'm guessing wouldn't necessarily run that well. Language runtimes often provide stuff like os-independent threading or green threads, which have to be implemented all over again for wasm's threading model (I'm not sure it even exists yet). Some CLR features would be redundant, like the security model or the profiling API... and then you'd need to compile your C#/VB/F# down to managed CLR code without using the .NET Framework at all, since so much of .NET depends on having stuff wasm can't provide (not even .NET Core has few enough features to run on wasm). Either you make '.NET Core Core Web Edition Preview 3' and make library developers explicitly target this new framework subset so you can use it, or you just give up and recognise that without most of .NET it's not that worthwhile having C# in the browser. The difficulties for language developers are on two fronts really. #1 is producing WASM in a compiler backend, instead of LLVM IR / Java bytecode / bare machine code. #2 is getting the language small enough to be possible and not wasteful to implement in wasm. You don't have a filesystem, or really anything a regular OS provides, so you have to be able to strip those language / stdlib features away. Rust is often cited as a go-to because it can already do #2 easily: #![no_std] strips out the os-dependendent standard library and essentially all of the already tiny stack-unwinding 'runtime'. #1 can be done with an LLVM backend, though it's still a bit of a hack and Rust would prefer to skip LLVM and that whole redundant optimisation phase entirely. Most importantly, CLR and .NET are just too heavyweight for anyone to bother writing any wasm code in. What are the uses for wasm as it stands? There's basically no DOM interaction yet, so just really fast optimised code that has no OS interaction for crypto and other CPU-heavy tasks. You can't write a game targeting wasm, but you could outsource your ray-tracer there. Plain C++ and Rust are good at that. CLR/.NET is pretty quick when JITing x86 but wouldn't be worth the tremendous effort to port to wasm when you already have C++ and Rust, and they'd still be quicker in the end anyway. Lastly there's the question of how to run a JIT at all within wasm. I don't think there is a way of creating executable memory regions (ie x86) within wasm, because wasm is independent of who's running it. You would have to instead generate executable wasm regions, which would need to be parsed again... all of which sounds fairly impossible too, as far as I know.

jtth 10y ago

We are hurtling faster and faster towards this talk every day https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

Ajedi32 10y ago
I kinda see the future in that talk as that as a worthwhile goal. If we could get all the security and interoperability advantages of the web but with native-level performance, support for multiple languages, and backwards-compatibility with legacy software that'd be huge.

munificent 10y ago

Every Turing complete language is a universe language runtime. The interesting question is whether it's a good universal language runtime, and what kind of languages it's best for. Today, WASM doesn't support GC, which means it's unlikely to be a good runtime for any language that wants to automatically manage memory and interact with the DOM (which needs to have its own GC).

throwawaysbdi 10y ago
So wasm is a bytecode format like Java or C#'s IL except it basically has no runtime? Why don't we just use an existing bytecode format and skip all the pointless design? LLVM? Android DEX? Java Class or C# IL formats aren't enough? Hell if we use one of those bytecode formats we could reuse the runtime too! I'm sure there's probably 20+ bytecode formats and I'm rolling my eyes that we need yet another for the web....
- Rusky 10y ago
  This has been brought up several times in this thread, but none of those bytecodes is sufficient. LLVM is not platform-agnostic, JVM/IL are sub-optimal for languages like C++. None of those platforms' security models are as good as the web's, either, nor are their runtimes able to work well in that context.
- legulere 10y ago
  Java (including dex) and IL bytecodes are too high level. They assume that everything is laid out in garbage collected classes. This basically means that programming languages usually have to be specially designed for them. There's ironpython, but it's not fully compatible with python for instance. LLVM IR is designed as a compiler IR and hardly useful for this usecase, as it is unstable, target-specific and has a complicated largely undocumented bitcode format (I don't know any reimplementations). It has been tried with PNaCl and the original SPIR, but both projects abandoned LLVM-IR/ were abandoned.
- coldtea 10y ago
  >Why don't we just use an existing bytecode format and skip all the pointless design? LLVM? Android DEX? Java Class or C# IL formats aren't enough? Because the major browser devs that designed WebAssembly are not smart enough to have thought this /s

dawidloubser 10y ago

Kinda like the Java VM, 20 years ago :-)