Both are top left.. SvelteKit closer to where Next is.

Yeah I just can't fit all logos that occupy the same/similar space on top of each other. I picked a logo that is very recognizable in each location so people could sort of fill in the gaps. Otherwise the top left (where a lot of us had been in) would be an absolute Zoo.

I never realized there was a 6 year gap between Angular.js and Angular V2. I'm gathering there were bet builds etc..., but it is a testament to how streamline the process has gotten. 20 major versions in 10 years.

Not itself.. like you can put almost anything in Astro but the main mechanism it has is lower right. It is a server driven Islands framework. It's close to the client border but it doesn't own the islands so it can't guarentee things like state preservation.

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.

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.

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.

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

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. 👇

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.

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.

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.

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.

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.

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.