[bedatadriven]

The primary point of the article is to compare two compilation targets for a single codebase: JS and WasmGC.

It's an extremely timely and interesting topic.

The performance of a third compilation target - JVM bytecode provides a useful baseline.

[cxr]

You just wrote out a series of true statements. But you aren't engaging with the comment that I wrote. <https://en.wikipedia.org/wiki/Grice's_maxims>

You're right: the article is comparing compilation targets for Java programs (or rather, one specific Java program in this case study). That's my point: despite that being what the article actually is, it's written like it's comparing Java programs to JS programs—the performance that a Java program can achieve versus the performance of a comparable JS program written to give the same results. But again, it's not comparing those. It's comparing how well they can compile Java, in Java source files, to JVM bytecode (or Wasm) and execute it on the corresponding VM versus how well they can get those Java source files to compile and run on v8 and various other JS runtimes. It's an analysis that simply doesn't show what is suggested by the authors' comments (e.g. "The challenge: JavaScript" and "Why is JavaScript slower than Java?" or anywhere that they refer to the (nonexistent) "JavaScript version").

Very sloppy and irresponsible use of language throughout. The whole article is a mess of confused thinking (at best, that is—the alternative is deliberate malfeasance).

[bedatadriven]

I'd encourage you to take another look at the article because I don't think your criticisms are well founded.

The javascript version does exist! The fact that it's produced by a compiler doesn't undermine it's existence.

What's interesting here is not that it's slower than the equivalent running on the JVM but that it was _faster_ than a version compiled to wasm.

Well written and useful article if you would like to learn about what type of optimizations are effective in targeting the wasmgc runtime.