Michael Hart

@RhysSullivan @swalker326 @felixrieseberg @vite_js @tan_stack It's a comparison with their previous system! I think you're reading too much into it if you're seeing "we tried but just couldn't make this work with SSR/PPR/Next.js"

@hichaelmart @swalker326 @felixrieseberg @vite_js @tan_stack It might have been but the second part implies that it's faster than a properly built SSR (technically PPR) setup when it wouldn't be >Time to first byte is down 65% at p75, prompts show up 50% sooner This is mainly a meaningless line as it's not an actual comparison

A small ship I love: We made Claude.ai and our desktop apps meaningful faster this week. We moved our architecture from SSR to a static @vite_js & @tan_stack router setup that we can serve straight from workers at the edge. Time to first byte is down 65% at p75, prompts show up 50% sooner, navigation is snappier. We're not done (not even close!) but we care and we'll keep chipping away. Aiming to make Claude a little better every day.

@RhysSullivan @swalker326 @felixrieseberg @vite_js @tan_stack "We moved our architecture from SSR to a static setup". "It's faster". Never said they moved *to* make it faster. May very well have been for simplicity?

@RhysSullivan @swalker326 @felixrieseberg @vite_js @tan_stack The tweet never said that either. They just said they moved and it was faster. They didn't say it was because SSR was slow and they had reached their limits with it.

@jlongster @threepointone I would've been stressed at the prospect of working with @thdxr too tbh

late to this but when I was job searching and got stressed about something I talked to @threepointone and he was so supportive and uplifting (as always). very cool guy

@RhysSullivan @swalker326 @felixrieseberg @vite_js @tan_stack "if used properly" is doing a lot of work here though. The surface area of PPR vs an SPA is much larger. Far more things can go wrong. Far more things need to be done just right. Is the extra complexity worth the payoff? Sometimes! Sometimes not.

@swalker326 @felixrieseberg @vite_js @tan_stack i don't disagree but that's not the claim that's being made in the tweet SSR (w/ loading shells) would probably make their site faster if used properly but it doesn't sound like they were using it correctly

Anyone know if mcp-remote works with Claude's new Channels stuff? @glenmaddern wadya reckon? code.claude.com/docs/en/channe…

kimi is here. workers ai is officially in the big model serving game blog.cloudflare.com/workers-ai-lar…

@rot13maxi @thdxr I was wondering this too – typechecking without types in the code, JS + JSDoc if really necessary. Just another linting step, at the last minute. Or maybe: JS while building, TS while maintaining. 🤷

@thdxr @hichaelmart Run the typechecker as a post-write hook

Kinda fascinated how ppl keep trotting out "typed languages are better for codegen" even though we have evidence against it. It *feels* intuitively correct, right? They give better guardrails! But maybe types aren't all that amazing as guardrails for LLMs? dev.to/mame/which-pro…

@MingtaKaivo Yeah we'd definitely need more data to say either way. This study is also super small and particular. Perhaps the big labs have that amount of data by now (but maybe they don't really care).

fair callout — no published report, it was internal tracking. compared error rates across ~200 agent runs, typed vs untyped endpoints. not rigorous enough to publish tbh. your data is more controlled. might be that types help more in larger codebases where the API surface is wider.

@MingtaKaivo Well the data here shows less hallucination with untyped. More reproducible, fewer outliers. But good to hear typing worked better for AudioWave – was there a blog post or report or anything? Where did the 30% number come from?

@hichaelmart types help most with hallucinated APIs, not logic errors. the agent invents a method, TS catches it before runtime. but only if there's a feedback loop. without it, it's vibes. saw 30% fewer hallucinated calls in AudioWave's typed pipeline vs untyped.

@michael_timbs Yeah I'm not so bothered by the extra code too much – more about the reproducibility – ie, the tight bound around how reproducible the untyped langs were, without outliers. Agree that it's a small sample though. Happy to see data that disproves it too.

I don't think the data in this test proves anything tbh. The LoC are so small that it feel obvious that type declaration makes up an unrealistic ratio of the code. If you normalise speed and cost by the number of characters in each implementation a lot of the gap would dissapear. Even if you normalise by LoC the gap narrows a lot. E.g. in the JS vs TS implementation the JS is 80% of the LoC which implies 20% of the TS implementation is types. Given that Tokens/s and $/token are fixed costs then it is impossible for the TS to be cheaper or faster

@michael_timbs They might! That's what feels right doesn't it? 😉 But that's what I wanna see – data that proves it

@hichaelmart but also i suspect if you ran a benchmark on top of this asking for a significant refactor, the statically typed languages might come out much stronger.

@michael_timbs Well this data has JavaScript vs TypeScript specifically

@hichaelmart suspect it is more a feature of the language than static vs dynamic types. E.g lots of time spent on python because benchmarks are usually in python. Even within python the amount of untyped training data is likely significantly higher and more token efficient as well.

@dillon_mulroy "write me a language I can use to add types to JS, but just for the React codebase, don't make any mistakes"

@hichaelmart my take away is OCaml is the best of both worlds

@thdxr That's what I keep wondering – are we just overstating the benefits? Even with a feedback loop – do we have evidence that types + tests + docs is better for LLMs than just tests + docs? Or are ppl just going off vibes

if you don't have a feedback loop to actually provide type errors it doesn't really benefit yeah the agent can run the type checker manually but it just doesn't it might be over stated though - practically speaking it's mostly just fixing things when it hallucinates an api that isn't there

Like, maybe they just get in the way? Have been thinking about this esp in light of what ppl think will be the "ideal" language for agents/LLMs Or am I off base here and we have (other) hard evidence showing types definitely help LLMs?

@NathanFlurry Nice, was gonna ask about that cavet. Also, welcome to the custom runtime game 😁

@hichaelmart Cheers! We're shipping process isolation today or tomorrow which uses our own Rust extension. Required for Bun support too.

Nice for Workers to get a shoutout here, but props should really go to these two npm libs providing all the support here! npmjs.com/package/isolat… npmjs.com/package/node-s…

@zebassembly Yeah it's handy huh – feels like Node.js should maybe even offer this natively?

@hichaelmart til about isolated V8, that's pretty cool

(the Workers runtime uses v8 isolates, as does any v8 engine technically, but it doesn't use these npm libs – they should get all the credit!)