upvote
Another example of a top comment that was definitely written by an LLM.

And to be clear, style isn't the only problem. This comment can be summarized as "WebAssembly can now interact with the DOM directly instead of through JavaScript, making it the better choice for more types of problems". One sentence instead of a paragraph of cliches ("...change how people think about this...chicken-and-egg loop..."), uncanny phrases ("...the hot-path optimization niche"), and inaccurate claims ("...the only viable use cases were compute-heavy workloads like codecs and crypto").

(For anyone who doesn't believe me, check the user's comment history)

reply
What do you think is the incentive to LLM post on HN (or any site?)
reply
The usual answer to this question is building out realistically looking accounts for later spam and/or astroturfing.
reply
The incentive of the human who deployed it—at one remove or another—would require knowing more. But the more likely cases are easy to guess at, e.g., someone is playing with OpenClaw. I'd guess "someone is playing with OpenClaw and intends to write something about it boost their brand, could be a Show HN could be a LinkedIn screed they hope goes viral."

Could be for fun. I remember fun.

reply
Woah, you're right. The account was created a day ago and writes walls of text everywhere (sometimes multiple on the same thread!)
reply
> no DOM access meant the only viable use cases were compute-heavy workloads like codecs and crypto,

no, it didn't mean that, because the overhead is not a deal breaker:

1) you don't have to do the glue code (libs can do it for you)

2) there's overhead due to glue, but the overhead is so small that WASM web frameworks easily can compete with fast JS frameworks in DOM heavy scenarios.

Source: Analysis of the creator of Leptos (a web framework based on WASM): https://www.youtube.com/watch?v=4KtotxNAwME

reply
> but the end state where you import a browser API like any other library in your language is genuinely simpler than the current JS FFI dance.

Tbf, Emscripten has solved this problem long ago - I don't quite understand what's the problem for other language ecosystems.

The JS shim is still there, but you don't need to deal with it, you just include a C header and "link with a library".

Some of the Emscripten-specific C APIs are also much saner than their web counterparts, which is an important aspect that would be lost with an automatic binding approach. And EM_JS (e.g. directly embedding JS code into C/C++ files) is just pure bliss, because it allows to easily write 'non-standard' binding layers that go beyond a simple 1:1 mapping.

Those features won't go away of course, I just feel like the work could be spent on solutions that provide more 'bang for the buck' (yeah, I've never been a fan of the component model to begin with).

reply
> the only viable use cases were compute-heavy workloads like codecs and crypto,

I tried using it for crypto, but WASM does not have instructions for crypto. So it basically falls back to be non-hw-accelerated. Tried to find out why and the explanation seems to be that it's not needed because JS has a `crypto` API which uses hw intrinsics.

reply
> meant the only viable use cases were compute-heavy workloads like codecs and crypto

And games, which the web is now a viable platform for a huge range of them, albeit not the top of the range, AAA and all that (yet?). Also some new graphical editors taking advantage of it, probably Figma being the most famous example so far.

reply
Generated comments are not welcome here. Please respect the guidelines of the community.

https://news.ycombinator.com/newsguidelines.html#generated

>Don't post generated comments or AI-edited comments. HN is for conversation between humans.

reply
It will take a LOT more to make WebAssembly win now.

People have the impression that WebAssembly has failed. After so many years, I sort of agree with that notion. WebAssembly is soon 10 years old by the way:

https://en.wikipedia.org/wiki/WebAssembly

reply