6 ms·

My excitement for WASM has nothing to do with speed or efficiency of the runtime. It's all about finally having a universal compile target for the web. We're fi

My excitement for WASM has nothing to do with speed or efficiency of the runtime. It's all about finally having a universal compile target for the web. We're finally going to be able to develop web apps in a proper language of our own choosing, without needing hacks like TypeScript. Hopefully, this will lead to real dedicated IDE tooling and standardized libraries for the web along the lines of what's available in iOS and Android native development.

themihai 10y ago
That's what I find great too, though for some reasons they put too much emphasis on JS-wasm compatibility and less on language support(i.e DOM or GC are considered "unicorn" features). I'm pretty sure 90% of the web developers won't mix js with wasm once they can compile their preferred language to wasm. You will find either js apps or wasm apps. There may be also a very small percent of js apps with wasm modules(i.e for video decoding)
- vonklaus 10y ago
  They are trying to convert current web devs. JS is the language of the browser and essentially the web, so most developers working in webdev primarily work w/ js.
  - gjjrfcbugxbhf 10y ago
    Actually many of us use es6 with a compiler to turn into some dialect of js that runs in browsers. We will hardly notice if our code starts getting compiled to wasm instead..
    - v413 10y ago
      JS will not compile to WASM.
      - yumaikas 10y ago
        Eh, there isn't any reason that it couldn't at some point in the future. That won't be happening any time soon, but I'd love to see that day, personally.
        rkangel 10y ago
        Lack of GC in WASM would make that difficult right now. But yes, that's the future I'd like to see. Browsers only have a WASM engine, and provide a JS->WASM compiler client-side for backwards compatibility.
        marcosdumay 10y ago
        GC is just something you implement on the language runtime.
        dcherman 10y ago
        Then you're shipping the entire (or at least large pieces of) language runtime to the client since presumably, you'd need to compile that to WASM as well.
        marcosdumay 10y ago
        You can probably fit the runtime in a 10th of the size of JQuery. You'll need most of a runtime anyway, since it provides much more than GC.
        gjjrfcbugxbhf 10y ago
        Something that never really worked was cached versions of jquery (and similar) from cdn. One reason is that browsers didn't give them any particular precedence. The other was that jquery was moving quite fast compared to devs using it so as an end user i nearly never benefited from the caching. I wonder if this might work better for language run times. Maybe browsers could be provided with some manifest saying 'this site needs python 3+' or 'this site needs python 3-3.5' so that end users end up with less runtimes cached.
  - themihai 10y ago
    The JS devs don't really need wasm. JS works just fine in browser. I find the use cases mentioned (js app + high performance wasm modules) limited to a very small niche. WASM is supposed to be a target language. Are they trying to convert current web devs to C++/rust devs? It doesn't make any sense to me. If wasm was designed just to help JS to do more then it is doomed to fail.
    - aphextron 10y ago
      >JS works just fine in browser. Sure it does. And the myriad of languages that pop up to support WASM will work infinitely better. ES6 was a huge step forward, but it's still a long way from a real language like C#. I suspect Javascript development will always be a thing, but that front end development will fracture into multiple different languages and runtimes as full WASM support comes online.
      - joshuahutt 10y ago
        > a real language like C# While I can agree that C# has tons of language features that make it more powerful than JavaScript, I take issue with the idea that those features are the defining characteristic of a "real" language. I think there are many reasons to choose C# over JS, but there are also a non-trivial of reasons to make the opposite choice. https://blog.codinghorror.com/the-principle-of-least-power/ https://blog.codinghorror.com/the-principle-of-least-power/
