this is backed by data btw.

In case it wasn’t clear:

Magic usually translates to implicit abstractions. Invisible. That’s bad software design in almost all scenarios. It’s hard to test. It’s walled off (usually). It’s hard to learn. You can design good APIs and avoid this problem. Explicit APIs != bad abstractions

framework developers repeat after me: magic is bad

@OpenAIDevs ChatGPT Apps ➡️ MCP-UI ➡️ React Server Components 🚀 powered by @CloudflareDev 🧡 and @RedwoodJS 🪵 this is all i need, its beautiful pass props in MCP or query in ur server comps will clean and share soon hi @rachelnabors @jherr @Infoxicador @idosal1 @liadyosef

We built an entire React framework from scratch because I realized that you _need a platform_ to be productive. We tested a whole bunch of them, but @CloudflareDev stuck out: - Bindings: Allow you to make services feel like they're on the same machine as your code - Web standards: Almost everything is just fetch instead of APIs When it comes to the "squashing" make sure you're picking something that isn't too far abstracted from the base-level implementation; because all the tools and libraries you rely on will make an assumption that the base-level is what you're dealing with.

"use cloudflare"

Incredible experience building with @RedwoodJS on @Cloudflare Any deployment velocity less than this is unforgivable.

TIL durable objects have built in caching of their storage apis. I've always done this... this.ctx.blockConcurrencyWhile(async () => { let stored = await this.ctx. storage.get("value"); // After initialization, future reads do not need to access storage. this.value = stored || 0; }); but turns out you can just spam storage.get(....) and it's also chill.

Async work in @reactjs has come a long way. If you're still using fetches inside of useEffects you are behind the times. React 19.2 has a full async ecosystem now. Let's learn it in just 10 minutes! youtu.be/KI4gjUrOfOs

Noone wants to hear it but RSC solves this

You're touching grass? Either us-east is down or you're using RedwoodSDK on Cloudflare

I'll be chatting in Joshua 2 (East side) at Cloudflare's conference at 3pm. In about 35 minutes.

It’s tempting to look at a simple demo or screenshot of imperative code and think “I understand this, so I can always understand it”. But there is a steep cliff, fairly quickly, where you can’t understand it because the sequencing is too spread out or complex.

Team had a lot of fun making workers faster. Big thank you to @theo for pushing us to be better!

When @tan_stack and @RedwoodJS walk into a bar...

New blog post is live! As promised, all about the two-brained architecture behind better-chat! Featuring my updated personal site, now on the @RedwoodJS v1.0.0-beta, using updated markdown/code-block rendering from what I learned working on the chat app, and a new table-of-contents sidebar. Pretty clean if I say so myself.

Unbundled dev server are nimble, fast, and naturally incremental. That's how we made Vite's HMR so fast. But it has its limitations: one of the major pain points when using Vite in large-scale applications is the slow dev server page load speed. The upcoming Full Bundle Mode for `vite dev` (powered by Rolldown) completely resolves this problem. In developing this, we actually had to invent a whole new HMR implementation (inspired by Vite's original unbundled HMR) to ensure HMR stays decoupled from application size even in full bundle mode. The result is the best possible DX: in an app loading 10k React components, full bundle mode offers 15x faster startup & 10x faster full page reload compared to unbundled mode, now faster than rspack/rsbuild in both metrics, while retaining instant (and even faster) HMR.

. @Cloudflare is your Security Cloud Performance Cloud Network Cloud Developer Cloud Media Cloud Realtime Cloud Data Cloud AI Cloud Agent Cloud