I did 5 game jams in Web assembly last year and found it quite painful overall.

Emscripten is very bloated, but it's the best option from what I can tell.

I lost a whole day of a 3 day game jam to a weird Emscripten bug. It ended up being that adding a member to a class blew up the whole thing.

The alternative (and the only option, if you want it to be as light as possible) is to do the bindings yourself, which is fun, depending on how much your concept of fun involves JavaScript, and having half your code in a different programming language.

I'm told the Rust situation is pretty nice, although my attempt didn't get anywhere — apparently I tried to use it in exactly the opposite way that it was intended.

I had a pretty nice time with Odin. Someone put raylib wasm bindings for Odin on GitHub, and it worked really well for me.

(Odin syntax is really nice, but you don't realize just how nice, until you port your game to another language!)

Zig was cool, but a bit pedantic for a jam, and a bit unstable (kept finding out of date docs). Didn't see much in the way of game libs, but I was able to ship a Zig game with WASM-4.

I ended up switching to TS, which I'm not happy with, but since you (usually) need JS anyway, the benefit of having a single language, and a reliable toolchain, is very high, especially under time pressure. The "my language is nice" benefits do not in my experience outweigh the rest of the pain.

Just for another data point, I took me 4 days to cook up a WASM front-end using Go for my otherwise command-line only Hive game:

https://janpfeifer.github.io/hiveGo/www/hive/

Probably everything JS and DOM is better supported from TS, but I have to say, I was never blocked on my small project.

Seems quite the opposite

https://www.youtube.com/@wasmio

According to those, likely to replace containers and likely to be integreated in more and more systesms.

It seems like it's exploding in populartity and usage because it solves some very real problems.

Hello application servers from 2000's.

Which were mostly tied down to specific languages and GC'd runtimes. You seem to have a big problem with Wasm just because bytecoode runtimes have been done before.

2001 says hi,

"More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. "

https://news.microsoft.com/source/2001/10/22/massive-industr...

Ah, it isn't portable, maybe 1989?

"The Architecture Neutral Distribution Format (ANDF) in computing is a technology allowing common "shrink wrapped" binary application programs to be distributed for use on conformant Unix systems, translated to run on different underlying hardware platforms. ANDF was defined by the Open Software Foundation and was expected to be a "truly revolutionary technology that will significantly advance the cause of portability and open systems",[1] but it was never widely adopted."

https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut... or better 1980?

"The Amsterdam Compiler Kit (ACK) is a retargetable compiler suite and toolchain written by Andrew Tanenbaum and Ceriel Jacobs, since 2005 maintained by David Given.[1] It has frontends for the following programming languages: C, Pascal, Modula-2, Occam, and BASIC."

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

I have a problem with people selling WASM as something spectacullary new, never done before.

> I have a problem with people selling WASM as something spectacullary new, never done before.

Nobody is doing this here, you're arguing against a strawman.

Furthermore, “I recognize this technology as a rehash of something that already exists” is just extremely uninteresting conversation without getting into the specifics. Clearly there are differences. Let’s talk about the merits and demerits of the thing.

Yeah, nearly everything is in some way a rehash of something that existed before at this point.

The biggest advantage is non-technical: it has universal adoption in the browsers from early on, esp. on Apple devices. That was NOT an easy task to achieve. I do believe the previous attempt with asm.js was able to help there to ease the idea for the browser makers.

And technically it's quite well done. The only thing that is missing is thread support, but due to complexities I totally get why it wasn't done and it was a right call. There are workarounds and it will be added eventually, some forms of it exist already.

Yeah, the thing that's new and hasn't been done before is the level of adoption.

What do you mean, DOA? It's been in active use for years now.

As far as I know, "2.0" is just a marketing term batching several extensions standardized since 1.0 (and simplifying feature queries "are extensions X,Y,Z supported" to "is 2.0 supported"), not unlike what Vulkan does with their extensions.

It’s not DOA, it just became everything except anything to do with “web.” The purpose it was invented for has been forgotten.

I don't know what you're trying to say.

If you're talking about WASI, well personally I'm not interested in it and we're just using plain wasm in the browser. However, nothing in this linked post is about WASI specifically.

The purpose it was invented for was not the web. WASM was designed from the beginning to be a platform-independent technology[0].

The HN crowd has just always been terminally myopic about this because it has "web" in the name.

[0]https://learn-wasm.dev/tutorial/introduction/what-webassembl...

It was definitely invented to make everyone happy after the NaCL/PNaCL vs asm.js political wars.

We already have lots of bytecode formats.

Think of it like German names, where people are often named for where they came from. Berliner, Münchner, etc. WebAssembly is so named because it came from the web :)

> A common misconception is that WebAssembly can only run in web browsers. Although "Web" is part of its name, WebAssembly is not limited to browsers. It's designed to be a platform-independent technology that can run in various environments, including IoT devices, edge computing, artificial intelligence, game development, backend services, or cloud services. Its portable binary format allows it to execute efficiently across different platforms and architectures.

I am not going to lie, I thought the same because of the name, too.

yeah the W assembly has nothing to do with web.

There's documentation from the people who created it stating as such, and it's weird how intransigent so many people here are about that fact.

Yes, the "w" does stand for "web" and yes it was designed with the web in mind but no it was not designed exclusively or even primarily for the web and no it isn't DOA because DOM access from a browser isn't here yet, as demonstrated by all of the existing applications already using it.

> The purpose it was invented for was not the web

> Its main goal is to enable high performance applications on the Web

So it's not just the name

On the contrary, the browser is the only place where it makes sense.

Outside of the browser are only VC backed companies, pretending bytecode based distribution isn't something existing since 1958, with wins and losses, many of those were polyglot, supporting languages like C in bytecode was already done in 1989 with Architecture Neutral Distribution Format, and many other examples.

There are some highly competitive web applications that use Wasm and plenty of useful libraries. The web is definitely the primary use case.

Personally I don't find it that painful to write the little js code to send browser input to wasm. I'm having a lot of fun with it. Just the simd stuff to speed up whatever you're working with is often worth writing a c version of things.

Might be futile for the broader scope, but the main scope of enabling native code in the browser would remain strong.

Maybe a WASI DOM could help ?