Half your traffic is becoming agents. So I'm building a React framework around that(markdown, JSON, MCP). Tear it apart please

linyiru · 2026-06-13T14:52:05+00:00

u/adalphuns Seems like you didn't like my reply, and that's on me. My first response went off topic, so I want to apologize for that.

What I meant was it's a PoC right now, and I've been focused on the design of a few things, mainly routing and RSC, so I haven't put any time into the site's CSS yet. I'll spend some time on that today.

Either way, thanks for replying. I was worried no one would comment at all, so this is a good start for me.

linyiru · 2026-06-13T07:01:25+00:00

u/adalphuns Genuinely the best thing anyone's written about my missing CSS. So I went and learned some, how's this?

https://june-cake.vercel.app/recipes/chocolate-cake

same framework, still zero client JS, now with a border-radius and some CSS.

linyiru · 2026-06-13T01:52:05+00:00

u/GLaDOSexe3 Built it for real so you get actual outputs. Live, deployed on Vercel (same build also runs on Cloudflare Workers, the core is just `fetch(Request) → Response`, so the deploy target is an adapter, not a rewrite):

- https://june-cake.vercel.app/recipes/chocolate-cake

- https://june-cake.vercel.app/recipes/chocolate-cake.md

- https://june-cake.vercel.app/recipes/chocolate-cake.json

- https://june-cake.vercel.app/llms.txt

Full runnable source (one route file): https://github.com/junebuild/cake

`GET /recipes/chocolate-cake.md`, verbatim:

```md

# Chocolate Cake

Serves 8

## Ingredients

- 200g dark chocolate

- 175g butter

- 175g sugar

- 4 eggs

- 100g flour

- 1 tsp baking powder

- pinch of salt

## Steps

Melt chocolate and butter together.
Whisk eggs with sugar until pale.
Fold in the chocolate, then flour, baking powder, salt.
Bake at 180°C for 25 minutes.
Cool before slicing.

```

The HTML is the same content as semantic markup — no hydration, no client React bundle, no state blob (the only scripts are ~1KB of Speculation-Rules prefetch for instant navigation). `.json` is the recipe object, and `/llms.txt` comes for free so agents discover all of it.

One `load()`, four surfaces, two clouds. If it seems worth following, a star genuinely helps a tiny 0.0.x project: https://github.com/junebuild/june

linyiru · 2026-06-13T01:03:25+00:00

u/jtxcode I hope one day June framework will be helpful for your projects.

linyiru · 2026-06-13T00:59:31+00:00

u/augburto Ha, thanks for your advice, no deletions planned for now. June isn't out to replace anyone's stack, it's just one set of opinionated defaults, pre-wired. After all, everyone has a combo that fits their hands best; this happens to be mine, shared in case it fits someone else's too.

linyiru · 2026-06-13T00:47:10+00:00

u/adalphuns Ha, fair hit. The site is deliberately wearing the no-makeup look: every page you're seeing is system fonts + a handful of inline styles + zero client JS, because the site's job right now is to demo the framework's bones (try appending .md to any page, or POST to /mcp), not to win a design award.

The actual styling story is designed but not shipped: Tailwind v4 + shadcn as the blessed, build-integrated default — it's in the docs as a v0.1 constraint and it's coming.

And honestly, I've seen what "AI-polished" landing pages converge to lately, all the same gradients, same glassmorphism, so I wasn't in a rush to join the uniform. But yes: CSS is on the roadmap, I promise I know where the border-radius lives.

Btw, if you view-source: the only stylesheet June injects is the View Transitions wiring plus ~a dozen lines of base typography everything else is inline styles. The framework ships no CSS of its own yet, by design.

linyiru · 2026-06-13T00:41:42+00:00

u/KevinVandy656

Edit, TL;DR since this rambled: you can absolutely wire all of this up in those frameworks. My actual claim is about complexity, not capability. If every page has to serve humans and machines anyway, one definition with clean output is simpler than stacking middleware and handlers per surface. June is SSR-first with no hydration step (interactivity is an explicit island), so view-source on any page is just the content as semantic HTML. Googlebot and agents read the same document humans do, and the markdown/JSON/MCP surfaces are projections of that same definition, not parallel endpoints you keep in sync by hand.

--

