> If you’re building a product that billions of people will be stuck with, however, this can lead to a little stress. The history of the web is littered with bad APIs, ill-considered specs, and tangled piles of security vulnerabilities. Something a programmer puts together in a week can consume decades of engineering time in the future. WebAssembly could not and would not release as a half-baked or ill-considered spec because as browser developers we all understood the costs everyone would pay for that.
I might be missing something here, but this feels a little like unnecessary pressure. As I understand it, billions of people wouldn't be using the API; a few compiler authors would. I thought that's one of the nice things about WASM: recompile to upgrade. Security is a good concern to have, of course!
I used to work at G. They put this pressure on you artificially, I think because they believe it gets you to buy in to your work due to its importance. Practically, it seems to encourage lethargy because you need to make sure that all billion of them are happy. Great engineering is done when you know what you can sacrifice some goals for other goals.
People today aren't a lot smarter than people were 20 years ago, and we kind of forget that fact when we try to do grandiose projects like "replace the entire stack and make sure that it works equally well to the old stack in all circumstances." The old stack was built well for its goals, and had the benefit of 20 years of tuning. The replacement needs to come when the goals change. There is plenty of opportunity still: peoples' goals change frequently.
If the goal was just to allow you to write webapps using toolchains for native apps, then you can put in an LLVM-like sidecar next to JS that has terrible performance but amazing security (I think this was closest to the goal of WASM). However, if the goal was to bring native performance to webapps means you can target your spec toward efficient JIT compilation on x86 and ARM (and RISC-V), without worrying a lot about portability to other architectures. I have heard a mix of the two looking at the WASM project from the outside: that they wanted native performance with 100% portability of both hardware platforms and development languages, and they thought they could achieve it.
A great TPM (technical program/product manager - the Google term for an engineering-focused product manager) can help define these exclusions, and it sounds like OP really tried hard to get one. I'm surprised that Google didn't give them one to start.
I had the same conclusion: This team needs to get a dedicated TPM to act as a stress umbrella for the team. I tell my engineering team, if anyone is stressing you out, "pinging you" for things, asking you to set up pointless meetings, "escalating" things with managers, or anything else that sucks away your productivity, please redirect them to me and I'll handle these annoyances. If software developers are distracted by stressful bullshit, then I'm not doing my job.
Chrome already had Google Native Client (NaCl), basically the LLVM sidebar you describe, so asm.js and wasm (and even Google's own Dart VM) had an uphill battle to being adopted by Chrome.
> As I understand it, billions of people wouldn't be using the API; a few compiler authors would.
Yes, but billions of people may suffer the consequences of the WASM design doing something stupid and then the few compiler authors having to semi-successfully deal with it. That may be stressing, assuming that you care about such things as your brain child being an improvement (not a regression) on what came before.
Very few developers, yes, but shipped to very many end users. As it turns out WASM was used as a springboard for a pretty nasty exploit chain to get persistent root on Chromebooks (responsibly disclosed and fixed, thankfully.)
I might be missing something here, but this feels a little like unnecessary pressure. As I understand it, billions of people wouldn't be using the API; a few compiler authors would. I thought that's one of the nice things about WASM: recompile to upgrade. Security is a good concern to have, of course!