4 ms·

Most of my early excitement for WASM circled around “Hey, I can finally use a decent language on the web” but since then I have grown to love TypeScript, so a l

by donatj 6y ago

Most of my early excitement for WASM circled around “Hey, I can finally use a decent language on the web” but since then I have grown to love TypeScript, so a lot of that early excitement has been tempered. I have done a number of experiments with Go’s WASM target, one of the earliest and silliest porting Go’s “Otto” JavaScript runtime to WASM, so you can much less efficiently run ES3 JavaScript in a browser. I have also been working on porting a number of tools I currently have that run server side with web frontends to pure WASM. I have had mixed success here however and have found interacting with web elements and JavaScript from Go an awkward, non statically validated, frustrating experience of trial-and-error that somewhat undermines the joy of a statically typed language. On top of everything, Go’s .wasm files are frustratingly large, “Hello World” starting at 1mb and growing quickly from there. All that said though, it is pretty magical seeing something written as a CLI tool running in a browser with minimal changes.

the_duke 6y ago
Go has to embed it's runtime and GC into builds, so build size and performance will take a hit here. Same goes for most popular languages. For me Rust offers the best WASM experience and tooling at the moment. Rust has no GC and (almost) no runtime. It also has official wasm build target support out of the box, including generating Typescript definitions for Rust types. The ecosystem is somewhat well-developed: * wasm-bindgen for general interop in both directions * js-sys / web-sys for (low-level) type-safe and surprisingly efficient browser API bindings * wasm-bindgen-futures for easy Promise <-> Future interop * wasm-pack for easy building * ... Getting the code size low is still a challenge though. A Rust implementation of the Krausest frontend framework benchmark takes a top 4 spot [1]. Despite this benchmark not favouring wasm at all since it requires little computation and mostly does FFI calls. (ps: C++ is in a decent state as well) [1] https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...
- pjmlp 6y ago
  It is still much smaller than most SPA used to display static text.
- amelius 6y ago
  > Go has to embed it's runtime and GC into builds, so build size and performance will take a hit here I expect that WASM doesn't have the concurrency model required by a modern concurrent garbage collector like Go's, but perhaps I'm wrong.
  - foota 6y ago
    It's likely much slower, but it should be able to run just fine single threaded as well.
- pansa2 6y ago
  > C++ is in a decent state as well I’d still choose Go or Rust over C++, though, because they’re memory-safe. This recent discussion shows that’s still important in the context of WebAssembly: https://news.ycombinator.com/item?id=24216764 https://news.ycombinator.com/item?id=24216764
  - the_duke 6y ago
    Sure, for new projects I choose Rust over C++ whenever feasible. But a huge amount of the worlds software is written in C++, and will remain so for decades. Getting some of that code to run well in WASM can be a big win for certain domains.
  - stjohnswarts 6y ago
    Modern C++ has a lot of memory safe operations if you use them (smart pointers, atomics, actually using RAII properly and universally), although I'm not sure how much overhead they might add to a wasm blob. Rust seems almost perfect for it though, but no reason to discourage C++ people; it can be a relatively modern language if you let it.
    - pjmlp 6y ago
      As someone that loves still having C++ on the toolbox, that is unfortunately only true if you have 100% control over the source code and have all team on modern C++ mindset.
maxgraey 6y ago
Perhaps if you like TypeScript and still want compile to WebAssembly you might be interested in AssemblyScript which stricter subset of TypeScript which compile to wasm
- donatj 6y ago
  I poked a similar project a while back. If I can just as easily have understandable, easily debug-able JavaScript as output target, I believe that’s preferable. Particularly where extreme performance is not a concern. Tools like GopherJS, Elm, Dart and such output JavaScript no human could reasonably interpret. WASM seems logical for them. TypeScript outputs very human readable JS (for the most part) and WASM seems to have little virtue. As someone who learned JavaScript in the late 90s / early 2000s reading websites code, outputting readable JS feels like giving back.
