iiinova — where your digital self keeps evolving

Yeah I keep a pile of logos around for these sort of comparison. Less embarassing when I was still using Angular.js logo in like 2020.

There is a tradeoff. As far as i can tell with Solid straddling all 4 modes at the same time the base code is about 40kb minzipped, which is more than our simple SPA app. Most costs in serialization/wire protocol stuff. But that's framework/router/server functions,components.. all the pieces needed.

020

Put Nuxt next to React there.. like maybe between React and like Next. Archetypally, Next(RSCs) represent a bigger departure from our SPAs in teh top-left corner than our SSR SPA metaframeworks.

020

Being able to scale down into a single location is valuable but the coordination leaves gaps. This is exploration was a question of if we could close those gaps.

020

Ok done in the article. I don't think I can edit this post.

The Grand Unifying Architecture of Frontend

The interesting question isn't which quadrant is right. It's why you'd pick a framework that only lets you comfortably live in one. dev.to/playfulprogr...

dev.to

I used to joke that the history of frontend development could be retraced by following the argument...

380

Ryan Carniato @ryansolid.bsky.social · 16/09/2026

I've finally been able to put all frontend solutions on the same grid by recognizing them as a product of 2 axes and 3 core responsibilities. HTMX, LiveView, RSCs, islands, SPAs, Sync Engines... None express what another can't. They differ in efficiency and ergonomics. 👇

6396

The challenge in the Next.js case is outside of the nesting on navigation, when you invalidated it was basically the whole page always. They lost that property of SPAs where you can replace just the data that changed. HTML partials don't prevent that capability. SPAs know how to handle it innately.

000

Ryan Carniato @ryansolid.bsky.social · 16/09/2026

What I mean by the client being the orchestrator is that it owns the URL. Server is the source of truth but the client controls what gets pulled. Even with HTMX once you are dealing with dozens of partials its the client that decides which ones to request.

100

Almost 2 years of struggling with Next.js from v14-16 was about this more or less. The single tree ensured consistency and simplicity but it was a large overhead to carry. Even HTMX recognizes the client is the orchestrator. That was where the gap was. So architecture needs a shift.

Between the mental models/ownership. Like the reason Next RSCs are awkward is they needed their mutations to close the loop, but architecturally the server was a single tree. Which led to a lot of server side re-renders that were unnecessary and put a huge pressure on server side cache solutions.

So either there is something completely radical that can be done coming from the server perspective(unfound in 20 years). Or the missing piece is in front of us in SPA architecture and we need to look a bit harder there. Which is why I'm critical of stance I've seen many Hypermedia enthusiasts take.

011

I think its actually interesting to look at Next.js run with RSCs because that is a solution that should close the gap and yet developers feel it doesn't. That alone suggests there is still something missing here. The shape of what is missing still lives in SPAs.

200

But I am assuming that is off the table for a lot of people. My criticism of hypermedia solutions for apps isn't the technology; as I said Server Components are similar. It's that none of the tools I've seen are built for it close the gap.

110

Additionally a lot of time with SPA approaches the client acts a cache that doesn't invalidate as often (ie.. ok to be stale) so per interaction costs are actually reduced. Like if the goal is to create DBMon benchmark I imagine the best approach is actually have a persistent server that diffs.

111

Yeah I mean it depends on how much changes. HTML chunk might be fastest but do you replace the whole page? Do you replace a dozen little pieces? Do those pieces themselves contain shared client side ephemeral state. Once we stopped shipping the page wholesale the places that wiring shows up increase

110

I'm suggesting that because of their wheelhouse modern SPA frameworks tend to account for this category in their design. I view HyperMedia as lower level protocol. I don't see an issue communicating with HTML partials etc. There is just a lot that sits on top of that. bsky.app/profile/ryan...

211

No one is dismissing hypermedia or the like. Server components are basically a nod to them. There is just a reason like how you acknowledge you can't stop at HTMX, that I don't stop at Datastar. Not anything wrong with what its doing.

010

To be clear I don't have an issue with what Datastar offers, just that there is a wider spectrum of considerations. This isn't unlike how Nuxt/Next users think I'm particularly harsh on the scenario where their metaframework ships mostly static content.

110

Ryan Carniato @ryansolid.bsky.social · 11/09/2026

Thanks for posting. I would respond but @gabbev.bsky.social pretty much has it completely covered. He's not trying to be difficult. The first thing I do when playing around with an app is throttle the network and see if it holds up. I did that on stream too. I hope this thread serves as a reference.

100

The answer is surprisingly similar. The main divergence we have is in implementation. Conceptually Solid and React are very aligned on what the behavior should be, just not how to best get there.

040

Ryan Carniato @ryansolid.bsky.social · 11/09/2026

Stream is back today. Going to look at even more of the capabilities of Solid 2.0. www.youtube.com/watch?v=khmx...

youtube.com

Going, Going… LIVE! — Real-time UI in Solid 2.0

