3 ms·

I don't care if it's faster, the same or even slightly slower. The sooner I can start working on large applications with a strongly typed language (that isn't

I don't care if it's faster, the same or even slightly slower. The sooner I can start working on large applications with a strongly typed language (that isn't just transpiled to JS) - the better.

eatonphil 5y ago
My point is that compilation targets are somewhat arbitrary. Non-JavaScript languages have been compiling to JavaScript for a long time. What difference does it make for you as a user of a language that it compiles to webassembly than to JavaScript or any other VM?
- laszlokorte 5y ago
  JavaScript being garbage-collected, having a rather complex runtime, not having proper integers etc... makes it a rather unfortunate compile target. Yes you can do it and it is done but js idiosyncrasies leak into the source langues pretty easily.
  - eatonphil 5y ago
    That's a good argument but more of a maintainer argument than a user argument. From a user it should be transparent except for performance and FFIs.
    - laszlokorte 5y ago
      Well the user perspective is: suddenly there a compilers for all kind of languages targetting the browser because wasm makes it easier for the maintainers to build them. Sure you could have implemented unsigned integer semantics on top of bool-arrays in javascript years ago but if the result is too slow you have gained because the compiled c++ code does not run fast enough to be usable.
      - josephg 5y ago
        Regarding numbers, Javascript supports bigints now - which makes the situation a little bit better. (But maybe a lot more complex). I wish they were somehow better supported by JSON.parse though. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- spiffytech 5y ago
  Compile-to-JS is a leaky abstraction that gets messy when JavaScript's type system and built-ins collide with your language's. Some languages also need specialized tooling for their compile-to-JS stuff, rather than treating it as just another compile target. I usually find it causes more problems than it solves, but I'm hopeful that someday WebAssembly can make compile-for-Web transparent enough that non-JS languages really feel like a great experience in the browser.
cercatrova 5y ago
You could use Dart I guess, Flutter is similar to WASM apps like Figma in that they manipulate a canvas, not the DOM directly. I'd assume most WASM apps in the future will look more like that than true DOM manipulation. There are others however, such as Yew written in Rust, or Blazor in C#.
- mhoad 5y ago
  Interestingly enough Dart is also pretty deep into adding WASM as a compile target to act as an alternative to the current compile to optimised JS approach they do currently in the browser. You are right though they are going to be the first big WASM / Canvas and WebGPU framework as opposed to the generations of JS / DOM. It will be interesting to see where they land with it, I’m quietly hopeful especially once you get AOM sorted in the browser too. I think the real test is going to be when they decide to migrate over the multiple billion dollars of revenue project that Google Ads is from JS based Dart to WASM based Dart. Work going on here but not much to look at now just source and no docs https://github.com/dart-lang/sdk/tree/main/pkg/dart2wasm https://github.com/dart-lang/sdk/tree/main/pkg/dart2wasm

I don't care if it's faster, the same or even slightly slower. The sooner I can start working on large applications with a strongly typed language (that isn't just transpiled to JS) - the better.

eatonphil 5y ago

My point is that compilation targets are somewhat arbitrary. Non-JavaScript languages have been compiling to JavaScript for a long time. What difference does it make for you as a user of a language that it compiles to webassembly than to JavaScript or any other VM?

laszlokorte 5y ago
JavaScript being garbage-collected, having a rather complex runtime, not having proper integers etc... makes it a rather unfortunate compile target. Yes you can do it and it is done but js idiosyncrasies leak into the source langues pretty easily.
- eatonphil 5y ago
  That's a good argument but more of a maintainer argument than a user argument. From a user it should be transparent except for performance and FFIs.
  - laszlokorte 5y ago
    Well the user perspective is: suddenly there a compilers for all kind of languages targetting the browser because wasm makes it easier for the maintainers to build them. Sure you could have implemented unsigned integer semantics on top of bool-arrays in javascript years ago but if the result is too slow you have gained because the compiled c++ code does not run fast enough to be usable.
    - josephg 5y ago
      Regarding numbers, Javascript supports bigints now - which makes the situation a little bit better. (But maybe a lot more complex). I wish they were somehow better supported by JSON.parse though. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
spiffytech 5y ago
Compile-to-JS is a leaky abstraction that gets messy when JavaScript's type system and built-ins collide with your language's. Some languages also need specialized tooling for their compile-to-JS stuff, rather than treating it as just another compile target. I usually find it causes more problems than it solves, but I'm hopeful that someday WebAssembly can make compile-for-Web transparent enough that non-JS languages really feel like a great experience in the browser.

cercatrova 5y ago

You could use Dart I guess, Flutter is similar to WASM apps like Figma in that they manipulate a canvas, not the DOM directly. I'd assume most WASM apps in the future will look more like that than true DOM manipulation. There are others however, such as Yew written in Rust, or Blazor in C#.

mhoad 5y ago
Interestingly enough Dart is also pretty deep into adding WASM as a compile target to act as an alternative to the current compile to optimised JS approach they do currently in the browser. You are right though they are going to be the first big WASM / Canvas and WebGPU framework as opposed to the generations of JS / DOM. It will be interesting to see where they land with it, I’m quietly hopeful especially once you get AOM sorted in the browser too. I think the real test is going to be when they decide to migrate over the multiple billion dollars of revenue project that Google Ads is from JS based Dart to WASM based Dart. Work going on here but not much to look at now just source and no docs https://github.com/dart-lang/sdk/tree/main/pkg/dart2wasm https://github.com/dart-lang/sdk/tree/main/pkg/dart2wasm