thefounder 6y ago
>> non statically validated, frustrating experience of trial-and-error that somewhat undermines the joy of a statically typed language. That's because officially Go has not support for web APIs(as wasm has no access to web apis) so you have to callback through JavaScript. However once you build the right wrappers around JS APIs and the tools to deal with HTML the experience is pretty nice.
pansa2 6y ago
> it is pretty magical seeing something written as a CLI tool running in a browser with minimal changes. Years ago, I wanted to write some code that could run both as part of a command-line app and an in-browser tool. I asked what language I should use for this shared code and was told, basically, that there was no suitable language. Now, thanks to WASM, there are lots!
- fulafel 6y ago
  This is indeed nice but in fact you could run C/C++/Rust before too, with asm.js. Not to mention the languages that target JS and can run on Node or the browser.
- pjmlp 6y ago
  How come? I have done that eons ago with Java.
nikki93 6y ago
As another poster said-- C++, C or Rust may give you better luck when compiling to WASM. You could also try TinyGo. Vanilla Go's embedding of its entire runtime and GC is ... a lot.
- stjohnswarts 6y ago
  does it matter much after it's cached locally though? I mean say for single page web apps. I could see that not being a big issue, but if you have to reload the page a lot it might, but loading 1 Mb into memory is nothing to most modern CPUs if it's pulled off the hard drive.
  - nikki93 6y ago
    I started working on a game in Go (with Ebiten-- which is an awesome engine for native!) and hit perf issues in simple scenes that just worked flawlessly with similarly trivial code in C++ with SDL. It wasn't about the size as much as the performance overhead of having a GC and just generally maybe more lax runtime overhead philosophy than Rust / C/C++. I think deterministic memory management and memory layout control is the main perf benefit you get with WASM over JS for the type of stuff I was working on-- both things there's more natural methods for in Rust and C++. I also prefer being able to monomorphize generic code and have it inline etc. (esp. with entt) vs. the vtable stuff you tend to see with Go interfaces (this is totally up to coding style / practices and both are doable in both...). You can also see this with Gio UI library in Go where they try to minimize GC overhead yet one keeps hitting GC pauses in WASM. The author talks about some of the issues with Go on WASM here: https://changelog.com/gotime/128 https://changelog.com/gotime/128 It did help that after diving back into the new stuff in 'modern C++' with auto, lambdas and move semantics I was able to write quite ergonomic code without any actual manual memory management stuff going on.
MaxBarraclough 6y ago
> Most of my early excitement for WASM circled around “Hey, I can finally use a decent language on the web” This has been true for years, various languages can compile down to JavaScript. Kotlin and Dart, for instance. Also, doesn't WASM lack a garbage collector? I imagine porting a language to WASM is still quite a task, and presumably a GC written in WASM is going to be far inferior to one provided by the browser, as with JavaScript. (Corrections welcome if I'm wrong about that.) That's not to dismiss the potential for performance gains in situations well suited to WASM. (I see the_duke already mentioned the GC situation.)

by donatj 6y ago

the_duke 6y ago

Go has to embed it's runtime and GC into builds, so build size and performance will take a hit here. Same goes for most popular languages. For me Rust offers the best WASM experience and tooling at the moment. Rust has no GC and (almost) no runtime. It also has official wasm build target support out of the box, including generating Typescript definitions for Rust types. The ecosystem is somewhat well-developed: * wasm-bindgen for general interop in both directions * js-sys / web-sys for (low-level) type-safe and surprisingly efficient browser API bindings * wasm-bindgen-futures for easy Promise <-> Future interop * wasm-pack for easy building * ... Getting the code size low is still a challenge though. A Rust implementation of the Krausest frontend framework benchmark takes a top 4 spot [1]. Despite this benchmark not favouring wasm at all since it requires little computation and mostly does FFI calls. (ps: C++ is in a decent state as well) [1] https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...

pjmlp 6y ago
It is still much smaller than most SPA used to display static text.
amelius 6y ago
> Go has to embed it's runtime and GC into builds, so build size and performance will take a hit here I expect that WASM doesn't have the concurrency model required by a modern concurrent garbage collector like Go's, but perhaps I'm wrong.
- foota 6y ago
  It's likely much slower, but it should be able to run just fine single threaded as well.
pansa2 6y ago
> C++ is in a decent state as well I’d still choose Go or Rust over C++, though, because they’re memory-safe. This recent discussion shows that’s still important in the context of WebAssembly: https://news.ycombinator.com/item?id=24216764 https://news.ycombinator.com/item?id=24216764
- the_duke 6y ago
  Sure, for new projects I choose Rust over C++ whenever feasible. But a huge amount of the worlds software is written in C++, and will remain so for decades. Getting some of that code to run well in WASM can be a big win for certain domains.
