It's bad, and obviously shouldn't have happened, but the car is cautious around people and didn't hit anyone. It's a far better failure mode than the typical case of a human who drives into a crowd.

You're not helping the negative reputation of Wasmer that's out there with this unprompted promotion.

I tend to use Wasmtime, V8, WAMR, and browsers. The point of WebAssembly is that there are many runtimes.

Gee thanks.

I like to have my right hand on a mouse or trackpad, so two handed chords are much less convenient.

Macs manage to make one-handed chords for copy and paste ergonomic, but on a PC it's user error?

Control specifically is just a terrible modifier key for common things like edit commands. First, it sits near your pinky instead of your thumb, making chording it with Z, X, C, V, etc., really difficult.

But then... who decided that ctrl-c should be used for both copy and abort??? That's diabolical levels of messed up. In a terminal app ctrl-c aborts, so you need to use shift-ctrl-c to copy, and now you have two shortcuts for the same operation you need to remember based on context, except that in a web-based terminal in Chrome shift-ctrl-c opens "Inspect Element Mode" and now you have no way to copy!

Am I the only one who finds this astoundingly frustrating?

LLMs change the calculus a lot, the result seems faster, and it's possible that the TypeScript team might want to change directions. It'd be a big deal, but I bet they'll at least discuss it.

Go having a garbage collector isn't necessarily bad, since Wasm has GC, but I think Go's GC can't easily use Wasm GC because Go has interior pointers.

It's very hard to say much about an absolute number. You need to compare against some alternative or control, and because of CPU load, throttling, GC, and a thousand other variables, you really should be comparing against that control _in the same run_, and importantly round robin across multiple runs to spread out the noise fairly across each implementation.

Then once you have a bunch of measurements you have a distribution and shouldn't just take a mean to compare, but should calculate something like the 95% confidence interval. If you see that those confidence intervals overlap, the you might not really know which is faster. If they don't overlap, then you probably do know which is faster.

If you have a good benchmark, then running it more times can narrow the confidence intervals and let you tease out very small improvements at the cost of longer runs. If confidence intervals don't narrow, then you hit the limits of signal-to-noise.

This is the only way I've been able to get reliable, actionable benchmarks outside of a very, very controlled hardware lab. It's what Google's Tachometer benchmark runner does, and I wish more runners did this: https://github.com/google/tachometer

But if the web components APIs suck, what sucks about them now?

In the real DOM you need to know which element from project _from_. The itself is only half the connection. In a light-DOM only document full of s you won't know which elements to project where.

> The problem with the browsers API is a lack of an understanding on how to design good ergonomic APIs for the end user.

This could be slightly true, but the statement also misunderstands the role and priorities of standards. When adding new capabilities to first priority is to make something possible at all, and coherent with the rest of the platform. Making a sugary high-level API is often left to libraries at first, and is exactly what libraries like Lit are.

Slots need to have a host element to select slotted nodes from. ShadowRoot provides that host. Everyone who I've seen say that it's easy comes up with an ambiguous system that doesn't work in many cases and could never be standardized.

Which is a common problem with most "web components suck" takes - they have no sympathy for standards developers or the difficulty of the problem and somehow assume the spec people are dumb or evil, and they don't do the work to show how something could realistically be better.