deleted 10y ago
[deleted]
charlieflowers 10y ago
True. I agree with it all. However, by then, TypeScript might be so darn good that people choose to keep going with it! It really does have a better type system than C# in a lot of ways.
- tonyedgecombe 10y ago
  It could be another target for TypeScript though.
  - v413 10y ago
    Typescript is designed to be compiled to JS. WASM is designed for staticly compiled languages. Even if there is GC and DOM access through WASM, Typescript will be better off to run for the natively JIT optimized JS path.
    - oneweekwonder 10y ago
      Really? Anders Hejlsberg is in charge of TypeScript and a apt compiler architect with a proven track record(turbo pascal, delphi, .net/C#).
      - readittwice 10y ago
        Sure, Anders is great but this not so easy. Basically you would have to re-implement all the features and optimizations of current JS-Engines. In WASM you are restricted to the given (statically-typed) opcodes, while a JS-JIT has more knowledge about program semantics and can thus apply optimizations more easily. In addition the JIT can also make use of hand-written assembly if it is needed for best performance. I think JRuby does a similar thing for Ruby and Java Bytecode. TruffleRuby shows that it is possible to be faster, they do not compile to bytecode and use their own compiler.
        RussianCow 10y ago
        Sure, but all else being equal, a statically typed language will always be faster than a dynamically typed one, because you can do way more optimization at compile-time rather than run-time. So you're right in that JS is pretty darn fast, but it probably wouldn't take that much effort to surpass JS performance with a custom TypeScript -> WASM compiler.
scriptproof 10y ago
You can write wasm. It is the official shortcut (not an acronym). Source: http://webassembly.org/ http://webassembly.org/
- unwind 10y ago
  *Abbreviation (https://github.com/WebAssembly/design/issues/980 https://github.com/WebAssembly/design/issues/980).
amelius 10y ago
Is it possible to run an efficient garbage-collected runtime system on top of WASM? And how about a multithreaded one?
jlebrech 10y ago
Leading to real IDEs, real languages, real libraries. downsides will be some proprietary solutions will crop up.
- vikas0380 10y ago
  There is no harm in that
zurn 10y ago
JS provided that already without WebAssembly, no?
- mkawia 10y ago
  I don't understand why the downvotes , JS is one of the most target languages. Elm,GHJS(Haskell),Purescript,Clojurescript and supersets like Typescript which come with their own toolchains.
  - fulafel 10y ago
    Also Javascript itself is frequently compiled down to an older version of Javascript.
- bluejekyll 10y ago
  Asm.js was exactly what your talking about. You can think of webassembly more like a common standard akin to the JVM specification. Anyone can implement the spec. It's a formal definition of what people are doing with JS.

themihai 10y ago

That's what I find great too, though for some reasons they put too much emphasis on JS-wasm compatibility and less on language support(i.e DOM or GC are considered "unicorn" features). I'm pretty sure 90% of the web developers won't mix js with wasm once they can compile their preferred language to wasm. You will find either js apps or wasm apps. There may be also a very small percent of js apps with wasm modules(i.e for video decoding)

vonklaus 10y ago
They are trying to convert current web devs. JS is the language of the browser and essentially the web, so most developers working in webdev primarily work w/ js.
- gjjrfcbugxbhf 10y ago
  Actually many of us use es6 with a compiler to turn into some dialect of js that runs in browsers. We will hardly notice if our code starts getting compiled to wasm instead..
  - v413 10y ago
    JS will not compile to WASM.
    - yumaikas 10y ago
      Eh, there isn't any reason that it couldn't at some point in the future. That won't be happening any time soon, but I'd love to see that day, personally.
      - rkangel 10y ago
        Lack of GC in WASM would make that difficult right now. But yes, that's the future I'd like to see. Browsers only have a WASM engine, and provide a JS->WASM compiler client-side for backwards compatibility.
        marcosdumay 10y ago
        GC is just something you implement on the language runtime.
        dcherman 10y ago
        Then you're shipping the entire (or at least large pieces of) language runtime to the client since presumably, you'd need to compile that to WASM as well.
        marcosdumay 10y ago
        You can probably fit the runtime in a 10th of the size of JQuery. You'll need most of a runtime anyway, since it provides much more than GC.
        gjjrfcbugxbhf 10y ago
        Something that never really worked was cached versions of jquery (and similar) from cdn. One reason is that browsers didn't give them any particular precedence. The other was that jquery was moving quite fast compared to devs using it so as an end user i nearly never benefited from the caching. I wonder if this might work better for language run times. Maybe browsers could be provided with some manifest saying 'this site needs python 3+' or 'this site needs python 3-3.5' so that end users end up with less runtimes cached.
- themihai 10y ago
  The JS devs don't really need wasm. JS works just fine in browser. I find the use cases mentioned (js app + high performance wasm modules) limited to a very small niche. WASM is supposed to be a target language. Are they trying to convert current web devs to C++/rust devs? It doesn't make any sense to me. If wasm was designed just to help JS to do more then it is doomed to fail.
  - aphextron 10y ago
    >JS works just fine in browser. Sure it does. And the myriad of languages that pop up to support WASM will work infinitely better. ES6 was a huge step forward, but it's still a long way from a real language like C#. I suspect Javascript development will always be a thing, but that front end development will fracture into multiple different languages and runtimes as full WASM support comes online.
    - joshuahutt 10y ago
      > a real language like C# While I can agree that C# has tons of language features that make it more powerful than JavaScript, I take issue with the idea that those features are the defining characteristic of a "real" language. I think there are many reasons to choose C# over JS, but there are also a non-trivial of reasons to make the opposite choice. https://blog.codinghorror.com/the-principle-of-least-power/ https://blog.codinghorror.com/the-principle-of-least-power/

deleted 10y ago

[deleted]

charlieflowers 10y ago

True. I agree with it all. However, by then, TypeScript might be so darn good that people choose to keep going with it! It really does have a better type system than C# in a lot of ways.

tonyedgecombe 10y ago
It could be another target for TypeScript though.
- v413 10y ago
  Typescript is designed to be compiled to JS. WASM is designed for staticly compiled languages. Even if there is GC and DOM access through WASM, Typescript will be better off to run for the natively JIT optimized JS path.
  - oneweekwonder 10y ago
    Really? Anders Hejlsberg is in charge of TypeScript and a apt compiler architect with a proven track record(turbo pascal, delphi, .net/C#).
    - readittwice 10y ago
      Sure, Anders is great but this not so easy. Basically you would have to re-implement all the features and optimizations of current JS-Engines. In WASM you are restricted to the given (statically-typed) opcodes, while a JS-JIT has more knowledge about program semantics and can thus apply optimizations more easily. In addition the JIT can also make use of hand-written assembly if it is needed for best performance. I think JRuby does a similar thing for Ruby and Java Bytecode. TruffleRuby shows that it is possible to be faster, they do not compile to bytecode and use their own compiler.
      - RussianCow 10y ago
        Sure, but all else being equal, a statically typed language will always be faster than a dynamically typed one, because you can do way more optimization at compile-time rather than run-time. So you're right in that JS is pretty darn fast, but it probably wouldn't take that much effort to surpass JS performance with a custom TypeScript -> WASM compiler.

scriptproof 10y ago

You can write wasm. It is the official shortcut (not an acronym). Source: http://webassembly.org/ http://webassembly.org/

unwind 10y ago
*Abbreviation (https://github.com/WebAssembly/design/issues/980 https://github.com/WebAssembly/design/issues/980).

amelius 10y ago

Is it possible to run an efficient garbage-collected runtime system on top of WASM? And how about a multithreaded one?

jlebrech 10y ago

Leading to real IDEs, real languages, real libraries. downsides will be some proprietary solutions will crop up.

vikas0380 10y ago
There is no harm in that

zurn 10y ago

JS provided that already without WebAssembly, no?

mkawia 10y ago
I don't understand why the downvotes , JS is one of the most target languages. Elm,GHJS(Haskell),Purescript,Clojurescript and supersets like Typescript which come with their own toolchains.
- fulafel 10y ago
  Also Javascript itself is frequently compiled down to an older version of Javascript.
bluejekyll 10y ago
Asm.js was exactly what your talking about. You can think of webassembly more like a common standard akin to the JVM specification. Anyone can implement the spec. It's a formal definition of what people are doing with JS.