YouTube video by Ryan Carniato

0151

Ryan Carniato @ryansolid.bsky.social · 09/09/2026

It's also my understanding there was a difference of CDN so the solid image load trickle is much more visible than if they had been from the same source. I think that has been rectified now.

030

Ryan Carniato @ryansolid.bsky.social · 09/09/2026

Yeah I wouldn't consider this the done state for SolidJS + assets. React's scheduling here only landed very recently (last 12 months or so). This is in my post Solid 2.0 bucket.

240

Reposted by Ryan Carniato

Jason Lengstorf @jason.energy · 03/09/2026

we're live! @ryansolid.bsky.social and I are talking Solid v2 and the future of frameworks on the web youtube.com/live/8f09f50...

youtube.com

Does AI mean the end of progress for the web?

YouTube video by CodeTV

0182

Ryan Carniato @ryansolid.bsky.social · 02/09/2026

Learn with Jason was quite possibly my favorite early Solid moment. I'm excited to talk about all that has changed in the past 5 years.

0253

Ryan Carniato @ryansolid.bsky.social · 27/08/2026

Yes I wrote and published 5 articles in a week. Yes I'm exhausted.

1470

Ryan Carniato @ryansolid.bsky.social · 27/08/2026

When I saw this yesterday(since been fixed). I thought it was piling on the recent Cursor reveal. But then I realized these docs are from April. It's not a conspiracy. It's something worse, because there's no one to argue with. Nobody Argued For Your Stack: dev.to/playfulprogr...

3194

Ryan Carniato @ryansolid.bsky.social · 26/08/2026

Part 3 was partially inspired by a @danabra.mov (React Core team) talk. But I think you will really like how Solid 2.0 closes the gap.

0361

Ryan Carniato @ryansolid.bsky.social · 24/08/2026

Sounds like a non-reactive read somewhere. Solid 2 would complain about that. (The main site is still Solid 1).

010

Ryan Carniato @ryansolid.bsky.social · 24/08/2026

Yeah I used the livestream to help me think about how I'd cover the content for the 3 articles in this series.

011

Ryan Carniato @ryansolid.bsky.social · 24/08/2026

I still find it crazy how we are still discovering primitives that completely collapse decades of carefully crafted imperative code. Part 2 is probably more impactful as a live demo. But picture it paints is still very powerful. www.solidjs.com/blog/async-s...

solidjs.com

SolidJS

Solid is a purely reactive library. It was designed from the ground up with a reactive core. It's influenced by reactive principles developed by previous libraries.

3452

You can, but that assumes stateful server? Also server as the authoritative source is correct but there is additional layering that the client can provide uniquely since it operates without necessarily doing the full roundtrip. Rx is great at pushing but consistency guarantees aren't automatic.

Yes basically we made async colorless. Which means you aren't working in 2 worlds anymore. This is why I'm excited about this.

040

I had to stay within the means of my capability. I sang straight because I could hit the notes strong. I probably always should have but previously I could hide my pitchiness under the guise of artistry. That being said historically that would have passed to some degree. Just the world had changed.

000

It's more that its existance changed the equation. I didn't get to do my accents because autotune would have sounded fake/forced. But not autotuning was not an option because that was the expected production. People had gotten used to hearing perfect pitch.

100

For those looking for more details after the release announcement here they are. Solid's approach to Async is one of kind. And more than that it has real implications. www.solidjs.com/blog/async-s...

37314

It comes down to how much you value the ends vs the means. The answer isn't always the same. I'm not saying the ends always justify the means but the intent of the article is equally important. It is a knob. It's why I can write an article like above and see no issue with the release announcement.

130

LLM is more like if autotune could have done its job better. If I could have kept those accents. The solution here was never to remove the autotune. It might have been for me to sing better. I'd like to think I would have gotten there eventually.

220

But the truth was I needed to be a better singer and I didn't have the time to be in that moment. We wanted our stuff picked up, and we went with the more polished sound. Now someone might equate autotune with the LLM in my story. But I view it more as the bar.

100

Now it wasn't his fault. He was right but to this day I have recordings that when I hear them I'm like, that isn't right. It was my own incompetence that had it result that way. We could have removed the autotune altogether and it probably would have sounded alright intentionally sloppy.

100

Like places were I'd lift the note at the end of a phrasing. I thought it added emphasis, and I still stand by that. But the engineer got me to sing the notes straight. He knew autotune would take to it better, having to do less work and it sounded more intentional.

100

I was a songwriter. Now coming up in the late 90s early 2000s meant that autotune was very new to the market. It was really easy to overuse. Yet everyone used it. I remember I'd write parts that I couldn't quite pull off. Not because of range but because of control.

100

I'm not saying that doesn't happen anymore. I'm saying I judge the result superior. It's another tool and it's one that early stages lets me retain more of my voice if done right. Let me tell you a story. When I was a singer in a band admittedly the actual singing part was not my strongest suit.

100