Dev Wells

YouTube video by ThePrimeTime DHH Is Right About Everything

It's the "don't like it? that's fine--fork it!" approach.

Not saying I agree necessarily, but that helped me understand where the "gift-giving" analogy stems from.

related: youtu.be/mTa2d3OLXhg?...

Not sure if he talks on this in the interview, but I think DHH's take on open-source is easier to grok with the context that he views OSS as meritocratic, not democratic.

There are democratic elements, but he believes it's those doing most of the work that should set the direction.

Was scratching my single brain cell over here trying to figure out how to turn streaming on on my new blog... which is a static site.

I think I may have spent too much time "optimizing" SPA architecture lately y'all 🫠

I suspect it could do a lot more than the wordpress sites it angles for, too.

Yes! Have had a blast with Astro lately. Strikes the right balance of "let me just refresh + enhance some HTML" and "oh but i'd also like some tooling please".

Just threw together wlls.dev (migrated from alexwells.dev). Both Astro!

Conferences, Clarity, and Smokescreens - Infrequently Noted If frontend aspires to be a profession -- something we do for others, not just ourselves -- then we need a culture that can use statistical methods for measuring quality and reject the marketing that ...

So the joke goes "a platform engineer walked into a React conference..."

infrequently.org/2025/06/conferen…

A notification on an iOS home screen with the new “liquid glass” design style that is hard to read due to white text on a light blue background

what the fuck is this contrast?

For sure that's another part of the equation. So much of the ecosystem integrates with React/Next as the "default" (whether by way of contracts or that's where the value is).

So if you need those integrations, or have clients/partners that do, it's tough not to lean into the ecosystem.

One of the bigger challenges I have had promoting @solidjs.com is assuming developers have a general idea of how their tools work. I'd show off fine-grained rendering, and be met with "Isn't that how React works?" I'd find myself educating them more about their existing tools.

I find myself referencing this over and over these days:

infrequently.org/2024/11/if-n...

To @ryansolid.bsky.social 's original point, it's really hard to have nuanced discussions here because often we're talking past each other, whether one's an expert or a novice.

"isn't much worse" than others.

But for those of us who do have these problems (either you're building a website/progressive enhanced app that needs to cater to marginal devices) or you're working in the FE dev tooling space, then the context is entirely different and the cracks show.

it would never even occur to you to consider that they are problems. For example, if you're largely focused on highly interactive, capital "A" Applications that can afford the inefficiencies of React, then sure!

Equally, if you never have to work below the "surface" of React, then maybe it...

This highlights exactly what Ryan is talking about.

Saying it "isn't that much worse" is entirely contextual to an individual's burden of knowledge to the core problems with React.

It's possible the types of software you're building don't suffer from these problems, hence...

Started migrating mine, then had a baby, so there are exactly two posts (counting the lore) in 2025. I still need to move all my older posts.

alexwells.dev

simple: deno, astro, vanilla js/css
might try integrating Zero later for fun

We did this everywhere and still had perf issues, but maybe don't read into it too much as it's anecdotal evidence.

I know @infrequently.org and others in the perf community have done some more data analysis here though, so would be interesting to look at React app perf broken down by feature use.

My point was that often I see inexperienced React devs saying that RSCs = zero clientside JS, or more generally, no clientside impact, which is inaccurate, since it's sent twice (once as HTML, again as vdom metadata).

Agreed, misdirection is the wrong word.

yep! we would do this but it's tough to get non-expert engineers to do this effectively without a crash course in all of this... was tough to try and optimize for as a platform eng

INP and total page weight were hit hardest, which had outsized impact on users who on slower devices/connections (frequent in say, the back of a pharmacy where service is crappy and/or bandwidth is limited).

FCP was good because of the fast initial shell. LCP was rough but might be unrelated.

We had hundreds if not thousands of components, but the vast majority 95% were RSCs laying out non-interactive UI.

I'm curious if you know what the React team is considering for optimizing this initial payload. Will it be a Qwik-like direction where metadata is embedded into the HTML?

Ooh thanks I missed that other thread!

Yeah, agreed. IME at my prior work (goodrx.com), content-heavy site, the duplicated HTML ended up significantly impacting pagespeeds. And for this interaction class, where user session depth is shallow (not many interactions on avg), it was a "bad" tradeoff.

@danabra.mov correct me if I'm misunderstanding here. Been doing a lot of deep dives into trying to better understand this and the related approaches across other frameworks, e.g. Qwik/Marko resumability, islands, etc.

NEXTJS 13: self.__next_f.push · vercel next.js · Discussion #42170 I want to write right away that I have begin work with nextjs since version 12. Hello, somebody knows what is it self.__next_f.push in source code. self.__next_f.push double all content on webpage....

Related Next.js discussion on the RSC metadata / limitations: github.com/vercel/next....

All in all just wish there was more nuanced discussion to the impacts and tradeoffs here. Too often I see it get hand-waved away with hyperbolic "SPA is best" or "react is garbage" type discourse, when there's a lot of nuance.

I think it depends on the application class you're building ultimately.

Also think it's fair to point out that you can include clientside interactivity in `.astro` files by adding script tags in the template return and those get scoped and bundled.

But there's tradeoffs here (as you write) since the islands are isolated, and you have to do work to share between them.

Astro is an MPA framework, so it doesn't suffer from this, but instead (as you write) has MPA-specific drawbacks.

Just think it's worth clarifying that astro components result in "just HTML", whereas RSCs result in HTML + metadata (which in Next is a bunch of script tags at the bottom of the doc).

This isn't "react-specific" either necessarily, it's a side effect of SPA architecture, which is built on the premise of having a local data model (meaning you know ahead of time what the routes are).

I think this is a critical piece of information that is often hand-waved in RSC discourse, and is a fundamental difference between an Astro component.

It saves clientside compute since RSC nodes can be skipped on the client, but the payload is still sent down the wire and has to be parsed.

and it has to start from a single root, the server still has to send all of the metadata for RSCs down on initial load. This is necessary, as I understand it, so that React can find and attach event listeners (and frameworks, e.g. Next use it for routing metadata as well).

"If a component truly does not require interactivity, just remove 'use client' from it, and then importing it from the Server world would already keep it Server-only."

I think one note absent from RSC discourse is that "server-only" here is, IMO, misdirection. Since React still needs to hydrate...

This is a great comparison and excellent writeup as always. Definitely seems like there's a lot of overlap between astro "components" and RSCs.

Been having a lot of thoughts here... *deep breath*