It's not that complex, anything in computers can seem complex if you're not familiar with it. I would suggest that you're just not familiar with it, and that's not a knock against you, it's just something that you need to study like anything else. It's not true that you need a large team to do anything on the web these days, the same technology works today that has worked for the last two decades, but if you want to leverage the benefits of new technology you need to invest the time to understand how it works, that's just the nature of technological advancement.

Parent mentioned the lack of tooling, and that is indeed where most of the cost of using WebAssembly lies.

You don’t really need to learn the assembly language itself since you’ll probably just be calling emcc.

However, you may need to build code to marshall more than just ints and strings to the JS code. Even after you do, you’ll run into the classical issues of keeping track of object references across a GC & non-GC system.

You may need debugging and find that in-browser debuggers for WASM are primitive/non-existent. You may need to figure out how unmangle stack traces —- including mixed JS/WASM traces. Third-party tools like Sentry for error reporting may not have built support (they sort of recently have and is very under-documented).

All solvable problems, but it’s a lot of time spent not building the product. There are plenty of good uses cases but it’s usually not the ones based on the false premise that native is somehow always better than interpreted.

Your answer is my thoughts perfectly put in text. Better explanation than what I could come up with myself. Thanks!

Also, with wasm you are now dealing with memory leaks and hunting them down, is no fun at the moment.

It looks complex until you sit down and do it and force yourself to understand what you are doing. Most things are like that.

The way I structure learning things like this in my team is by organizing spikes. We commit to diving into some technology with the goal of finding out how feasible it is for us to use it and a secondary goal of maybe getting something useful going. However the primary goal is finding out if it can work and if so exactly how. If it works out it becomes a regular thing we work on and integrate. This usually starts with studying what is there, what the risks and benefits are, etc.

At some point you reach the point where the only way to learn more is simply doing it. You can analyze something to death without fully understanding it. Just sitting down and doing it becomes the logical next step. The payoff is usually non linear: you gain more if it works than you lose if it doesn't. This is one of those things that you might suspect is valuable like that. So your job is finding that out in an efficient way.

In your team, I would task one or two of your people with spending a max of 2 days to validate that they can take a simple bit of typescript, convert it to assembly script, compile it and hook it up. Chances are pretty good that they'll have working code at the end of those two days. Worst case you lose two days. Best case you figure out it's easy and just works and you move forward.

I agree. Is there something specific that you found difficult that should be simple?