Chrome is now released with Wasm GC enabled by default

[Bruno Salmon]

Hi,

I read this from https://github.com/google/j2cl/discussions/216

Is it a good news for TeaVM too?

[Alexey Andreev]

Hello.

Not really. WebAssembly GC is so a game changer, that the existing generators can't be just augmented with new feature. Instead, everything must be rewritten literally from scratch, except few low-level things. And Wasm GC still not supported in Safari (for businesses it's important to cover ALL users) and browserless engines. And it's unclear what to do with debugging.

Anyway, WebAssembly support exists for years in TeaVM, and I did not see any adoption. I understand, there's no docs, but I was hoping that if someone really wants to evaluate WebAssembly, reach me directly and ask questions. Even in my company we still sit in JS, since there's simply no reason to switch to WebAssembly.

Hi,

I read this from https://github.com/google/j2cl/discussions/216

Is it a good news for TeaVM too?

--
You received this message because you are subscribed to the Google Groups "TeaVM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to teavm+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/teavm/18b985bb-a0f6-4533-88fc-37ef5546a054n%40googlegroups.com.

[Bruno Salmon]

>> I was hoping that if someone really wants to evaluate WebAssembly, reach me directly and ask questions.

I was that person and I did evaluate the WebAssembly TeaVM backend a few years ago (see my demos https://mandelbrot.webfx.dev and https://raytracer.webfx.dev) and I reached you and asked questions, but you looked reluctant to provide support regarding WebAssembly and you basically suggested me to give up, so I didn't go further.

There is no complain here, I just wanted to know if your position regarding WebAssembly has changed.

I understand from your reply that your position hasn't changed, and that there is no plan to develop the WebAssembly TeaVM backend any further, and that this new WasmGC won't change anything.

I agree from my own experiments that WebAssembly doesn't provide the performance boost they claim in most scenarios, because the gain you eventually get is then completely lost with the JS interaction boilerplate (which you can't avoid as WebAssembly has no direct access to the DOM). The only thing you "gain" in the end is that your app becomes more complicated.

But I'm still keeping an eye of the possible progress in that area.

Thank you.

[Alexey Andreev]

>> I was hoping that if someone really wants to evaluate WebAssembly, reach me directly and ask questions.

I was that person and I did evaluate the WebAssembly TeaVM backend a few years ago (see my demos https://mandelbrot.webfx.dev and https://raytracer.webfx.dev) and I reached you and asked questions, but you looked reluctant to provide support regarding WebAssembly and you basically suggested me to give up, so I didn't go further.

There is no complain here, I just wanted to know if your position regarding WebAssembly has changed.

I understand from your reply that your position hasn't changed, and that there is no plan to develop the WebAssembly TeaVM backend any further, and that this new WasmGC won't change anything.

No, my position never was "not to develop". I develop and improve Wasm BE, you can see that from commit history and I even mentioned Wasm in latest release notes and in milestone issues on GitHub. However, it's always been low-priority task.

As for WasmGC, I'm really interested in creating a prototype, but as I already explained, it's not just a small improvement for Wasm BE, neither it's a BIG improvement. It's rather just reimplementing everything from scratch (possible, as a separate WasmGC backend). So I need to find a time span when I can give up all other tasks and spend few weeks just working on it. For now I don't see such opportunities, but I'm looking forward to find one. As for near future, I was planning just to make minor improvements into current Wasm BE.

I agree from my own experiments that WebAssembly doesn't provide the performance boost they claim in most scenarios, because the gain you eventually get is then completely lost with the JS interaction boilerplate (which you can't avoid as WebAssembly has no direct access to the DOM). The only thing you "gain" in the end is that your app becomes more complicated.

The main reason for WebAssembly poor performance is not the need to interact with JS, it's just whole design of WebAssembly. It was primarily designed to run C++ or Rust. So what we have is something close to real CPU, but without useful CPU features that managed runtime engineers use to get really good performance (like runtime code generation, direct stack access, memory protection, etc). In WebAssembly GC they addressed this issue not by introducing lacking features, but by turning WebAssembly in something similar to JVM, with notion of objects, references between them, etc. Yet they did it with major flaws, like trapping instructions, so languages like Java or C# still suffer from generation of excessive code to address these flaws.

[Bruno Salmon]

Thanks for your explanation about WebAssembly poor performance.

I still think the interaction with JS also degrades performance in many scenarios. For example, my demos lose lots of time in data transfer from the WebAssemby to JS (serialisation of the pixel colours into integer arrays + asynchronous communication between web workers and main JS).

But mostly, thanks for clarifying your position regarding the WebAssembly TeaVM backend.

I'm glad to see you still have some plans (even if low-prioritised) to develop the Wasm BE, and eventually a future WasmGC BE.

Good luck for finding the time. I will keep an eye on it.

[Alexey Andreev]

BTW, I just checked you examples and they look impressive! What TeaVM version are you using? Did you try to update to the latest one?

Also, this whole webfx looks great. Did you ever consider switching to TeaVM?

--

You received this message because you are subscribed to the Google Groups "TeaVM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to teavm+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/teavm/120ae1d7-1640-4d8f-8fc1-ab8cae009d50n%40googlegroups.com.

[Bruno Salmon]

Thanks. I'm using TeaVM 0.9.0 (as seen in parent pom.xml)

I actually noticed some improvements with WebAssembly when I moved from TeaVM 0.8.1 to 0.9.0. In particular the RayTracer demo used to crash in WebAssembly mode (you can enable WebAssembly in the settings i.e via the gear icon) after a couple of minutes of computation with TeaVM 0.8.1. It's not crashing anymore with TeaVM 0.9.0. Thanks for that.

For now I'm using TeaVM mainly to perform some heavy computation in WebAssembly in the background (web workers), the main UI being compiled by GWT.

But I plan to move from GWT to J2CL, and also support TeaVM as an alternative compiler for the UI, so people will have the choice.

So no my plan is not to "switch" to TeaVM, but to support both J2CL and TeaVM in the future.

But like you with WASM, it's not the most prioritised task for now, so difficult to tell at this stage when this will happen.

Once done, you should be able to write web apps using the JavaFX framework and compile them with TeaVM.

A quite ambitious project, but according to my experiments conducted so far, this seems possible.