This post has been originally published on my Substack publication VSL.
React is what most developers reach for first, wrapped in Next.js or Remix or just running through Vite.
That makes sense for products that behave like real apps, where the screen is constantly reacting to what the user does, but it quietly makes simple sites feel heavier than they should to be.
For most solo founders, the priority is a site that loads fast, feels snappy on cheap phones, and plays nicely with AI crawlers and search engines trying to understand what you actually do.
Imagine a landing page with a hero, three feature blocks, and an email signup form.
In a typical React setup, you are loading an entire framework just to make that form submit.
That often means shipping a bunch of useless JavaScript even though the page itself is mostly text and a couple of buttons.
This causes multiple issues, starting with visitors having to wait for JavaScript to parse before they can even scroll smoothly.
AI tools trying to summarize your site, or search engines like Google trying to index your copy, have to run your JavaScript first before they “see” your text.
That extra step can fail on slower devices, tighter crawl budgets, or when an AI assistant is racing through dozens of sites to answer a user's question about "simple task management tools."
How visitors and AI experience your stack
Picture someone on a train with spotty signal clicking your link.
They see your headline start to appear, then watch the layout shift three times as JavaScript loads, then wait for the "Sign Up" button to become clickable.
By the time the page finally loads, they have already spent a few seconds wondering whether your product will feel just as clunky.
Now picture an AI agent trying to figure out what your product does so it can recommend you to someone asking for help.
It lands on your site, waits for React to hydrate, tries to parse your state tree, and eventually gives up or grabs a half-rendered snippet that makes your product sound vague or broken.
React shines when the page is constantly changing based on what the user does: think dashboards, editors, or complex flows.
Marketing pages are different. They sit closer to a good PDF with a few buttons than to Figma or Notion. Their whole purpose is to help the visitor understand what you do and ideally take an action towards your conversion goal, be it to sign up or to download a resource.
React for apps, Astro for "reading"
The turning point for me was admitting that my main site behaves more like a magazine than an app.
People land there to understand the promise, skim through a few sections, maybe read a FAQ, and then decide if they want to try the product.
Astro fits that world because it builds pages as plain HTML first and then lets you sprinkle interactivity only where you truly need it.
The default experience puts content ahead of JavaScript, which lines up nicely with what search engines, AI crawlers, and impatient humans all tend to prefer.
For the product itself, React still plays a big role.
I use it heavily for real app features and tiny tools where it makes sense, often with AI helpers and Kilo Code (my lightweight editor setup) to move fast on more complex flows.
The site you hit first, the one where you decide if this thing is worth your time, stays much simpler and more focused on clarity than the app that sits behind it.
Hosting on Cloudflare Workers
Once the pages are built, they live on Cloudflare's network as static files.
You can think of this as uploading a folder of prebuilt pages to a network of cities around the world.
The setup is three steps: build your site, run one command to push to Workers, and you are done. I do have a Github action setup that does this automatically which I will share in a later edition.
Static files are cheap to serve (basically free), and backend only gets involved when there is something truly dynamic to handle, like a form submission or a webhook callback.
From a reader's point of view, the page shows up quickly from wherever they are, with no waiting for a single origin server halfway across the world.
From your point of view, it means one fewer thing to worry about, and one more piece of your stack that "just works" once you set it up.
From an AI crawler's point of view, it means clean HTML that arrives fast and makes sense without needing to execute a bunch of JavaScript first.
If something does go wrong, you’re usually looking at a small, specific piece of logic instead of a giant app server.
A tiny Astro example that shows the difference
Here is a concrete look at how a page can be mostly "just content" with one small interactive piece.
You do not need to understand every symbol. The key idea is that almost everything is plain HTML, and only one piece is interactive.
This example shows the file structure of a typical Astro page. The top section (between the --- marks) runs at build time to prepare variables. The middle section is your HTML template. The <Counter /> component at the bottom is the only part that ships JavaScript to the browser.
---
const title = "Ship your first version this weekend";
import Counter from '../islands/Counter.jsx';
---
<html lang="en">
<body>
<main>
<h1>{title}</h1>
<p>Describe your product in one clear paragraph here.</p>
<Counter client:load />
</main>
</body>
</html>
Here is what happens when someone visits this page:
- The browser receives HTML immediately. Your headline and paragraph appear before any JavaScript downloads.
-
Astro sends one tiny script to wake up the
<Counter />component, because you marked it withclient:load. - Everything else stays as plain HTML. No framework overhead, no hydration delay, no waiting for a bundle to parse.
Compare that to a React app, where the entire page waits for JavaScript to load before showing anything, and AI tools have to execute your bundle just to read your headline.
Why this matters for a landing page: Most of your page is static content. Your headline does not change based on user input. Your feature descriptions do not need React. Only the signup form or a demo widget might need interactivity, and Astro lets you load JavaScript for just that piece.
Why this stack matters for real people (and AI)
For readers, a fast site means less time waiting and more time deciding whether they trust you.
Most people never think about frameworks. They simply notice whether your page appears quickly on hotel Wi-Fi and whether it feels smooth on an older phone.
For AI assistants, clean HTML means they can actually understand what you do and recommend you when it makes sense.
When ChatGPT, Perplexity, or any other AI tool crawls your site, it wants structured content it can read in milliseconds instead of a React bundle it has to execute first.
Pre-built pages give AI the straight story, which means you show up in AI-generated answers instead of getting skipped for something easier to parse.
For search engines, clear, pre-built content is easier to crawl and understand.
Astro's style of building static pages plays nicely with this, and hosting them on Cloudflare's edge means the "fast page" story stays true worldwide.
For you as a founder, this split makes your life simpler.
React stays where its power actually pays off, inside your product, while your marketing site stays closer to a document you can reason about in an afternoon.
When something breaks, the stack is small enough that the issue usually lives in Astro, React, or a specific Worker instead of feeling like a maze.
I mention Yahini on the site as an example of this stack in action: Astro for content, React where it counts, and Cloudflare Workers to get it all to people and AI crawlers quickly.
That mix keeps things simple enough that when something breaks, you can usually trace the problem in one sitting.
This week's finds: Grok Code Fast 1 and serving markdown to AI crawlers
Grok Code Fast 1 has been quietly helping in the background. It is a coding-focused model built for speed and low cost, which means you can afford to iterate quickly instead of waiting for one "perfect" answer.
The best part is that you can fire off several quick rounds of prompting without worrying about your bill, things like: "draft this component," "simplify it," "make it easier to read," and treat it like a rapid feedback loop in your editor.
That makes it a great fit for experiments like "rewrite this page component for Astro" or "split this React widget into a tiny piece I can reuse elsewhere," where you mostly need many small tries instead of one giant brain dump.
For example, I used it to turn a React hero section into a simple Astro page, then asked it to remove anything that was not strictly needed for the first version. The whole experiment took about fifteen minutes and three iterations, which would have felt much slower with a heavier model.
I use Grok Code Fast 1 via Open Router, but you can also use it directly from Grok.
Serving markdown to AI crawlers with Cloudflare Workers is another small trick worth knowing about.
Someone on Reddit shared a setup where Workers detect AI crawlers (like ChatGPT or Perplexity bots) and serve them a clean markdown version of your page instead of the full HTML.
That makes it even easier for AI tools to parse your content, understand what you do, and recommend you when people ask questions your product can solve.
If you are already on Cloudflare, this is a tiny addition that can make a real difference in how AI sees your site. The setup involves checking the user agent string, then serving a simplified markdown response when it matches known AI crawlers.
Link: Using Cloudflare Workers to serve markdown to AI crawlers - Reddit post
Let's connect
Which page in your world is mostly words and a single call to action, but still runs through your full React setup?
Reply and tell me what it does and what you are using today, and I will suggest the smallest "content-first" version you could try without touching the rest of your product.
If you have already split your app this way, reply with "stack split" and tell me how it went, so I can include a few real-world examples in a future issue.
You do not have to pick between "I will just rent a platform forever" and "I need to become a full-time engineer."
One fast, simple, ownable website is often enough to start, and moving it off your full app stack might be the lowest-risk win you can grab this week.
This post has been originally published on my Substack publication VSL.
Top comments (0)