spankalee

They released Argon shortly after announcing it, so I think some benefit of the doubt is reasonable here.

That's actually a little confusing to me: The 8F and 6F diagrams don't show why 6F takes less area per cell.

What would a "fully-constrained tool call environment" be?

Read where "required" was in the comment you're flipping out about: it didn't say that the software had to be vibe coded, just that it was.

The RCE was caused specifically by a custom Claude generated overlay, so finding the RCE did require using this vibe coded software.

What is this doing on the front page?

The DOM in modern browsers is backed by texture compositing just like people hand-roll with canvas and webgpu, so it can be extremely fast.

If you can get by with canvas rendering, you could instead use HTML and eliminate tons of CSS and layout cost by using CSS containment and absolute positioning:

    #my-container > * {
      contain: strict;
      position: absolute;
    }

AT Proto has a chance to really help here, so that governments and other orgs and publish structured content like posts and events, and have them indexed and distributed through all kinds of AT Proto services and apps, including, but not limited to Bluesky.

I hope to see turnkey organization oriented PDSes that let an admin management multiple accounts, and also host web pages with the same content that's distributed on network. Then gov posts has a web home and can be subscribed to in AT Proto apps.

Oh god, that repo links to Grokipedia.

A lot of that is Waymos not taking highways, but that's changing.

This exactly. The car didn't drive into people: it followed a vendor truck into a place it shouldn't have gone, apparently slowly exited the area.

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.

What does that have to do with the topic at hand? Not to mention that Wasm that can only run on Wasmer defeats the whole point of Wasm.

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

Wasmer is one of many WebAssembly runtimes, not sure why it needs specific hyping here.

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

This really should be a WebAssembly runtime so that the same computations can run on different platforms and devices.

Yet Bun has Node compatibility.

> just type the chords correctly

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?

I recently got a Linux desktop after being Mac-only for a long time and using Linux only as a deploy target, and holy shit: the modifier key situation on PCs is so bad.

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?

I think the difference here is that the original motivation for choosing Go over Rust was that Go was easier to port TypeScript to.

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.

This was a lot of tokens to spend on a port. I wonder if all of the porting activity out there would be better supported by investing in really good deterministic automatic translators that do 90% of the job cheaply and delegate any decisions that have to be made back out to the AI agent?

Wasm is a first-class target for Rust, which produces faster and smaller Wasm binaries. My understanding is that you need to use TinyGo to reasonably target Wasm with Go.

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.

Rust is better at targeting WebAssembly

I would rather say: "benchmark with confidence intervals" or maybe "benchmark with comparisons".

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

It would be more clear if there were any concrete critique of the web components APIs.

Reactivity would be an addition to web components, and you can layer that on in userland. Plus, there are proposals for exactly that.

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

Stencil's is _not_ a workable platform solution. Stencil is emulating something close to slots _above_ the DOM. Stencil knows the host tree form Stencil's own component definitions, then it flattens before it gets to the DOM. This is basically just what React and every other framework does, just copying the browsers terminology. It's not compatible with anything but Stencil.

In the real DOM you need to know which element from project _from_. The <slot> itself is only half the connection. In a light-DOM only document full of <slot>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.

So any specifics on web components? What part is actually bad and how could it be better in a way that actually works?

How would you solve that? To this day I've never seen a workable proposal.

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.

What about the web components APIs are bad, and how could they be done differently given the reality of the existing platform?

> Yes, we're building a sad world. I'm glad you noticed

What is the point of sarcastic, passive aggressive comments like this?

The syntax is TypeScript inspired because I like it and my bet is that the familiarity helps human and AI coders learn the language.

I don't think those assertions about AI development necessarily hold. And I think it'd be a depressing future if we can't ever have anything new or better that wasn't popular in the training set as of November 2025.

I wrote about some of my thoughts with Zena and AI here: https://zena-lang.dev/blog/2026/09/languages-for-the-ai-era/