1. 5
  1.  

  2. 1

    I have mostly been ignoring the whole WASM thing as I feel it is merely going to make things worse…

    It’s the old, “Syntax doesn’t really matter, Syntax is just sugar. It’s the semantics of a language that make a language a language”.

    So it seems to me WASM is just JavaScript uglified by removing all syntactic sugar to lay bare the JavaScript semantics.

    ie. No matter which language you choose to sugar it with…. the semantics won’t be and can’t be changed.

    So you’re going to end up with pages like https://clojurescript.org/about/differences (and worse) for every language that compiles to WASM.

    Am I missing something?

    1. 2

      WASM isn’t JS and JS can’t compile to WASM. It’s a lower level that doesn’t even feature a GC. Think more bytecode, than uglified JS.

      A quick scroll through the instruction set gives you a pretty good idea of what it provides. Compiling to WASM allows for some substantial performance benefits over it’s JS counterpart in initial start time and a number of scenarios in runtime. Realistically, however, most web developers at this point in time will not have any use for it.

      There is still a bit of work needed to provide WASM with the ability to interact with the DOM directly rather than bridge through JS. How they are going to achieve this, I don’t know. It’s is the main feature I am looking forward to as it will allow VDOM implementations to be optimized further, and incorporated into languages like rust. See asm-dom for example

      1. 1

        So it seems to me WASM is just JavaScript uglified by removing all syntactic sugar to lay bare the JavaScript semantics.

        That’s not the case at all. There is JS interop but it’s unrelated to JS. It doesn’t even have GC, for starters (as mentioned in the post.)