- stjohnswarts 6y ago
  Modern C++ has a lot of memory safe operations if you use them (smart pointers, atomics, actually using RAII properly and universally), although I'm not sure how much overhead they might add to a wasm blob. Rust seems almost perfect for it though, but no reason to discourage C++ people; it can be a relatively modern language if you let it.
  - pjmlp 6y ago
    As someone that loves still having C++ on the toolbox, that is unfortunately only true if you have 100% control over the source code and have all team on modern C++ mindset.

maxgraey 6y ago

Perhaps if you like TypeScript and still want compile to WebAssembly you might be interested in AssemblyScript which stricter subset of TypeScript which compile to wasm

donatj 6y ago
I poked a similar project a while back. If I can just as easily have understandable, easily debug-able JavaScript as output target, I believe that’s preferable. Particularly where extreme performance is not a concern. Tools like GopherJS, Elm, Dart and such output JavaScript no human could reasonably interpret. WASM seems logical for them. TypeScript outputs very human readable JS (for the most part) and WASM seems to have little virtue. As someone who learned JavaScript in the late 90s / early 2000s reading websites code, outputting readable JS feels like giving back.

thefounder 6y ago

>> non statically validated, frustrating experience of trial-and-error that somewhat undermines the joy of a statically typed language. That's because officially Go has not support for web APIs(as wasm has no access to web apis) so you have to callback through JavaScript. However once you build the right wrappers around JS APIs and the tools to deal with HTML the experience is pretty nice.

pansa2 6y ago

> it is pretty magical seeing something written as a CLI tool running in a browser with minimal changes. Years ago, I wanted to write some code that could run both as part of a command-line app and an in-browser tool. I asked what language I should use for this shared code and was told, basically, that there was no suitable language. Now, thanks to WASM, there are lots!

fulafel 6y ago
This is indeed nice but in fact you could run C/C++/Rust before too, with asm.js. Not to mention the languages that target JS and can run on Node or the browser.
pjmlp 6y ago
How come? I have done that eons ago with Java.

nikki93 6y ago

As another poster said-- C++, C or Rust may give you better luck when compiling to WASM. You could also try TinyGo. Vanilla Go's embedding of its entire runtime and GC is ... a lot.

stjohnswarts 6y ago
does it matter much after it's cached locally though? I mean say for single page web apps. I could see that not being a big issue, but if you have to reload the page a lot it might, but loading 1 Mb into memory is nothing to most modern CPUs if it's pulled off the hard drive.
- nikki93 6y ago
  I started working on a game in Go (with Ebiten-- which is an awesome engine for native!) and hit perf issues in simple scenes that just worked flawlessly with similarly trivial code in C++ with SDL. It wasn't about the size as much as the performance overhead of having a GC and just generally maybe more lax runtime overhead philosophy than Rust / C/C++. I think deterministic memory management and memory layout control is the main perf benefit you get with WASM over JS for the type of stuff I was working on-- both things there's more natural methods for in Rust and C++. I also prefer being able to monomorphize generic code and have it inline etc. (esp. with entt) vs. the vtable stuff you tend to see with Go interfaces (this is totally up to coding style / practices and both are doable in both...). You can also see this with Gio UI library in Go where they try to minimize GC overhead yet one keeps hitting GC pauses in WASM. The author talks about some of the issues with Go on WASM here: https://changelog.com/gotime/128 https://changelog.com/gotime/128 It did help that after diving back into the new stuff in 'modern C++' with auto, lambdas and move semantics I was able to write quite ergonomic code without any actual manual memory management stuff going on.

MaxBarraclough 6y ago

> Most of my early excitement for WASM circled around “Hey, I can finally use a decent language on the web” This has been true for years, various languages can compile down to JavaScript. Kotlin and Dart, for instance. Also, doesn't WASM lack a garbage collector? I imagine porting a language to WASM is still quite a task, and presumably a GC written in WASM is going to be far inferior to one provided by the browser, as with JavaScript. (Corrections welcome if I'm wrong about that.) That's not to dismiss the potential for performance gains in situations well suited to WASM. (I see the_duke already mentioned the GC situation.)