Using asynchronous web APIs from WebAssembly | Hacker News Reader

Using asynchronous web APIs from WebAssembly

web.dev

43 pointsgraderjs30 comments

If anything this article is an example how WebAssembly is miles behind of the alternatives avaible in 2011.

Instead of just using Flash Editor with CrossBridge, here we are 10 years later doing low level plumbing into a standard that hardly moved past MVP 1.0 after 10 years.

My favourite talk at Web Assembly 2020 Summit was about the possible failure for Web Assembly to gain wide adoption due to tooling constraints and minimal language support.

This year, my favourite talk equates Web Assembly to the Concorde, that eventually was removed out of circulation, not due to the accident, but the running costs that did not justify high performance cross atlantic flying.

So when will WebAssembly move beyond low level plumbing and compiler toolchains that require npm like dependencies to generate a plain .wasm file?

WebAssembly has different ambitions than Flash. It is meant to be become similar to an operating system, whereas Flash was a very specialized tool.

TinyGo and Zig can generate .wasm files out of the box.

The ambition to delay progress for 10+ years.

Good to know that at least two do so, even though Zig isn't even 1.0 and TinyGo is well tiny Go subset.

Wasm did nothing to delay progress. It's a bunch of people doing what they think is cool and useful, and they're pretty upfront about it. If you don't like it, why are you waiting for them; they're not slowing you down. What did you do?

It surely did, given that we had Unreal running on Flash in 2011, with a 3D API that WebGL 2.0 still fights to achieve the same level of guaranteed hardware acceleration.

All in 2011, 10 years ago!

What did I do? Contribute to native apps taking over.

Unfortunately a lost battle now that ChromeOS has won the Web.

What does that have to do with Wasm people? They're working on Wasm and you're working on native apps. If you desired a better Flash, then you should've made it, the Wasm contributors are not responsible for your desires. Unfortunately for you nobody picked it up, but that is not fault!

The same group of people actively botched Flash and PNaCL support on browsers.

Please send links to discussions/commits. I remember it as these technologies being inherently botched and pretty much unbotchable, and the group moving on to Wasm - which isn't a fault they could be blamed for, they're not yours to command. I'm very sure that if you knew how to unbotch it you could've simply submitted into the discussion and would've been accepted.

Personally I'm more excited for WebAssembly on the server side. The possibilities for low-overhead multi-tenant workload sandboxing are fun to think about (CloudFlare is doing more than just think about them!).

It doesn't offer anything better than hundred other bytecode formats, some of them in use for decades, since IBM and Unisys mainframes have gotten into production.

What are your options if you want to support C, Go, Rust, Python (actual Python, not "Jython" or others with low ecosystem compatibility), and JavaScript? Of those bytecode formats that support those languages, which have something like Krustlet, which would allow us to leverage Kubernetes and its ecosystem?

Given your list of languages, neither does WebAssembly.

