The frontend ecosystem feels like it is vibrating at a different frequency lately. It is more fragmented than ever if you look at the sheer number of libraries, yet we are seeing this intense consolidation around a few very specific, very opinionated tools. Today's prompt from Daniel is about that exact tension—the evolution of frontend design and where the loyalty is actually landing in twenty twenty-six.
It is a fascinating moment, Corn. Herman Poppleberry here, and I have been diving into the data on this all week. March twenty twenty-six feels like a real tipping point. We have moved past the era where a framework was just a way to organize your code. Now, a framework is essentially a delivery vehicle for AI-generated patterns. By the way, fun fact—Google Gemini three Flash is actually writing our script today, which is fitting because we are talking about how these models are shaping our architectural choices.
It is a bit meta, isn't it? The AI is telling us how AI tells us to build websites. But let's look at the landscape Daniel mentioned. He pointed out that Astro has this incredibly loyal userbase. I remember when Astro was just the "islands architecture" curiosity. Now, it feels like the default for anything that isn't a complex enterprise dashboard. What changed in the last year or so to make it go from niche to mainstream?
I think it goes back to the Astro four point zero release in late twenty twenty-four. They did something very smart—they doubled down on content collections and what they called "Actions." They realized that most developers were tired of the "hydration tax." For years, we were shipping massive amounts of JavaScript to the browser just to make a button click or a menu toggle work. Astro's rejection of client-side JavaScript as the default really started to resonate as performance budgets became strictly enforced by search engines and accessibility standards.
But wait, explain the "hydration tax" to me like I’m five. I get that it’s "heavy," but what is actually happening in the browser that makes it such a villain in twenty twenty-six?
Think of it like this: in the old React-only world, the server would send a fully cooked meal—the HTML—to your table. But then, the waiter would stand there and re-cook the exact same meal right in front of you—that’s the hydration—just to make sure the salt and pepper shakers worked. It’s redundant. You’re downloading the data, then downloading the JavaScript to process that data, and then the browser has to execute all that script just to attach event listeners. Astro says, "Here is the meal. The salt and pepper already work. Only call the waiter if you want to order dessert."
That makes total sense. So the "islands" are just the dessert cart?
Only the interactive parts—a search bar, a shopping cart, a live chat—get that JavaScript. The rest is just pure, fast HTML.
The hydration problem always felt like we were trying to solve a problem we created ourselves. We built these massive single-page applications for simple blogs and then spent five years trying to figure out how to make them load faster. Astro just said, "What if we didn't do that?" But I want to push on that—what does "frontend design" even mean now? We have islands architecture, edge rendering, and streaming server-side rendering. Is the line between frontend and backend essentially gone?
It is blurring to the point of disappearing. In twenty twenty-six, we talk about "full-stack frontend." When you look at things like streaming SSR, which is now the default rather than an optimization, the server is doing the heavy lifting of composing the UI. The user sees the content almost instantly while the interactive "islands" wake up in the background. It is a more honest way to build for the web.
It is honest, but is it simple? I feel like every time we "simplify" the frontend, we add three new layers of build tools. You mentioned consolidation earlier. If everyone is using different frameworks like SvelteKit, Astro, or Qwik, where is the actual consolidation happening? Because it doesn't look like we are all using one language yet.
The consolidation is happening underneath the hood, specifically in the build engine. Vite has essentially won the war. If you look at the State of JS twenty twenty-five survey, eighty-seven percent of new projects were using Vite as their build tool. It doesn't matter if you are using Astro, Svelte, or even the new WordPress block editor—Vite is the engine. And now, with the Rolldown beta that just dropped this month, we are seeing the next step: moving that entire layer to Rust for speed.
But how does a build tool consolidate the ecosystem if we are still writing in different syntax? Does Vite actually make a Svelte developer and a React developer more compatible?
In a way, yes. Because Vite uses a unified plugin system. If I write a plugin for image optimization or tailwind processing, it works across the board. We’ve stopped fighting about how to bundle code and started focusing on how to write it. It’s like how every car manufacturer uses different body styles, but eighty percent of them are buying the same Bosch sensors and transmissions. The "guts" of the web are becoming standardized.
Ah, the "rewrite it in Rust" phase of the cycle. I was waiting for that. But let's talk about that Figma case study from last year. They moved their marketing site from Next.js to Astro in the third quarter of twenty twenty-five. Their Lighthouse score went from a seventy-two to a ninety-eight. That is a massive jump for a company of that scale. Was that purely because of the shift away from the "everything-is-an-app" mindset?
Precisely. Next.js is brilliant for complex, highly interactive applications where the state is constantly changing—think of a dashboard or a social media feed. But for a marketing site, even a complex one like Figma's, you want the content to be static and the interactivity to be isolated. Next.js fourteen's app router created a lot of fragmentation because it forced a specific way of thinking about server components that didn't always mesh with how marketing teams want to manage content. Astro's content collections created cohesion instead.
I remember reading about that migration. Didn't they mention that their build times dropped by something like sixty percent too?
They did. And that’s a huge "developer experience" win. When you have a marketing team trying to push a new landing page for a product launch, waiting twelve minutes for a Vercel deployment to finish is a nightmare. With Astro, because it’s not trying to pre-render a complex state tree for every single page, the build is just... leaner. It’s a return to the "static site" roots but with twenty twenty-six muscles.
It sounds like Next.js might have over-engineered itself into a corner for a certain segment of the market. I mean, they are still the giant in the room—what, forty-five percent market share according to the recent Stack Overflow survey? But the momentum feels different. It feels like Next is the "enterprise safe" choice, while Astro is where the excitement is.
There is a bit of that. But we also have to look at the "TanStack-ification" that's happening. Developers are moving away from monolithic frameworks and toward these highly specialized, framework-agnostic libraries. TanStack Query, TanStack Table, TanStack Router—these are becoming the standard way to handle data and state regardless of whether you are using React or Solid. It is a modular way of building that feels very twenty twenty-six.
I like that. It is like we are building with Lego bricks rather than buying a pre-built house. But let's get into the AI angle, because Daniel hit on something huge there. AI code generators like Cursor and Claude Code are steerage mechanisms. If I ask an AI to "build me a high-performance blog," what is it giving me?
It is almost certainly giving you Astro. These models are trained on the most successful patterns of the last couple of years. Because Astro has such a clear, readable syntax and a very specific "performance-first" pitch, it has become the "Astro-first" bias in AI. The AI "knows" that Astro is the right tool for SEO and speed, so it suggests it. Then, a new developer uses it, loves it, and writes a blog post about it, which then gets crawled and fed back into the next model's training data.
So it is a feedback loop. The AI is creating a monoculture based on what it thinks we want. Does that worry you? That we might be losing the "weird" web because the AI keeps suggesting the same three frameworks?
It is a double-edged sword. On one hand, it raises the floor. We are seeing fewer terrible, slow websites because the defaults are better. But on the other hand, the "build step" is becoming a black box for a lot of junior developers. They are learning the framework patterns before they understand the underlying browser APIs. If the AI hallucinates a build configuration, they are stuck.
I’ve seen that happen. You get these developers who can build a complex island in Astro but don't know how to write a vanilla fetch request. It’s a strange knowledge gap. But speaking of the build step, you mentioned Rolldown and the speed increases. If builds are ten to twenty times faster, does that change the developer's relationship with the code?
It makes the feedback loop instantaneous. In the Webpack era, you’d make a change, go grab a coffee, and wait for the hot module replacement to kick in. Now, with Vite and Rolldown, the change is reflected before your fingers even leave the keyboard. That speed is addictive. Once you experience a sub-one-hundred-millisecond dev server start, you can never go back to a framework that takes five seconds.
But wait, isn't there a risk of "micro-fiddling" when the feedback is that fast? If I see the change instantly, I might spend three hours tweaking a hex code instead of finishing the feature.
(Laughs) That’s a human problem, Corn, not a tool problem. But actually, the speed helps with debugging more than anything. If you can see exactly which line of code broke the layout the instant you type it, you don't have to keep a "mental map" of the last ten changes you made. You just look at the screen. It lowers the cognitive load significantly.
That speed also enables more experimentation. I think that is why we are seeing frameworks like Qwik gain traction. Qwik’s whole thing is "resumability"—the idea that the app starts on the server and just continues on the client without "replaying" the logic. It’s technically brilliant, but it’s a lot to wrap your head around. Do you think Qwik will ever hit the mainstream like Astro has?
It is struggling with the "mental model" hurdle. Developers understand "islands"—it’s a simple metaphor. "Resumability" is a much more complex concept. However, in an AI-driven world, the complexity of the mental model matters less if the AI can write the boilerplate for you. If the AI handles the resumability logic, the developer just sees the performance gains. That might be Qwik’s path to the top.
So the framework that wins isn't the one that's easiest for humans to understand, but the one that's easiest for AI to generate correctly? That is a wild shift. It reminds me of how TypeScript took over. It wasn't just because types are good—it was because types make the IDE and the AI much more helpful.
TypeScript is the perfect example. It is officially the most-used language on GitHub as of this year. It won because it provides the "guardrails" that both humans and AI need to collaborate effectively. In twenty twenty-six, if your framework doesn't have first-class TypeScript support and a predictable structure for an LLM to follow, it is essentially invisible.
Let's talk about the "backendless" trend Daniel mentioned. We are seeing more adoption of server functions and things like tRPC. Is the traditional API layer dying?
It is being abstracted. With tRPC, you get end-to-end type safety without the overhead of GraphQL. You just define a function on the server and call it on the client like it’s a local function. It feels like magic, but it’s just very clever code generation. This "bridge" between frontend and backend is where a lot of the innovation is happening. We are moving toward "thick" frontends that own their own data fetching logic entirely.
But how does that work in practice for a team with separate frontend and backend engineers? If I’m the frontend guy and I’m just "importing" a server function, don't I need to know exactly how the database is structured?
That’s the beauty of it. You don’t need to know the database structure, you just need to know the type of the data coming back. If the backend dev changes a field from a "string" to an "integer," your frontend code will literally show a red squiggly line before you even try to run it. It forces a contract between the two sides of the house that didn't exist when we were just throwing JSON over a fence and hoping for the best.
It feels like we are returning to the simplicity of the early web, but with a massive amount of hidden complexity making it possible. We want the developer experience of nineteen ninety-five—just save a file and it's live—but with the power of twenty twenty-six.
That is exactly it. Look at Biome, for example. It’s an all-in-one alternative to ESLint and Prettier. It’s written in Rust, it’s incredibly fast, and it just works. Developers are tired of spending hours configuring fourteen different linting and formatting tools. They want a "zero-config" world.
I’m all for that. I’m a sloth, remember? I want the path of least resistance. If I can get a ninety-eight Lighthouse score and a type-safe backend connection without having to read a three-hundred-page manual on build configurations, I am a happy camper.
And that is why Astro is winning. It’s the "happy camper" framework. It gives you the performance by default and stays out of your way. But we should talk about the edge. Edge computing is now a massive part of this. We aren't just deploying to a server in Virginia anymore; we are deploying to hundreds of nodes globally.
And that changes how we think about data. If my frontend is running at the edge, my database needs to be there too, right? Or at least have a very fast way to get there.
Which is why we see the rise of globally distributed databases and edge-compatible ORMs. The "fragmentation" Daniel mentioned isn't just in the UI; it’s in the entire stack. But again, the consolidation is happening around specific providers who have figured out the "one-click" deployment to the edge.
It’s a good time to be a developer, but a confusing time to be a beginner. If you were starting today, in March twenty twenty-six, what would you even learn first?
I would tell them to learn Vite. Seriously. Don't worry about the frameworks yet. Understand how the build tool works, understand the browser APIs, and then pick a framework like Astro to see how those pieces fit together. If you understand Vite, you can move between Svelte, Vue, or React with relatively little friction.
Does that mean HTML and CSS are becoming secondary? I see so many new devs who can write a Tailwind class but can't explain what a <div> is actually for.
That’s a real risk. I call it "abstraction amnesia." We’re so far removed from the metal that when something goes wrong with the CSS cascade, people just keep adding !important or wrapping things in more components. But the reality is, the browser still speaks HTML. No matter how many layers of Rust and AI we put on top, your user is still looking at a DOM tree. If you don't understand that tree, you're just a passenger in your own codebase.
That is solid advice. It’s about learning the foundation rather than the wallpaper. What about the "Shadcn-ification" of the web? Daniel mentioned these copy-paste component patterns. It feels like everyone’s site is starting to look the same. Is that just the price we pay for speed?
It’s the "design system" era. We’ve realized that building a button from scratch for the ten-thousandth time is a waste of human potential. Tools like Shadcn/ui aren't component libraries in the traditional sense; they are patterns you own. It’s a middle ground between a rigid library and building from scratch. It leads to a certain visual consistency, yes, but it also ensures that things like accessibility and keyboard navigation are handled correctly by default.
True. I’d rather have a "boring" site that everyone can use than a "unique" site that breaks on a screen reader. But I do miss some of the creative chaos of the early web. Maybe that will be the next trend—the "post-AI" aesthetic where people intentionally build things that look like a human made them, warts and all.
The "hand-crafted" web. I can see that. But for the commerce and content sites that drive the economy, performance and reliability will always be king. And right now, the crown is shared between Astro for content and Next.js for apps, both powered by the invisible hand of Vite and Rust-based tooling.
So, looking forward—what is the "next big thing" that isn't on everyone's radar yet? We've talked about AI, Rust, and the edge. What is the sleeper hit of late twenty twenty-six?
I think it’s going to be "AI-native" frameworks. Not just frameworks that AI can write, but frameworks intended to be run and modified by AI in real-time. Imagine a UI that adapts its own structure based on the user’s intent, generated on the fly. We are seeing the very early stages of that with "generative UI" components, but a full framework built for that could change everything.
That sounds both amazing and slightly terrifying. A website that rewrites itself while I'm looking at it? I’m not sure I’m ready for my browser to have that much agency.
It’s the logical conclusion of the trends we’re seeing. If we can ship zero JavaScript and use the edge to stream everything, why not stream a custom-built UI for every single user?
Because I like knowing where the "Buy" button is, Herman! If it moves because the AI thinks I’m in a "creative mood," I’m going to lose my mind. But I see your point. The abstraction layers just keep getting deeper.
They do. But for now, the practical takeaway for anyone listening is that the "frontend" is no longer a silo. You have to understand the build, the edge, and how to prompt your AI tools to get the best out of these modern architectures. Consolidation is happening, but it’s happening around speed and developer experience.
Well, if speed is the goal, I should probably wrap this up before I fall asleep. I am a sloth, after all. This has been a deep dive, Herman. I think we’ve covered a lot of ground for Daniel.
It’s a wide-ranging topic, but that is what makes it fun. There is always something new to read, some new benchmark to obsess over.
And some new Rust-based tool to install. I'll stick to my slow-and-steady approach, but I'll make sure my site loads in under a second.
That is the spirit. High-performance slowness.
Always. Let's move into some practical takeaways for the folks at home. If you're choosing a stack today, what's the move?
If it's a content-heavy site, a blog, a portfolio, or a marketing page, use Astro. It is the safe, high-performance default. If you're building a "software as a service" product with complex user states, Next.js is still the powerhouse. But regardless of what you choose, invest time in learning Vite. It is the common denominator across the entire ecosystem right now.
And don't be afraid of the AI tools, but don't let them drive the bus without a license. Use them to generate the boilerplate, but make sure you understand the output. Otherwise, you're just one hallucination away from a broken build.
Also, keep an eye on the "TanStack" ecosystem. Those libraries are the best way to keep your code adaptable. If you ever want to switch from React to Svelte, having your data fetching and table logic in a framework-agnostic library makes that transition so much easier.
Great advice. And I suppose we should mention the "accessibility" part too. With all these new tools, there's no excuse for a non-accessible site in twenty twenty-six. Use the patterns that have the guardrails built in.
Accessibility is a requirement, not a feature.
Well, that feels like a solid place to leave it. We've looked at the rise of Astro, the dominance of Vite, the Rust-ification of the build layer, and the "Astro-first" bias of our AI overlords.
It’s a lot, but it’s an exciting time to be building for the web.
If you say so, Herman. I’m just here for the cheeky observations. Thanks as always to our producer Hilbert Flumingtop for keeping the gears turning behind the scenes.
And big thanks to Modal for providing the GPU credits that power this show. We couldn't do these deep dives without that horsepower.
This has been My Weird Prompts. If you're enjoying our brotherly banter and technical deep dives, a quick review on your podcast app really helps us reach more curious minds.
Find us at myweirdprompts dot com for the full archive and all the ways to subscribe.
We’ll be back next time with whatever "weird" topic Daniel sends our way. Until then, keep your Lighthouse scores high and your hydration taxes low.
See ya.
Bye.