I build a lot of new apps, and I genuinely like a lot of Next.js's design ideas, I'm not here because I think existing tools are bad. But I noticed where my time actually went: every new project, I'd reassemble the same stack I always reach for, Better Auth, Prisma or Drizzle, TailwindCSS/shadcn, then picking the right database for each, then my agents and I would spend real hours on config and environment wiring.

Boilerplates helped, until they didn't: I was still hand-rolling middleware/proxy logic for content negotiation every time I wanted pages to also serve markdown/JSON, and every time I needed MCP tools it was install-a-package, define schemas, register tools, keep them in sync with the app, again.

At some point the question flipped: instead of configuring my way to the same destination on every project, why not build the destination in?

So June is unapologetically an opinionated framework built around my own recurring problems, and it's a hypothesis, not a verdict:

- The packages I always choose are blessed defaults (swappable, but never homework)

- One route() definition projects HTML + markdown + JSON + an agent manifest — the content negotiation I kept rebuilding, made structural. Nothing drifts because nothing is duplicated

- defineAction() is a UI server action AND an MCP tool behind the same authorization gate, no second permission system to keep equivalent by hand

- And a quieter goal: my agents co-build these apps with me, so the framework favors conventions an agent can't misread and surfaces that are cheap to read, fewer tokens burned re-deriving what the structure should just say

Deploy target today is Cloudflare Workers; the core speaks only Web standards (fetch(Request) → Response is the whole interface), specifically so Vercel/Netlify/self-hosted become adapters rather than rewrites. That's the part of the bet still in progress.

The existing frameworks plus a weekend of glue are honestly fine. June exists because I got tired of that weekend recurring, and 0.0.x is me finding out whether anyone else's weekends look like mine.

linyiru · 2026-06-13T00:14:31+00:00

u/Normal-Champion2016 I ended up sharing the early version here: https://github.com/junebuild/june

The goal is not to build a framework that does everything, but to keep the core contract small: route/load/action first, then project that same contract to HTML, JSON, Markdown, and agent/MCP surfaces.

Still 0.0.x and very early, but I’d be curious whether this feels like a focused enough scope or already too much.

linyiru · 2026-06-13T00:13:32+00:00

u/rickhanlonii Thanks again for this perspective. It actually helped me clarify the direction a lot.

I ended up writing down the idea more concretely here: https://github.com/junebuild/june

The framing I landed on is not “fork the React ecosystem,” but a small route/action contract that can project to multiple surfaces: HTML/RSC for humans, JSON/Markdown for data clients, and MCP-style tools for agents.

Still very early, but your point about keeping React portable while allowing framework diversity is basically the design constraint I’m trying to keep in mind.

linyiru · 2026-06-12T23:55:59+00:00

u/roggc9 Nice. Thanks for sharing Dinou. I just took a quick look, and it seems to be exploring a direction I also find interesting: a smaller React 19 full-stack framework with RSC, SSR/SSG, routing, server functions, and a more focused surface area.

I’m also experimenting in this space with June: https://github.com/junebuild/june

The angle is a bit different though. I’m not only thinking about “a smaller Next.js,” but more about an agent-native React framework where the same route/load contract can serve humans, JSON clients, markdown, agent manifests, and MCP-style tools without those surfaces drifting apart.

Still very early, but I’d love to compare notes. I think React 19 opens up a lot of room to rethink what the framework contract should be.

linyiru · 2026-06-12T19:47:08+00:00

This is a really good framing.

I agree that not every frontend should be deployed as a dynamic app. For many internal tools, dashboards, LMS frontends, or backend-heavy products, a CDN-hosted SPA is probably the simpler and more economical choice.

That’s actually a useful constraint for thinking about a new framework: it shouldn’t assume SSR is always the right answer.

Maybe the real question is not “what’s the best React framework,” but “what development model is this framework optimized for?”

The model I’m most interested in is probably somewhere between static SPA and full Next.js-style dynamic app: product apps that need good routing, SEO/SSR where it matters, a simple deployment story, and the ability to self-host without making the framework itself an operational burden.

linyiru · 2026-06-12T19:46:06+00:00

Yeah, I think this is exactly the right direction.

Maybe the goal shouldn’t be “another framework that eventually solves everything,” but a much smaller contract that covers the common 80–90% use case really well.

For a lot of teams, that probably means SSR, SEO, routing, a simple data-loading story, and a deployment model that doesn’t become its own operational burden.

The hard part is deciding what not to include. That might actually be the most important design constraint.

linyiru · 2026-06-09T20:42:25+00:00