Which ones specifically? From his list it looks like Python and JavaScript would be troublesome, but it's theoretically possible. What I've read suggests that sandboxing Python is a real PITA, but there is some promise by linking it with Rust first and then compiling that to WASM (I think Pyodide can maybe do this? There was a wasmer fork of it but it's unmaintained atm.)

Except JVM and CLI already support them today, but apparently not good enough for the OP, and given that the support in WebAssembly is even worse than those options then WebAssembly doesn't fulfill his list.

Add to that that Go is only partially supported on WebAssembly.

OP here. It's hard to make the case internally to switch to an orchestration platform that works for "most of our apps".

Of course, it's similarly hard to make the case for WASM, which is similarly incomplete today; however, there appears to be mutual interest from language communities and the WASM team to get support working. Even still, I don't intend to make the case until WASM has a decent track record of supporting those languages. But I have more optimism that WASM will get there than JVM or CLI.

Note also that while "JVM and CLI have support for those languages", their support for Python (and probably JavaScript) is only nominal. You can't reasonably use Jython or IronPython with the rest of the Python ecosystem, but WASM at least has a plausible path forward. I also strongly suspect that support for sandbox execution of the other languages is similarly nominal--if it's technically possible, I'd be surprised if anyone is doing this in practice.

I advise you to watch these talks,

"Why the #wasmsummit Website isn't written in Wasm"

https://www.youtube.com/watch?v=J5Rs9oG3FdI

"Production Ready Server-Side WebAssembly: The Challenging Parts"

https://youtu.be/-4zNzxqUBsk?t=3155

Which bytecode platform do you expect will have mature support for these languages first?

JVM (specially on GraalVM) and CLI support most of them.

It remains to be seen when WebAssembly will have native support for GC languages.

Then in case we are talking about languages like C and C++, IBM i and z/OS have had support for them on their language environments since they exist.

Graal is interesting. Is anyone using it in production for multi-tenant code execution? What is the sandboxing like? Can you combine it with something like Firecracker?

Someone posted a demo to HN the other day of compiling Lucene into a Graal image (that the right terminology?) and making grep on steroids. The sub 100ms startup time was impressive.

This little company called Twitter.

"Performance tuning Twitter services with GraalVM and Machine Learning"

https://jeeconf.com/program/performance-tuning-twitter-servi...

I'm hoping WebAssembly and its APIs will rid of us the regular platform version updates and deprecations that we now face, having to move from Node.js 6 to 8 to 10 to 12 to 14 etc. If there is a stable, evergreen platform similar to web browsers, then server-side apps could keep running forever.

WebAssembly MVP 1.0 vs 2.0, with and without WASI,...

Yes, being able to compile my VueJS component from inside my Python VM would be a huge plus: I would finally have one single template language on the frontend and the backend, and just one endpoint for rendered pages and API.

I find it really crazy how far this had to go to support something as simple as sleep. I became aware of this problem when I started writing WASI last year. So so much unix code is based on the idea of synchronous operations. My conclusions were that some sort of ability to have atomics that could pause a web assembly running on a web worker while an async operation completed then unlocked the blocked web assembly was the only way this could be sanely done.

To be fair, UI applications on most platforms that are not Windows or Linux have a very similar problem, you can't simply block the event loop for a few seconds or the whole UI will freeze and the OS will most likely terminate the application (on mobile at last). Usually one can workaround this with threads, alas, threading in the browser environment opens up a whole new can of worms.

Asynchronous programming is a different coding mindset, and async-await provides a convenient hack/workaround/solution to go back to a simple linear execution flow (even if that's just an "illusion"). But this problem had been solved many decades ago on the OS level in UNIX and other multitasking operating systems already (and solved it much better, because async-await is essentially cooperative multitasking, like in Windows 3.x or classic MacOS).

> something as simple as sleep

Is sleep really considered simple?

C io APIs are sync, but there are so many that are not such thing. Potentially would even be possible to expose something like the io_uring async api to the browsers I guess.

While io_uring certainly is great, but it is

a: Linux only. The main interest of browsers are Windows and Mac as most users are on those platforms.

b: Limited to modern variants of the kernel - this is a greater problem the more features that is needed. Not everyone wants to be or can be a kernel hipster.

That article probably should have mentioned the existing code built into wasm-bindgen that allows cross-language async/await between Rust and JS.

(Author here - sorry, just noticed this post got to HN a few days ago.)

True, I've considered describing that feature too, but in the end decided it would be too much deviation for the article that is already fairly large. That integration is very interesting on its own, but solves slightly different set of problems - that is, it can' t be used for bridging regular synchronous APIs like WASI in back-compat manner, but rather requires your entire stack to be built on top of async APIs.

If it is, that's indeed an even better solution, but most likely at least majority of your dependencies just use regular std:: APIs that are sync-only.

Describing those tradeoffs and doing meaningful comparison of two approaches feels like a whole separate blog post :)

Reply on news.ycombinator.com