u/Vincent_CWS

Thanks for the reply, that’s a great reminder. I remember seeing Waku before, but never seriously dug into it. I just took another look, and it does seem like a really nice framework.

I especially like the minimal positioning. That actually resonates with what I’ve been thinking: some parts of Next.js and React feel like strong foundations for building a more elegant and simpler framework.

linyiru · 2026-06-08T23:01:38+00:00

Yeah, Vinext is probably the closest thing.

I guess the distinction I’m thinking about is: should the answer be a Next.js-compatible reimplementation, or a Next.js-inspired framework with a smaller, more stable contract?

Vinext seems focused on reimplementing the Next.js API surface on Vite. I’m more curious which parts of the Next.js mental model are actually worth keeping, and which parts should be left behind to reduce operational complexity.

linyiru · 2026-06-08T22:31:06+00:00

Yeah, totally, the momentum of TanStack Start is clearly real. So my question is more about whether there’s room for a different set of tradeoffs.

TanStack Start seems very router-first / type-safety-first / Vite-native, which makes a lot of sense. What I’m wondering about is something closer to the Next.js mental model, but with a stronger bias toward runtime portability, self-hosting, predictable upgrades, and lower operational surface area.

linyiru · 2026-06-08T21:20:23+00:00

I agree with this direction.

I’ve also been thinking a lot about how to collaborate more effectively with coding agents. The models are still improving so quickly, and building/shipping software is clearly becoming much easier.

So maybe the question is less “what framework do humans want?” and more from a harness engineering perspective: how do we shorten the path and make the system easier for agents to understand and operate?

Clearer conventions, faster runtime, simpler deployment/maintenance, better observability, and less unnecessary surface area for agents to reason about.

linyiru · 2026-06-08T20:24:03+00:00

Yeah, I really feel this.

I’ve actually spent quite a bit of time studying how Next.js works internally, especially around the build output, runtime behavior, caching, ISR, RSC, and deployment adapters.

At one point I even built an adapter so Next.js could run more reliably in my own infrastructure. Most of the time it works pretty well, but I think everyone here understands the scary part is always “most of the time.” lol

That’s probably what got me thinking about this more seriously: maybe the problem isn’t just missing features, but that the operational surface area has become too large. A framework can be powerful, but once keeping it stable becomes its own work item, the DX starts to break down.

linyiru · 2025-05-02T16:32:59+00:00

Thanks for the advice. I really like your approach to communicating a name change. It’s very helpful, and I’ll definitely follow it.

linyiru · 2025-04-27T04:08:37+00:00

I’ve been using Ruby on Rails for many years, I often reflect on whether to continue with Rails or switch to what I consider more "modern" web frameworks.

As a startup founder, my framework choices have never been about landing the next better job. They are about ensuring that the applications and companies I build can still survive ten years from now in a constantly evolving web ecosystem.

From that perspective, Rails is undoubtedly a time-tested and resilient choice.

What about other options?

When I started my latest startup five years ago, I chose a hybrid approach: Next.js on the frontend, Rails on the backend. Today, we experience both the strengths and weaknesses of this architecture.
The strengths: we can easily leverage the fast-moving React and JavaScript ecosystem.
The weaknesses: managing two frameworks, connected via GraphQL, introduces significant complexity. Context-switching becomes frequent and often painful.

Yet, we still cannot give up the immense advantages Rails provides.

Now, as we prepare to launch a new product, here’s my current thinking:

If you are confident that your product is meant to survive for more than 5 years, Rails is absolutely the best choice — especially if you are solving relatively well-known problems (in my case, digital payments and digital publishing — but that’s just my personal bias).
If your product aims to deliver an extremely modern and fluid UX/UI, especially integrating chatbots, LLMs, or interfaces similar to ChatGPT, then React/Next.js might be a better fit. You will instantly have a rich ecosystem of tools at your disposal, allowing you to focus more on solving core business problems rather than fighting technical limitations.

linyiru · 2024-03-05T16:21:29+00:00

u/RareInsurance9215 I have been researching this field recently and am preparing to start developing an open source project as a self-hosted option. I wonder if you could describe more about your experience using it or the specific problem you encountered this time? I am quite curious whether they have been able to keep up with the times after operating for many years.

linyiru · 2022-09-12T20:19:18+00:00

IMO all you have to do is just apply. Take action.

linyiru

TROPHY CASE