From e67076ab4e636bb167904bd7a8970540b6b9e54c Mon Sep 17 00:00:00 2001 From: Tanner Linsley Date: Mon, 12 Oct 2026 08:39:17 -0600 Subject: [PATCH 1/6] Draft TanStack Start 1.0 announcement with partner logo grids --- src/blog/tanstack-start-1-0.md | 93 +++++++++++++++++++++++++ src/components/markdown/Markdown.tsx | 8 ++- src/components/markdown/PartnerList.tsx | 54 ++++++++++++++ src/utils/markdown-partner-lists.ts | 27 +++++++ tests/markdown-partner-lists.test.ts | 39 +++++++++++ 5 files changed, 220 insertions(+), 1 deletion(-) create mode 100644 src/blog/tanstack-start-1-0.md create mode 100644 src/components/markdown/PartnerList.tsx create mode 100644 src/utils/markdown-partner-lists.ts create mode 100644 tests/markdown-partner-lists.test.ts diff --git a/src/blog/tanstack-start-1-0.md b/src/blog/tanstack-start-1-0.md new file mode 100644 index 000000000..c89791708 --- /dev/null +++ b/src/blog/tanstack-start-1-0.md @@ -0,0 +1,93 @@ +--- +title: TanStack Start 1.0 +published: 2026-10-10 +draft: true +excerpt: TanStack Start 1.0 is finally here, and this is the story of how we got here. +authors: + - Tanner Linsley +library: start +--- + +# TanStack Start 1.0 + +TanStack Start 1.0 is finally here! And we're beyond excited to officially call it stable and ready for production. + +I'm so proud of what we've built and the people who helped build it, and I'm very ready to stop having the conversation where somebody tells me they're running their entire business on Start and I have to remind them it's still a release candidate (that conversation has happened a lot more than I expected). We've had people put Start into production through pretty much every stage of its development, from small projects and startups to enterprise teams and Fortune 500 companies, and some of them were insisting on using it before we even got to RC. We'd explain where things were, and they'd basically tell us, yeah, we understand, we're using it anyway. And when enterprise teams are insisting on putting it into production before you've even called it a release candidate, you start realizing that a lot of what you're still working toward is making the commitment official, settling the APIs and making sure you're ready to support the people who've already put that much trust in you. + +For me, 1.0 is us making a commitment to the APIs we've built and the people building on them. You should be able to choose Start, learn it, ship something with it, and keep building without wondering whether we're about to change the whole way your application works. + + + +Getting here took longer than I thought it would (if you read our RC announcement, I was expecting a pretty short stretch of polish), and looking back through what actually landed after that, calling all of it polish would be underselling a lot of people's work. + +## Start started with a router + +Start wasn't actually where this started, I was trying to build the router I wanted to use, and I wanted my routes to know which paths existed, which parameters they needed, what my search parameters looked like, what data a loader returned, and what context was available further down the route tree, so when I changed something, my editor could tell me what else needed to change. That sounds pretty reasonable now, but there was a lot of skepticism around it. Some people didn't think that level of type safety was possible, some didn't think it mattered, and some thought it was an awful lot of work for a router (and a few years earlier, I probably would have agreed with them). + +I used to think TypeScript was mostly extra work. I already knew what my code did, why did I need to explain it to something else? Working on React Query, and learning from the people helping move it to TypeScript, changed that for me. Eventually I started seeing types as something I could design with, something that could make an API easier to use in the first place, and once that clicked, it was hard to stop noticing all the places where we were asking developers to remember things the tools could already know. Building a router around that was a pretty big investment, I was betting on something people were telling me wasn't important or wasn't even possible, and I didn't know yet that I was also building the foundation for a full-stack framework. + +By December 2023, there's already work in the repo on the server utilities that would become part of Start, and in May 2024, there's a commit where I renamed `react-router-server` to `start`, complete with a goofy emoji (very official framework naming process). + +## I wanted another option + +Around that time, I felt like the React ecosystem was narrowing its idea of what an application should look like, Next was making a very big bet on React Server Components and a more server-oriented model, React Router and Remix were working through their own changes, and there were interesting ideas in all of it, but I wasn't comfortable with how often the conversation seemed to land on one answer for everybody. + +I wanted to keep building the kinds of applications I already knew how to build, with state, client-side navigation, data caches, and all the things that have made SPA development such a productive way to work, and I also wanted server rendering, streaming, server functions, and the ability to put work on the server when that was the right place for it, and I didn't want adding those things to mean relearning my entire application. + +That's still what I love about using Start, it feels familiar, your components are components, your routes are routes, and when you need the server, you have a pretty direct way to use it. There's a lot happening to make that easy, but I don't want you to have to keep a second explanation of your application in your head just to get through the day. And simple doesn't have to mean bare bones, I like conveniences and powerful APIs, and I want the common thing to be easy without running out of useful tools when your application gets complicated (which it probably will). + +A route can render normally on the server, load its data there without rendering its component, or render on the client. You can call a typed server function from a loader or an event handler. You can compose middleware around those calls, including work on the client and work on the server, with types carrying the context through, and those choices fit into the same application model, so you get to decide where the work belongs without giving up the routing and data tools you already understand. + +I've borrowed ideas from pretty much every framework I've used (and I've tried a lot of them). React Router has done great work on primitives, Solid has been a huge inspiration on performance, and Next knows how to explain and market an idea. I've disagreed with directions those projects have taken, sometimes pretty loudly, but there's a lot of good work there that has influenced mine. + +## Other people made it much better + +Manuel and Flo took this so much further than I could have taken it on my own. I knew what I wanted Start to feel like to use, but that doesn't mean I knew how to build every part of it, and there are things in the framework today that are better than what I even knew to ask for. So when I look back at how long this took, I also look at what actually landed, the compiler work, streaming, server boundaries, hydration, all the combinations people found by putting it in real applications, and how much of that came from people other than me. + +The [SSR performance work](https://tanstack.com/blog/tanstack-start-5x-ssr-throughput) Manuel and Flo did is one of my favorite examples. They profiled what the server was doing and kept finding work it didn't need to do, eventually getting roughly 5.5x the throughput in their benchmark. That's their benchmark, your application is going to have its own workload, but I love that we got there by going back through the implementation and understanding it better. There's a lot more of that work in this release than you can fit into an announcement, regression tests, benchmarks, allocations we don't need anymore, compiler bugs caught before they reach somebody's app. Those are things I want us spending time on when people are trusting us with their framework. + +## Freedom takes work + +I've spent years on framework agnosticism across TanStack, well before Start, because I don't want all the useful work in a library to come and go with whatever UI framework happens to be popular around it. And I want to treat those other frameworks as real options, which means actually designing for them and finding out where we've made assumptions. Supporting Solid will teach you pretty quickly which parts of your supposedly agnostic code are still thinking in React. We went through something similar [adding Rsbuild](https://tanstack.com/blog/start-adds-rsbuild-support), with assumptions about the build tool that had worked their way into the framework. + +Hosting has been its own adventure. At one point I was pretty discouraged looking at the deployment adapters we'd have to maintain, and Ryan Carniato's advice was basically to use Vite and Nitro. That helped us [change direction](https://tanstack.com/blog/why-tanstack-start-is-ditching-adapters), and I'm glad we listened, I want us spending our time making Start better, and I want you to be able to choose where you run it without that choice taking over how you build your app. + +## Yes, we spent a lot of time on RSC + +For a while, supporting React Server Components felt like a box we had to check to be taken seriously as a React framework. We spent a lot of time on it, and some really good work came out of that. Manuel in particular put a huge amount into figuring out how RSC could fit into Start without taking ownership of the entire application model. We wrote about [that approach](https://tanstack.com/blog/react-server-components), and about [who owns the component tree](https://tanstack.com/blog/who-owns-the-tree), because those decisions matter beyond whether a feature appears in a comparison table. + +We also used RSC on tanstack.com, got real value out of it, and then [stopped using it](https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com) when changes to our Markdown and highlighting code made the tradeoff different. I'm glad we could do that, we learned something, our needs changed, and we changed the implementation, which is the kind of freedom I want you to have with your own application, too. + +## Then agents showed up + +I think it was around November of 2025 when AI started noticeably changing the work around Start, and by the middle of 2026 we were dealing with it everywhere. The volume of PRs and issues went up, a lot of it was drive-by stuff, generated content that someone hadn't really read or understood before sending it to us, and that takes time away from the people actually doing the work. Security has changed along with it. People are using AI to actively look for vulnerabilities, we're using it ourselves and with partners to find and fix problems, and that's becoming a normal part of maintaining this thing. It has to be. + +But I've also been using agents to build, and watching other people use them to build with Start, and I keep coming back to the router. All that work to make the types strict, to make the APIs explicit, to give you as much freedom as possible while still being able to tell you when something doesn't fit, we did that for people. I wanted you to be able to move things around and try things and have your editor help you, without having to remember every connection in your application. An agent needs a lot of that same help, it changes a route parameter or the input to a server function and now it can find the places that no longer agree with it, and the more complicated the application gets, the more I want that feedback. It doesn't tell you whether you've built the right thing, you still have to do that part, but it gives you a way to keep making changes without guessing about all of those connections. We didn't have to redesign Router and Start around agents to get there (the design was deliberate, having it line up this well with how people are building now was a pretty happy coincidence). + +We did have a lot to teach them, though. Sarah Gerrard and Kyle Mathews helped bring [TanStack Intent](https://tanstack.com/blog/from-docs-to-agents) into the picture, and we made a big push across TanStack to get that guidance into the packages, with a lot of it anchored around how agents use Start and Router. I'm glad we invested in that too, because knowing an API exists and knowing how to use it well in somebody's application are different things. And now we have [tools for maintaining those skills](https://tanstack.com/blog/intent-0.5-skills-you-can-maintain), checking the examples and keeping the guidance connected to the code as it changes. + +## People started betting on it + +Lovable really surprised us. They were going to use Start for the applications their product generates, which is a very different conversation from somebody trying it on a side project, because you're choosing a foundation for things other people are going to build (including things you haven't seen yet). [Lovable began generating new projects with Start in May 2026](https://lovable.dev/blog/building-apps-using-tanstack-start), and their explanation connects a lot of what we've been working toward: server rendering, portability, and types that help generated code fit together. + +They weren't the first to take a chance on us. Convex supported Start when it was extremely early, and I'm still grateful for that. Vercel also supported us early on, and I'm really glad to have them back as a partner after some time away (that early support still means a lot to me). Clerk had a Start SDK in beta back in 2024. Netlify helped fund development and worked with us on deployment, and Cloudflare has been an important part of making Start work well on Workers. + +Since then we've seen people build integrations, publish examples, add deployment support, and choose Start for their own applications. WorkOS and Clerk help people bring authentication into their apps, Sentry has a dedicated SDK, and companies like Railway, Render, Vercel, and Cloudflare give people places to run what they build. Prisma has put work into getting people started with their data layer. + +## Come build something + +If you've been waiting for 1.0, I'd love for you to give Start a try. Start with the [docs](https://tanstack.com/start/latest/docs/framework/react/overview). If you're moving an existing application, we have [migration guidance](https://tanstack.com/start/latest/docs/framework/react/migrate-from-next-js), and I would absolutely put an agent to work with you on that. In my experience, agents have become a really good way to work through a migration, especially when they have the current guidance and can use the types and tests to check the changes. + +I also want to thank Manuel Schiller and Florian Pellet, Brenley Dueck, Birk Skyum, Sean Cassiere, and the wider maintainer team, along with people like TkDodo and Edmund Hung, whose contributions show up in the foundations of this work. And thank you to Jack Herrington, Sarah Gerrard, Kyle Mathews, and Ryan Carniato for the ideas, tooling, explanations, and advice that helped us get here. And to everyone who wrote a reproduction, answered somebody's question, made a tutorial, improved the docs, or patiently helped us understand what broke in their application, thank you, there's so much of that work in this release and most of it doesn't come with a name attached to a big feature. + +Thank you to our current partners for helping make this work possible. + + + +And to our previous partners and sponsors, you're part of this history too (support doesn't stop mattering when a sponsorship ends). + + + + + +I started this because I wanted a better way to build my own applications, and somewhere along the way, a whole lot of other people decided they wanted to help build it with me, and they turned it into something much better than I could have made on my own. I'm so excited to see what you build with it. diff --git a/src/components/markdown/Markdown.tsx b/src/components/markdown/Markdown.tsx index b477905e8..ea95e3713 100644 --- a/src/components/markdown/Markdown.tsx +++ b/src/components/markdown/Markdown.tsx @@ -14,6 +14,8 @@ import { } from '~/utils/markdown' import { isSafeHttpUrl } from '~/utils/url-boundary' import { mapStartHostingPartnerElements } from '~/utils/start-hosting-guide' +import { mapMarkdownPartnerLists } from '~/utils/markdown-partner-lists' +import { PartnerList, PreviousPartnerList } from './PartnerList' import { CodeBlock } from './CodeBlock' import { LiveExample } from './LiveExample' import { MarkdownLink } from './MarkdownLink' @@ -54,7 +56,9 @@ export function Markdown({ [content, document], ) const renderDocument = React.useMemo(() => { - const withHostingPartners = mapStartHostingPartnerElements(parsed) + const withHostingPartners = mapStartHostingPartnerElements( + mapMarkdownPartnerLists(parsed), + ) return chartEmbedSource ? mapChartsCatalogEmbeds(withHostingPartners, chartEmbedSource) @@ -257,6 +261,8 @@ function createMarkdownComponents( 'md-live-example': LiveExample, 'md-tab-panel': MdTabPanel, pre: CodeBlock, + 'partner-list': PartnerList, + 'previous-partner-list': PreviousPartnerList, 'start-hosting-lovable-logo': StartHostingLovableLogo, 'start-hosting-partners': StartHostingPartners, 'start-hosting-render-logo': StartHostingRenderLogo, diff --git a/src/components/markdown/PartnerList.tsx b/src/components/markdown/PartnerList.tsx new file mode 100644 index 000000000..bf40bf084 --- /dev/null +++ b/src/components/markdown/PartnerList.tsx @@ -0,0 +1,54 @@ +import { PartnerTierLogo } from '~/components/ds/ui/PartnerTierLogo' +import { partners, partnerTierLabels, type Partner } from '~/utils/partners' +import { getPartnerTierGroupsForPlacement } from '~/utils/partner-placement' +import { usePartnerPlacementContext } from '~/utils/usePartnerPlacementContext' + +export function PartnerList({ + status = 'active', +}: { + status?: Partner['status'] +}) { + const context = usePartnerPlacementContext({ + orderStrategy: 'tier-rotated', + surface: `markdown-partners-${status}`, + }) + const groups = getPartnerTierGroupsForPlacement( + partners.filter((partner) => partner.status === status), + context, + ) + + return ( +
+ {groups.map((group) => ( +
+

+ {status === 'inactive' ? 'Previous ' : ''} + {partnerTierLabels[group.tier]} partners +

+
+ {group.partners.map((partner) => ( + + + + ))} +
+
+ ))} +
+ ) +} + +export function PreviousPartnerList() { + return +} diff --git a/src/utils/markdown-partner-lists.ts b/src/utils/markdown-partner-lists.ts new file mode 100644 index 000000000..583bce2b0 --- /dev/null +++ b/src/utils/markdown-partner-lists.ts @@ -0,0 +1,27 @@ +import type { MarkdownDocument } from '@tanstack/markdown' + +// Standalone blocks only, so examples inside code fences stay literal. +export function mapMarkdownPartnerLists( + document: MarkdownDocument, +): MarkdownDocument { + return { + ...document, + children: document.children.map((block) => { + if (block.type !== 'html') return block + + const match = block.value.match( + /^\s*<(partner-list|previous-partner-list)>\s*<\/\1>\s*$/, + ) + if (!match) return block + + return { + type: 'component', + name: match[1], + tagName: match[1], + attributes: {}, + properties: {}, + children: [], + } + }), + } +} diff --git a/tests/markdown-partner-lists.test.ts b/tests/markdown-partner-lists.test.ts new file mode 100644 index 000000000..5a556e097 --- /dev/null +++ b/tests/markdown-partner-lists.test.ts @@ -0,0 +1,39 @@ +import assert from 'node:assert/strict' +import { it } from 'node:test' +import { parseSiteMarkdown } from '../src/utils/markdown' +import { mapMarkdownPartnerLists } from '../src/utils/markdown-partner-lists' +import { getPartnerTierGroupsForPlacement } from '../src/utils/partner-placement' + +it('renders both partner markers but leaves code examples alone', () => { + const document = mapMarkdownPartnerLists( + parseSiteMarkdown( + '\n\n\n\n```html\n\n```', + ), + ) + assert.equal(document.children[0]?.type, 'component') + assert.equal(document.children[1]?.type, 'component') + assert.equal(document.children[2]?.type, 'code') +}) + +it('keeps tier order and reproduces the server order from serialized context', () => { + const partners: Parameters[0] = [ + { id: 'a', name: 'A', tier: 'bronze', category: 'deployment' }, + { id: 'b', name: 'B', tier: 'gold', category: 'deployment' }, + { id: 'c', name: 'C', tier: 'gold', category: 'deployment' }, + { id: 'd', name: 'D', tier: 'silver', category: 'deployment' }, + ] + const context: Parameters[1] = { + orderStrategy: 'tier-rotated', + rotationSeed: 'root-loader-seed', + } + const server = getPartnerTierGroupsForPlacement(partners, context) + const client = getPartnerTierGroupsForPlacement( + partners, + JSON.parse(JSON.stringify(context)), + ) + assert.deepEqual( + server.map((group) => group.tier), + ['gold', 'silver', 'bronze'], + ) + assert.deepEqual(client, server) +}) From ab302ff2242091f32835425649db60300f1e59b0 Mon Sep 17 00:00:00 2001 From: Tanner Linsley Date: Mon, 12 Oct 2026 10:13:59 -0600 Subject: [PATCH 2/6] Apply spoken announcement edits and reuse homepage partner grid --- src/blog/tanstack-start-1-0.md | 82 +++++++++++++++---------- src/components/PartnersGrid.tsx | 4 +- src/components/markdown/PartnerList.tsx | 44 ++----------- 3 files changed, 58 insertions(+), 72 deletions(-) diff --git a/src/blog/tanstack-start-1-0.md b/src/blog/tanstack-start-1-0.md index c89791708..37b126b5e 100644 --- a/src/blog/tanstack-start-1-0.md +++ b/src/blog/tanstack-start-1-0.md @@ -10,84 +10,104 @@ library: start # TanStack Start 1.0 -TanStack Start 1.0 is finally here! And we're beyond excited to officially call it stable and ready for production. +TanStack Start 1.0 is finally stable. And we're really excited to officially call it ready for production. -I'm so proud of what we've built and the people who helped build it, and I'm very ready to stop having the conversation where somebody tells me they're running their entire business on Start and I have to remind them it's still a release candidate (that conversation has happened a lot more than I expected). We've had people put Start into production through pretty much every stage of its development, from small projects and startups to enterprise teams and Fortune 500 companies, and some of them were insisting on using it before we even got to RC. We'd explain where things were, and they'd basically tell us, yeah, we understand, we're using it anyway. And when enterprise teams are insisting on putting it into production before you've even called it a release candidate, you start realizing that a lot of what you're still working toward is making the commitment official, settling the APIs and making sure you're ready to support the people who've already put that much trust in you. +I can't begin to say how proud I am of what we've built here and of the people who have built it. And I'm also really, really looking forward to not needing to remind everybody who's already using it in production that it's still a release candidate (that conversation has happened a lot more than you'd think). We've had tons of people put Start into production through pretty much every stage of its development, from small projects and startups to entire enterprise teams and Fortune 500 companies. To our surprise, so many of these companies insisted on using it even when it was in beta. We'd explain where things were, and they'd basically tell us we're going to use it anyway. -For me, 1.0 is us making a commitment to the APIs we've built and the people building on them. You should be able to choose Start, learn it, ship something with it, and keep building without wondering whether we're about to change the whole way your application works. +When enterprise teams are insisting on putting your beta software into production before it's even a release candidate, it's difficult to not feel the massive level of trust everybody is putting in you. So even though people have been successfully using Start in production for a long time, this is us making our formal commitment to the APIs we've built and the people building on them. You can now choose Start, learn it, ship something with it, and continue to build without wondering whether we're going to change the entire way your application works. - + -Getting here took longer than I thought it would (if you read our RC announcement, I was expecting a pretty short stretch of polish), and looking back through what actually landed after that, calling all of it polish would be underselling a lot of people's work. +Sure, getting here took longer than I thought it would. If you read our RC announcement, we were expecting a pretty short stretch of polish, and looking back through what actually landed after that, calling all of it polish would be underselling a lot of people's work. ## Start started with a router -Start wasn't actually where this started, I was trying to build the router I wanted to use, and I wanted my routes to know which paths existed, which parameters they needed, what my search parameters looked like, what data a loader returned, and what context was available further down the route tree, so when I changed something, my editor could tell me what else needed to change. That sounds pretty reasonable now, but there was a lot of skepticism around it. Some people didn't think that level of type safety was possible, some didn't think it mattered, and some thought it was an awful lot of work for a router (and a few years earlier, I probably would have agreed with them). +Oddly enough, Start is not where this journey actually started (no pun intended). I was trying to build the router I wanted to use, and I wanted my routes to know which paths existed, which parameters they needed, which search parameters were valid and what they looked like, what loader data returned, and even what context was available all through the route tree. I wanted to know that when I changed something, my editor could tell me exactly what else needed to change and catch the type errors that came with it. That sounds pretty reasonable now, but you've got to remember that there was a ton of skepticism around that entire idea. Back when I was writing Router, or even just researching it, a lot of people didn't think that level of type safety was possible. Some didn't even think it mattered, and there were a few who thought it was just way too much work for a router. To be honest, a few years earlier I would've agreed with them. -I used to think TypeScript was mostly extra work. I already knew what my code did, why did I need to explain it to something else? Working on React Query, and learning from the people helping move it to TypeScript, changed that for me. Eventually I started seeing types as something I could design with, something that could make an API easier to use in the first place, and once that clicked, it was hard to stop noticing all the places where we were asking developers to remember things the tools could already know. Building a router around that was a pretty big investment, I was betting on something people were telling me wasn't important or wasn't even possible, and I didn't know yet that I was also building the foundation for a full-stack framework. +Believe it or not, I used to think TypeScript was unnecessary, mostly extra work. I already knew what my code did, so why did I need to explain it to something else? Working on React Query over the years and learning from people who helped move it to TypeScript changed that for me entirely. Eventually I started seeing types as something that I could and should design with, something that could make an API easier to use in the first place. And once all that clicked, it was really difficult to stop noticing all these places where we were asking developers to remember things that tools should just already know. Building a router around TypeScript was a massive investment, I was betting on something people were telling me wasn't important or wasn't possible, and I didn't even know yet that I was also building the foundation for a full-stack framework, on principles that would help us in the age of AI too. -By December 2023, there's already work in the repo on the server utilities that would become part of Start, and in May 2024, there's a commit where I renamed `react-router-server` to `start`, complete with a goofy emoji (very official framework naming process). +By around December 2023, there was already work in the repo on server utilities that would become the very first beginnings of Start. Then by May 2024, I made a commit where I renamed the `react-router-server` package to `start`, complete with a goofy emoji, which is the very official framework naming process. ## I wanted another option -Around that time, I felt like the React ecosystem was narrowing its idea of what an application should look like, Next was making a very big bet on React Server Components and a more server-oriented model, React Router and Remix were working through their own changes, and there were interesting ideas in all of it, but I wasn't comfortable with how often the conversation seemed to land on one answer for everybody. +It was around that time I felt like the React ecosystem was really constraining its idea of what an application should look like. Next.js was making a very big bet on React Server Components, as a framework primitive and an ideology, and moving more and more toward a server-oriented model. React Router and Remix were working through their own changes. There were interesting ideas in all of this, but I wasn't really comfortable with how the conversation seemed to land on one answer for everybody. -I wanted to keep building the kinds of applications I already knew how to build, with state, client-side navigation, data caches, and all the things that have made SPA development such a productive way to work, and I also wanted server rendering, streaming, server functions, and the ability to put work on the server when that was the right place for it, and I didn't want adding those things to mean relearning my entire application. +I wanted to keep building the kinds of apps I already knew how to build, the same kinds of apps I'd been building for the last ten years. State management, client-side navigation, data caching, and in my opinion, all the things that have made SPA development the most productive way to work. But I also wanted all the new things. I wanted server rendering, streaming, server functions, the ability to just put work on the server when I knew that was the right place for it, without having to change everything about the way my app worked. I didn't want adding any of those things to mean relearning an entire application framework and structure. -That's still what I love about using Start, it feels familiar, your components are components, your routes are routes, and when you need the server, you have a pretty direct way to use it. There's a lot happening to make that easy, but I don't want you to have to keep a second explanation of your application in your head just to get through the day. And simple doesn't have to mean bare bones, I like conveniences and powerful APIs, and I want the common thing to be easy without running out of useful tools when your application gets complicated (which it probably will). +That's honestly still what I love about using Start. It feels familiar. My components are components, my routes are routes, and when I need the server, I have a very direct and explicit way to use it. There's a lot happening under the hood to make that easy, but we don't want you to have to keep a second explanation of your app in your head just to get through the day. Simple doesn't have to mean bare bones, I like conveniences and powerful APIs, I want the common thing to be as easy as possible without running out of useful tools when things get complicated (which they probably will, as most apps do). -A route can render normally on the server, load its data there without rendering its component, or render on the client. You can call a typed server function from a loader or an event handler. You can compose middleware around those calls, including work on the client and work on the server, with types carrying the context through, and those choices fit into the same application model, so you get to decide where the work belongs without giving up the routing and data tools you already understand. +With Start, a route can render on the server, load its data there without rendering the component, or render on the client. You can call a typed server function from a loader or an event handler and compose middleware around those calls, including work on the client and the server. It's full-stack middleware that can cross the client and server, with types carrying the context through. These choices fit into the same application model that so many of us have worked with over the last decade, and that so many companies have worked hard to adopt. You get to decide where work truly belongs without giving up the routing and data tools the ecosystem has grown to love, or the architecture that a ton of the interactive web has been built on. -I've borrowed ideas from pretty much every framework I've used (and I've tried a lot of them). React Router has done great work on primitives, Solid has been a huge inspiration on performance, and Next knows how to explain and market an idea. I've disagreed with directions those projects have taken, sometimes pretty loudly, but there's a lot of good work there that has influenced mine. +Start definitely wasn't the first framework to have a lot of these ideas. Many are borrowed from other frameworks we've used, and I've tried a lot of them. React Router has great primitive design, SolidJS has been a massive inspiration on full-stack APIs and performance, and Next.js really knows how to explain and market an idea to the masses. I've disagreed with the direction of many projects over the years, sometimes pretty loudly, but just as they used the work that came before them for inspiration, so did we. ## Other people made it much better -Manuel and Flo took this so much further than I could have taken it on my own. I knew what I wanted Start to feel like to use, but that doesn't mean I knew how to build every part of it, and there are things in the framework today that are better than what I even knew to ask for. So when I look back at how long this took, I also look at what actually landed, the compiler work, streaming, server boundaries, hydration, all the combinations people found by putting it in real applications, and how much of that came from people other than me. +Manuel and Flo took this so much further than I could've taken it on my own. I knew what I wanted Start to feel like to use, but that doesn't necessarily mean I knew how to build every single part of it. There are things in the framework today that are better than what I even knew to ask for. So when I look back at how long this took, I also look at what actually got committed, the compiler work, streaming, server boundaries, hydration, all the combinations people found by putting it into real apps, and how much of that came from people other than me. -The [SSR performance work](https://tanstack.com/blog/tanstack-start-5x-ssr-throughput) Manuel and Flo did is one of my favorite examples. They profiled what the server was doing and kept finding work it didn't need to do, eventually getting roughly 5.5x the throughput in their benchmark. That's their benchmark, your application is going to have its own workload, but I love that we got there by going back through the implementation and understanding it better. There's a lot more of that work in this release than you can fit into an announcement, regression tests, benchmarks, allocations we don't need anymore, compiler bugs caught before they reach somebody's app. Those are things I want us spending time on when people are trusting us with their framework. +The [SSR performance work](https://tanstack.com/blog/tanstack-start-5x-ssr-throughput) Manuel and Flo did is one of my favorite examples. They profiled what the server was doing and kept finding work it didn't need to do, eventually getting roughly five and a half times the throughput in their benchmark. And there's so much work that you can't fit into this announcement around regression tests, benchmarks, allocations we don't need anymore, or compiler bugs caught before they reach somebody's app. That's stuff I'm not sure I would've had the attention or the time to invest in. People say the last ten percent takes the longest and is the hardest, and that's definitely true here, I wouldn't have gotten through that last ten percent without Manuel and Flo. So much of the trust people can put in this framework comes down to the work those guys did. ## Freedom takes work -I've spent years on framework agnosticism across TanStack, well before Start, because I don't want all the useful work in a library to come and go with whatever UI framework happens to be popular around it. And I want to treat those other frameworks as real options, which means actually designing for them and finding out where we've made assumptions. Supporting Solid will teach you pretty quickly which parts of your supposedly agnostic code are still thinking in React. We went through something similar [adding Rsbuild](https://tanstack.com/blog/start-adds-rsbuild-support), with assumptions about the build tool that had worked their way into the framework. +I've spent years on framework agnosticism across TanStack, well before Start, because I don't want all the useful work you build into a library to have to be rewritten or go by the wayside whenever a new UI framework happens to be popular. I want to treat those other frameworks as real options, which means actually designing for them and finding out where we've made assumptions. Supporting Solid will teach you pretty quickly which parts of your supposedly agnostic code are still thinking in React. We went through something similar [adding Rsbuild support](https://tanstack.com/blog/start-adds-rsbuild-support), with assumptions about the build tool that had worked their way into the core of the framework. Being able to make those choices now is pretty freaking awesome. -Hosting has been its own adventure. At one point I was pretty discouraged looking at the deployment adapters we'd have to maintain, and Ryan Carniato's advice was basically to use Vite and Nitro. That helped us [change direction](https://tanstack.com/blog/why-tanstack-start-is-ditching-adapters), and I'm glad we listened, I want us spending our time making Start better, and I want you to be able to choose where you run it without that choice taking over how you build your app. + + +Hosting has been its own crazy adventure. At one point I was pretty discouraged looking at all the deployment adapters we'd have to maintain. I remember Ryan Carniato's advice was basically to use Vite and Nitro, and that helped us [change direction early on](https://tanstack.com/blog/why-tanstack-start-is-ditching-adapters). I'm really glad we listened, I wanted to spend our time making Start better instead of rebuilding deployment adapters and maintaining them for eternity. I wanted people to be able to choose where to run it without having that choice take over how they build their application. And even though we support Rsbuild too, my hat's off to Vite for the work they've done to make that separation possible. ## Yes, we spent a lot of time on RSC -For a while, supporting React Server Components felt like a box we had to check to be taken seriously as a React framework. We spent a lot of time on it, and some really good work came out of that. Manuel in particular put a huge amount into figuring out how RSC could fit into Start without taking ownership of the entire application model. We wrote about [that approach](https://tanstack.com/blog/react-server-components), and about [who owns the component tree](https://tanstack.com/blog/who-owns-the-tree), because those decisions matter beyond whether a feature appears in a comparison table. +For a while, supporting React Server Components felt like this box we had to check to be taken seriously as a React framework, and I'm not going to lie, that's pretty frustrating. I think a lot of that came from the marketing around RSC, both from Next.js and from the React team themselves. It was propped up as the answer to so many things in the React ecosystem, and in my opinion it got a little too much fuel behind it for the distance you could actually get out of it. Regardless, we decided to spend time on it. A lot of time. And some really good work came out of that, Manuel in particular put a huge amount of work into figuring out how RSC could fit into Start without taking ownership of the entire application model. + +We wrote about [our approach](https://tanstack.com/blog/react-server-components) and [who owns the component tree](https://tanstack.com/blog/who-owns-the-tree), because after understanding how RSC fits into something that isn't Next.js, the questions around composition and which side owns the tree mattered a lot more than checking a feature off in a comparison table. I'm happy we could build that integration without changing Start's underlying application model or making its core depend on React. + + -We also used RSC on tanstack.com, got real value out of it, and then [stopped using it](https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com) when changes to our Markdown and highlighting code made the tradeoff different. I'm glad we could do that, we learned something, our needs changed, and we changed the implementation, which is the kind of freedom I want you to have with your own application, too. +At the same time, I've been disappointed with parts of the experience of using RSC. I was really excited to use it on tanstack.com, I knew we could get value out of keeping logic on the server instead of shipping it to the client. But understanding exactly what we were shipping where became this long, arduous process, and I could see the fingerprints of RSC throughout our codebase making things more complicated to reason about than I wanted, for us and for our AI models. Ultimately I decided to [stop using it on tanstack.com](https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com). Which is funny, because changes to how we did Markdown and highlighting were enough to make the tradeoff favor removing it. + +AI has changed how I approach that work too, including being able to build Markdown and highlighting libraries that do exactly what we need on the front end, instead of having to work around the cost of shipping other libraries to the client. I'm glad we went through that process, and taking RSC out didn't mean rewriting our application. We could choose to put it back if our needs changed again. That's the kind of freedom I wanted, even something as complex and unique as RSC could be something we opted into and out of without it deciding how the rest of our app had to work. ## Then agents showed up -I think it was around November of 2025 when AI started noticeably changing the work around Start, and by the middle of 2026 we were dealing with it everywhere. The volume of PRs and issues went up, a lot of it was drive-by stuff, generated content that someone hadn't really read or understood before sending it to us, and that takes time away from the people actually doing the work. Security has changed along with it. People are using AI to actively look for vulnerabilities, we're using it ourselves and with partners to find and fix problems, and that's becoming a normal part of maintaining this thing. It has to be. +I'm pretty sure it was around November of 2025 when AI started noticeably changing how we worked on Start, and by early 2026 it felt like we were dealing with it everywhere. We'd begun using it to look for performance improvements and security issues, and the volume of pull requests and issues coming into Start and Router started to skyrocket. A lot of it was drive-by stuff, generated content somebody hadn't really read or understood before sending it to us, and honestly that's frustrating because it takes so much time away from the people doing the work. I'd be sugarcoating it to say we've figured out how to manage all of that. There are still a lot of problems to work through, we're doing our best to mitigate them, and I am optimistic that it's going to get better and easier. + + -But I've also been using agents to build, and watching other people use them to build with Start, and I keep coming back to the router. All that work to make the types strict, to make the APIs explicit, to give you as much freedom as possible while still being able to tell you when something doesn't fit, we did that for people. I wanted you to be able to move things around and try things and have your editor help you, without having to remember every connection in your application. An agent needs a lot of that same help, it changes a route parameter or the input to a server function and now it can find the places that no longer agree with it, and the more complicated the application gets, the more I want that feedback. It doesn't tell you whether you've built the right thing, you still have to do that part, but it gives you a way to keep making changes without guessing about all of those connections. We didn't have to redesign Router and Start around agents to get there (the design was deliberate, having it line up this well with how people are building now was a pretty happy coincidence). +Security changed really early on. People are using AI to actively look for vulnerabilities, and we're using it ourselves and with our partners to find and fix problems proactively. It's surprising how quickly that became a normal part of open source maintenance, but it has to be at this point, and I'm really grateful to our partners for helping us with it. Security is never done. I'm sure we'll have our share of security adventures in the future, but knowing the team and our partners keep working on it, with and without AI, gives me a lot of confidence in how we'll handle them. -We did have a lot to teach them, though. Sarah Gerrard and Kyle Mathews helped bring [TanStack Intent](https://tanstack.com/blog/from-docs-to-agents) into the picture, and we made a big push across TanStack to get that guidance into the packages, with a lot of it anchored around how agents use Start and Router. I'm glad we invested in that too, because knowing an API exists and knowing how to use it well in somebody's application are different things. And now we have [tools for maintaining those skills](https://tanstack.com/blog/intent-0.5-skills-you-can-maintain), checking the examples and keeping the guidance connected to the code as it changes. +Beyond security, we've all been using agents to build and watching other people use them to build with Start, and so much of it brings me back to Router. All the work we did to make it type-safe and strict, and to make the APIs explicit, was about giving you as much freedom as possible while still being able to tell you when something isn't right or doesn't fit. We originally did that for people. I wanted you to be able to move things around in your editor and try things and have your editor help you, without remembering every connection in your application. An agent needs a lot of that same help, you can ask for almost anything, and it'll go change a route parameter or the input to a server function, and then it needs help finding the places that no longer agree with that change. + +Models are great and they're getting better. Maybe someday TypeScript won't be necessary for that feedback, but for now, with the size of applications people are building on Start, the more complicated they get, the more agents benefit from it. The types can't tell you whether you've built the right thing, you still have to do that part, but they can help keep the changes sane. We didn't have to redesign Router or Start around agents to get there, the design for type safety and explicitness was absolutely deliberate. The timing with agentic development was a happy coincidence, but I'm not going to say we just got extremely lucky, these were problems worth worrying about before AI. Humans and agents run into a lot of the same problems, just on a different scale. + +Type safety can't solve everything, though. We did have to teach agents how to use Start and Router. Sarah Gerrard and Kyle Mathews helped bring [TanStack Intent](https://tanstack.com/blog/from-docs-to-agents) into the picture, and we made a massive push across TanStack to get guidance in the form of skills right into our npm packages, with a lot of it anchored around Start and Router. Knowing an API exists and knowing the best practices around it are very different things, and that's something I don't want to rely on training data for. Now we also have [tools for maintaining those skills](https://tanstack.com/blog/intent-0.5-skills-you-can-maintain), checking the examples and keeping that guidance connected to changes in the code. I think there's a lot more we can do to give agents assurances about what they're building, but we'll leave that for another day. ## People started betting on it -Lovable really surprised us. They were going to use Start for the applications their product generates, which is a very different conversation from somebody trying it on a side project, because you're choosing a foundation for things other people are going to build (including things you haven't seen yet). [Lovable began generating new projects with Start in May 2026](https://lovable.dev/blog/building-apps-using-tanstack-start), and their explanation connects a lot of what we've been working toward: server rendering, portability, and types that help generated code fit together. +There have been so many companies and partners willing to take a chance on Start early on. Convex supported it when it was extremely early, and I'm really grateful for that. Vercel took an early bet on us too and was part of the support that helped me go full-time on TanStack, and I'm really happy to have them back as a partner. AG Grid has been supporting our work for years. Clerk had a Start SDK in beta back in 2024, Netlify helped fund development and worked with us on deployment, and Cloudflare has been a massive part of making Start work well on Workers. + + -They weren't the first to take a chance on us. Convex supported Start when it was extremely early, and I'm still grateful for that. Vercel also supported us early on, and I'm really glad to have them back as a partner after some time away (that early support still means a lot to me). Clerk had a Start SDK in beta back in 2024. Netlify helped fund development and worked with us on deployment, and Cloudflare has been an important part of making Start work well on Workers. +Lovable really surprised me, though. When I heard they were going to use Start for the applications their product generates, that was a very different conversation from somebody trying it on a side project. They were choosing Start as the foundation for things other people were going to build, a lot of other people. [Lovable started generating new projects with Start in May 2026](https://lovable.dev/blog/building-apps-using-tanstack-start), and their explanation connects so much of what we've been working toward, server rendering, portability, type safety, the things that help generated code fit together. Their trust has been a significant part of helping Start become what it is today. -Since then we've seen people build integrations, publish examples, add deployment support, and choose Start for their own applications. WorkOS and Clerk help people bring authentication into their apps, Sentry has a dedicated SDK, and companies like Railway, Render, Vercel, and Cloudflare give people places to run what they build. Prisma has put work into getting people started with their data layer. +And there's so much work around the framework that makes it possible for people to actually choose it. WorkOS and Clerk help us understand how to make Start work well with authentication without building our own authentication. CodeRabbit helps review work in the repo, Railway and Render help people ship their applications, Sentry has a dedicated SDK, and Prisma has put work into getting people started with their data layer. People have built integrations, published examples, added deployment support, and chosen Start for their own applications, and I'm grateful for all of it. + + ## Come build something -If you've been waiting for 1.0, I'd love for you to give Start a try. Start with the [docs](https://tanstack.com/start/latest/docs/framework/react/overview). If you're moving an existing application, we have [migration guidance](https://tanstack.com/start/latest/docs/framework/react/migrate-from-next-js), and I would absolutely put an agent to work with you on that. In my experience, agents have become a really good way to work through a migration, especially when they have the current guidance and can use the types and tests to check the changes. +If you've been waiting for 1.0, we really want you to give Start a try. The [documentation](https://tanstack.com/start/latest/docs/framework/react/overview) is a great place to start, and if you're moving an existing application, we have [migration guidance](https://tanstack.com/start/latest/docs/framework/react/migrate-from-next-js). But honestly, I'd put an agent to work on it with you. In my experience they've become amazingly good at working through both new projects and migrations, especially when they have current guidance, TypeScript, and tests to check the changes. Try telling your agent to “use TanStack Start,” you'd be surprised how far that can get you. -I also want to thank Manuel Schiller and Florian Pellet, Brenley Dueck, Birk Skyum, Sean Cassiere, and the wider maintainer team, along with people like TkDodo and Edmund Hung, whose contributions show up in the foundations of this work. And thank you to Jack Herrington, Sarah Gerrard, Kyle Mathews, and Ryan Carniato for the ideas, tooling, explanations, and advice that helped us get here. And to everyone who wrote a reproduction, answered somebody's question, made a tutorial, improved the docs, or patiently helped us understand what broke in their application, thank you, there's so much of that work in this release and most of it doesn't come with a name attached to a big feature. +I want to officially and publicly thank Manuel Schiller, Florian Pellet, Brenley Dueck, Birk Skyum, Sean Cassiere, the wider maintainer team, and everybody whose work shows up in the foundation of Start. I also want to thank Jack Herrington, Sarah Gerrard, Kyle Mathews, and Ryan Carniato for the ideas, tooling, explanations, and constant advice that helped us get here. And to everybody who wrote a reproduction, answered somebody's question, made a tutorial, improved the docs, or patiently helped us understand what broke in their application, thank you so much. There's tons of that work in this release, and most of it doesn't come with a name attached to a big feature. We owe so much of the polish and quality to that consistent stream of little things and the people who keep giving their support. -Thank you to our current partners for helping make this work possible. +A big thank you to all of our current partners for helping make this work possible. -And to our previous partners and sponsors, you're part of this history too (support doesn't stop mattering when a sponsorship ends). +And to our previous partners and sponsors, you've been part of the history of Start too, support doesn't stop mattering when a sponsorship ends. - + + +I started this because I wanted a better way to build my own apps and I didn't want to compromise. Somewhere along the way, a whole lot of other people decided they wanted to help build it with me and turned it into something bigger and better than I could've done on my own. And now I'm excited to see what you can build with it. -I started this because I wanted a better way to build my own applications, and somewhere along the way, a whole lot of other people decided they wanted to help build it with me, and they turned it into something much better than I could have made on my own. I'm so excited to see what you build with it. +Happy building. diff --git a/src/components/PartnersGrid.tsx b/src/components/PartnersGrid.tsx index 08ff5ac5b..6bb7e8097 100644 --- a/src/components/PartnersGrid.tsx +++ b/src/components/PartnersGrid.tsx @@ -24,6 +24,7 @@ type PartnerItem = (typeof allPartners)[number] type PartnersGridProps = { analyticsPlacement?: PartnerPlacement partnersList?: PartnerItem[] + status?: PartnerItem['status'] /** * Optional final band rendered inside the same bordered container as the tier * bands — used to fold the OSS Sponsors band into the stack. @@ -157,10 +158,11 @@ function PartnerGridItem({ export function PartnersGrid({ analyticsPlacement = 'grid', partnersList, + status = 'active', trailingBand, }: PartnersGridProps) { const items = (partnersList ?? allPartners).filter( - (partner) => partner.status === 'active', + (partner) => partner.status === status, ) const placementContext = usePartnerPlacementContext({ diff --git a/src/components/markdown/PartnerList.tsx b/src/components/markdown/PartnerList.tsx index bf40bf084..ae926ebcd 100644 --- a/src/components/markdown/PartnerList.tsx +++ b/src/components/markdown/PartnerList.tsx @@ -1,50 +1,14 @@ -import { PartnerTierLogo } from '~/components/ds/ui/PartnerTierLogo' -import { partners, partnerTierLabels, type Partner } from '~/utils/partners' -import { getPartnerTierGroupsForPlacement } from '~/utils/partner-placement' -import { usePartnerPlacementContext } from '~/utils/usePartnerPlacementContext' +import { PartnersGrid } from '~/components/PartnersGrid' +import type { Partner } from '~/utils/partners' export function PartnerList({ status = 'active', }: { status?: Partner['status'] }) { - const context = usePartnerPlacementContext({ - orderStrategy: 'tier-rotated', - surface: `markdown-partners-${status}`, - }) - const groups = getPartnerTierGroupsForPlacement( - partners.filter((partner) => partner.status === status), - context, - ) - return ( -
- {groups.map((group) => ( -
-

- {status === 'inactive' ? 'Previous ' : ''} - {partnerTierLabels[group.tier]} partners -

-
- {group.partners.map((partner) => ( - - - - ))} -
-
- ))} +
+
) } From a294aa4585c9f550a836795306959f1da8171668 Mon Sep 17 00:00:00 2001 From: Tanner Linsley Date: Mon, 12 Oct 2026 10:43:38 -0600 Subject: [PATCH 3/6] Address announcement review with clearer pacing and API example --- src/blog/tanstack-start-1-0.md | 52 ++++++++++++++++++++++++++++------ 1 file changed, 43 insertions(+), 9 deletions(-) diff --git a/src/blog/tanstack-start-1-0.md b/src/blog/tanstack-start-1-0.md index 37b126b5e..7a4c2097b 100644 --- a/src/blog/tanstack-start-1-0.md +++ b/src/blog/tanstack-start-1-0.md @@ -2,7 +2,7 @@ title: TanStack Start 1.0 published: 2026-10-10 draft: true -excerpt: TanStack Start 1.0 is finally here, and this is the story of how we got here. +excerpt: TanStack Start 1.0 is stable and ready for production. authors: - Tanner Linsley library: start @@ -12,7 +12,9 @@ library: start TanStack Start 1.0 is finally stable. And we're really excited to officially call it ready for production. -I can't begin to say how proud I am of what we've built here and of the people who have built it. And I'm also really, really looking forward to not needing to remind everybody who's already using it in production that it's still a release candidate (that conversation has happened a lot more than you'd think). We've had tons of people put Start into production through pretty much every stage of its development, from small projects and startups to entire enterprise teams and Fortune 500 companies. To our surprise, so many of these companies insisted on using it even when it was in beta. We'd explain where things were, and they'd basically tell us we're going to use it anyway. +I can't begin to say how proud I am of what we've built here and of the people who have built it. And I'm also really, really looking forward to not needing to remind everybody who's already using it in production that it's still a release candidate (that conversation has happened a lot more than you'd think). + +We've had tons of people put Start into production through pretty much every stage of its development, from small projects and startups to entire enterprise teams and Fortune 500 companies. To our surprise, so many of these companies insisted on using it even when it was in beta. We'd explain where things were, and they'd basically tell us we're going to use it anyway. When enterprise teams are insisting on putting your beta software into production before it's even a release candidate, it's difficult to not feel the massive level of trust everybody is putting in you. So even though people have been successfully using Start in production for a long time, this is us making our formal commitment to the APIs we've built and the people building on them. You can now choose Start, learn it, ship something with it, and continue to build without wondering whether we're going to change the entire way your application works. @@ -22,9 +24,13 @@ Sure, getting here took longer than I thought it would. If you read our RC annou ## Start started with a router -Oddly enough, Start is not where this journey actually started (no pun intended). I was trying to build the router I wanted to use, and I wanted my routes to know which paths existed, which parameters they needed, which search parameters were valid and what they looked like, what loader data returned, and even what context was available all through the route tree. I wanted to know that when I changed something, my editor could tell me exactly what else needed to change and catch the type errors that came with it. That sounds pretty reasonable now, but you've got to remember that there was a ton of skepticism around that entire idea. Back when I was writing Router, or even just researching it, a lot of people didn't think that level of type safety was possible. Some didn't even think it mattered, and there were a few who thought it was just way too much work for a router. To be honest, a few years earlier I would've agreed with them. +Oddly enough, Start is not where this journey actually started (no pun intended). I was trying to build the router I wanted to use, and I wanted my routes to know which paths existed, which parameters they needed, which search parameters were valid and what they looked like, what loader data returned, and even what context was available all through the route tree. I wanted to know that when I changed something, my editor could tell me exactly what else needed to change and catch the type errors that came with it. + +That sounds pretty reasonable now, but you've got to remember that there was a ton of skepticism around that entire idea. Back when I was writing Router, or even just researching it, a lot of people didn't think that level of type safety was possible. Some didn't even think it mattered, and there were a few who thought it was just way too much work for a router. To be honest, a few years earlier I would've agreed with them. -Believe it or not, I used to think TypeScript was unnecessary, mostly extra work. I already knew what my code did, so why did I need to explain it to something else? Working on React Query over the years and learning from people who helped move it to TypeScript changed that for me entirely. Eventually I started seeing types as something that I could and should design with, something that could make an API easier to use in the first place. And once all that clicked, it was really difficult to stop noticing all these places where we were asking developers to remember things that tools should just already know. Building a router around TypeScript was a massive investment, I was betting on something people were telling me wasn't important or wasn't possible, and I didn't even know yet that I was also building the foundation for a full-stack framework, on principles that would help us in the age of AI too. +Believe it or not, I used to think TypeScript was unnecessary, mostly extra work. I already knew what my code did, so why did I need to explain it to something else? Working on React Query over the years and learning from people who helped move it to TypeScript changed that for me entirely. Eventually I started seeing types as something that I could and should design with, something that could make an API easier to use in the first place. And once all that clicked, it was really difficult to stop noticing all these places where we were asking developers to remember things that tools should just already know. + +Building a router around TypeScript was a massive investment, I was betting on something people were telling me wasn't important or wasn't possible, and I didn't even know yet that I was also building the foundation for a full-stack framework, on principles that would help us in the age of AI too. By around December 2023, there was already work in the repo on server utilities that would become the very first beginnings of Start. Then by May 2024, I made a commit where I renamed the `react-router-server` package to `start`, complete with a goofy emoji, which is the very official framework naming process. @@ -40,11 +46,33 @@ With Start, a route can render on the server, load its data there without render Start definitely wasn't the first framework to have a lot of these ideas. Many are borrowed from other frameworks we've used, and I've tried a lot of them. React Router has great primitive design, SolidJS has been a massive inspiration on full-stack APIs and performance, and Next.js really knows how to explain and market an idea to the masses. I've disagreed with the direction of many projects over the years, sometimes pretty loudly, but just as they used the work that came before them for inspiration, so did we. +## Choosing where the code runs + +One small example of what I mean by explicit APIs is `createIsomorphicFn`. Say you need the current origin to build an absolute URL. On the server that comes from the incoming request, in the browser it comes from `window.location`, and you can put those two implementations right next to each other. + +```tsx +import { createIsomorphicFn } from '@tanstack/react-start' +import { getRequest } from '@tanstack/react-start/server' + +const getOrigin = createIsomorphicFn() + .server(() => new URL(getRequest().url).origin) + .client(() => window.location.origin) + +// Call during a server request or in the browser. +const absoluteUrl = new URL('/about', getOrigin()).href +``` + +That's a simplified version of something we use on this website for social image URLs. The call stays the same, the implementation depends on where it's running, and Start removes the other environment's implementation from that bundle. Calling it in the browser doesn't make a request back to the server. When you do want a server call, that's what `createServerFn` is for. + +The [environment functions guide](https://tanstack.com/start/latest/docs/framework/react/guide/environment-functions) goes into the details. This is the kind of control I want when building an app, I can see where each piece runs without changing the rest of my code around it. + ## Other people made it much better Manuel and Flo took this so much further than I could've taken it on my own. I knew what I wanted Start to feel like to use, but that doesn't necessarily mean I knew how to build every single part of it. There are things in the framework today that are better than what I even knew to ask for. So when I look back at how long this took, I also look at what actually got committed, the compiler work, streaming, server boundaries, hydration, all the combinations people found by putting it into real apps, and how much of that came from people other than me. -The [SSR performance work](https://tanstack.com/blog/tanstack-start-5x-ssr-throughput) Manuel and Flo did is one of my favorite examples. They profiled what the server was doing and kept finding work it didn't need to do, eventually getting roughly five and a half times the throughput in their benchmark. And there's so much work that you can't fit into this announcement around regression tests, benchmarks, allocations we don't need anymore, or compiler bugs caught before they reach somebody's app. That's stuff I'm not sure I would've had the attention or the time to invest in. People say the last ten percent takes the longest and is the hardest, and that's definitely true here, I wouldn't have gotten through that last ten percent without Manuel and Flo. So much of the trust people can put in this framework comes down to the work those guys did. +The [SSR performance work](https://tanstack.com/blog/tanstack-start-5x-ssr-throughput) Manuel and Flo did is one of my favorite examples. They profiled what the server was doing and kept finding work it didn't need to do, eventually getting roughly five and a half times the throughput in their benchmark. + +And there's so much work that you can't fit into this announcement around regression tests, benchmarks, allocations we don't need anymore, or compiler bugs caught before they reach somebody's app. That's stuff I'm not sure I would've had the attention or the time to invest in. People say the last ten percent takes the longest and is the hardest, and that's definitely true here, I wouldn't have gotten through that last ten percent without Manuel and Flo. So much of the trust people can put in this framework comes down to the work those guys did. ## Freedom takes work @@ -74,9 +102,13 @@ I'm pretty sure it was around November of 2025 when AI started noticeably changi Security changed really early on. People are using AI to actively look for vulnerabilities, and we're using it ourselves and with our partners to find and fix problems proactively. It's surprising how quickly that became a normal part of open source maintenance, but it has to be at this point, and I'm really grateful to our partners for helping us with it. Security is never done. I'm sure we'll have our share of security adventures in the future, but knowing the team and our partners keep working on it, with and without AI, gives me a lot of confidence in how we'll handle them. -Beyond security, we've all been using agents to build and watching other people use them to build with Start, and so much of it brings me back to Router. All the work we did to make it type-safe and strict, and to make the APIs explicit, was about giving you as much freedom as possible while still being able to tell you when something isn't right or doesn't fit. We originally did that for people. I wanted you to be able to move things around in your editor and try things and have your editor help you, without remembering every connection in your application. An agent needs a lot of that same help, you can ask for almost anything, and it'll go change a route parameter or the input to a server function, and then it needs help finding the places that no longer agree with that change. +Beyond security, we've all been using agents to build and watching other people use them to build with Start, and so much of it brings me back to Router. All the work we did to make it type-safe and strict, and to make the APIs explicit, was about giving you as much freedom as possible while still being able to tell you when something isn't right or doesn't fit. We originally did that for people. I wanted you to be able to move things around in your editor and try things and have your editor help you, without remembering every connection in your application. -Models are great and they're getting better. Maybe someday TypeScript won't be necessary for that feedback, but for now, with the size of applications people are building on Start, the more complicated they get, the more agents benefit from it. The types can't tell you whether you've built the right thing, you still have to do that part, but they can help keep the changes sane. We didn't have to redesign Router or Start around agents to get there, the design for type safety and explicitness was absolutely deliberate. The timing with agentic development was a happy coincidence, but I'm not going to say we just got extremely lucky, these were problems worth worrying about before AI. Humans and agents run into a lot of the same problems, just on a different scale. +An agent needs a lot of that same help, you can ask for almost anything, and it'll go change a route parameter or the input to a server function, and then it needs help finding the places that no longer agree with that change. + +Models are great and they're getting better. Maybe someday TypeScript won't be necessary for that feedback, but for now, with the size of applications people are building on Start, the more complicated they get, the more agents benefit from it. The types can't tell you whether you've built the right thing, you still have to do that part, but they can help keep the changes sane. + +We didn't have to redesign Router or Start around agents to get there, the design for type safety and explicitness was absolutely deliberate. The timing with agentic development was a happy coincidence, but I'm not going to say we just got extremely lucky, these were problems worth worrying about before AI. Humans and agents run into a lot of the same problems, just on a different scale. Type safety can't solve everything, though. We did have to teach agents how to use Start and Router. Sarah Gerrard and Kyle Mathews helped bring [TanStack Intent](https://tanstack.com/blog/from-docs-to-agents) into the picture, and we made a massive push across TanStack to get guidance in the form of skills right into our npm packages, with a lot of it anchored around Start and Router. Knowing an API exists and knowing the best practices around it are very different things, and that's something I don't want to rely on training data for. Now we also have [tools for maintaining those skills](https://tanstack.com/blog/intent-0.5-skills-you-can-maintain), checking the examples and keeping that guidance connected to changes in the code. I think there's a lot more we can do to give agents assurances about what they're building, but we'll leave that for another day. @@ -96,13 +128,15 @@ And there's so much work around the framework that makes it possible for people If you've been waiting for 1.0, we really want you to give Start a try. The [documentation](https://tanstack.com/start/latest/docs/framework/react/overview) is a great place to start, and if you're moving an existing application, we have [migration guidance](https://tanstack.com/start/latest/docs/framework/react/migrate-from-next-js). But honestly, I'd put an agent to work on it with you. In my experience they've become amazingly good at working through both new projects and migrations, especially when they have current guidance, TypeScript, and tests to check the changes. Try telling your agent to “use TanStack Start,” you'd be surprised how far that can get you. -I want to officially and publicly thank Manuel Schiller, Florian Pellet, Brenley Dueck, Birk Skyum, Sean Cassiere, the wider maintainer team, and everybody whose work shows up in the foundation of Start. I also want to thank Jack Herrington, Sarah Gerrard, Kyle Mathews, and Ryan Carniato for the ideas, tooling, explanations, and constant advice that helped us get here. And to everybody who wrote a reproduction, answered somebody's question, made a tutorial, improved the docs, or patiently helped us understand what broke in their application, thank you so much. There's tons of that work in this release, and most of it doesn't come with a name attached to a big feature. We owe so much of the polish and quality to that consistent stream of little things and the people who keep giving their support. +I want to officially and publicly thank Manuel Schiller, Florian Pellet, Brenley Dueck, Birk Skyum, Sean Cassiere, the wider maintainer team, and everybody whose work shows up in the foundation of Start. I also want to thank Jack Herrington, Sarah Gerrard, Kyle Mathews, and Ryan Carniato for the ideas, tooling, explanations, and constant advice that helped us get here. + +And to everybody who wrote a reproduction, answered somebody's question, made a tutorial, improved the docs, or patiently helped us understand what broke in their application, thank you so much. There's tons of that work in this release, and most of it doesn't come with a name attached to a big feature. We owe so much of the polish and quality to that consistent stream of little things and the people who keep giving their support. A big thank you to all of our current partners for helping make this work possible. -And to our previous partners and sponsors, you've been part of the history of Start too, support doesn't stop mattering when a sponsorship ends. +And thank you to our previous partners and sponsors for helping us get Start to this point. From 71a49353aaf68aea22d9930cf24e2455592af530 Mon Sep 17 00:00:00 2001 From: Tanner Linsley Date: Mon, 12 Oct 2026 13:57:10 -0600 Subject: [PATCH 4/6] Clarify that the release candidate period has ended --- src/blog/tanstack-start-1-0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/blog/tanstack-start-1-0.md b/src/blog/tanstack-start-1-0.md index 7a4c2097b..1cdb56421 100644 --- a/src/blog/tanstack-start-1-0.md +++ b/src/blog/tanstack-start-1-0.md @@ -12,7 +12,7 @@ library: start TanStack Start 1.0 is finally stable. And we're really excited to officially call it ready for production. -I can't begin to say how proud I am of what we've built here and of the people who have built it. And I'm also really, really looking forward to not needing to remind everybody who's already using it in production that it's still a release candidate (that conversation has happened a lot more than you'd think). +I can't begin to say how proud I am of what we've built here and of the people who have built it. For a long time, I'd hear from people already running Start in production and have to remind them we were still in RC (that conversation happened a lot more than you'd think). I'm really glad we can finally drop that caveat. We've had tons of people put Start into production through pretty much every stage of its development, from small projects and startups to entire enterprise teams and Fortune 500 companies. To our surprise, so many of these companies insisted on using it even when it was in beta. We'd explain where things were, and they'd basically tell us we're going to use it anyway. From 458beb6d31fe11fa20d43b700d04a8b00c429e03 Mon Sep 17 00:00:00 2001 From: Tanner Linsley Date: Mon, 12 Oct 2026 15:20:59 -0600 Subject: [PATCH 5/6] Recognize partner contributions by tier and link announcement references --- src/blog/tanstack-start-1-0.md | 44 +++---- src/components/markdown/Markdown.tsx | 2 + .../markdown/StartPartnerContributions.tsx | 120 ++++++++++++++++++ src/utils/markdown-partner-lists.ts | 2 +- tests/markdown-partner-lists.test.ts | 7 +- 5 files changed, 149 insertions(+), 26 deletions(-) create mode 100644 src/components/markdown/StartPartnerContributions.tsx diff --git a/src/blog/tanstack-start-1-0.md b/src/blog/tanstack-start-1-0.md index 1cdb56421..994084348 100644 --- a/src/blog/tanstack-start-1-0.md +++ b/src/blog/tanstack-start-1-0.md @@ -20,15 +20,15 @@ When enterprise teams are insisting on putting your beta software into productio -Sure, getting here took longer than I thought it would. If you read our RC announcement, we were expecting a pretty short stretch of polish, and looking back through what actually landed after that, calling all of it polish would be underselling a lot of people's work. +Sure, getting here took longer than I thought it would. If you read our [RC announcement](https://tanstack.com/blog/announcing-tanstack-start-v1), we were expecting a pretty short stretch of polish, and looking back through what actually landed after that, calling all of it polish would be underselling a lot of people's work. ## Start started with a router Oddly enough, Start is not where this journey actually started (no pun intended). I was trying to build the router I wanted to use, and I wanted my routes to know which paths existed, which parameters they needed, which search parameters were valid and what they looked like, what loader data returned, and even what context was available all through the route tree. I wanted to know that when I changed something, my editor could tell me exactly what else needed to change and catch the type errors that came with it. -That sounds pretty reasonable now, but you've got to remember that there was a ton of skepticism around that entire idea. Back when I was writing Router, or even just researching it, a lot of people didn't think that level of type safety was possible. Some didn't even think it mattered, and there were a few who thought it was just way too much work for a router. To be honest, a few years earlier I would've agreed with them. +That sounds pretty reasonable now, but you've got to remember that there was a ton of skepticism around that entire idea. Back when I was writing [Router](https://tanstack.com/router), or even just researching it, a lot of people didn't think that level of type safety was possible. Some didn't even think it mattered, and there were a few who thought it was just way too much work for a router. To be honest, a few years earlier I would've agreed with them. -Believe it or not, I used to think TypeScript was unnecessary, mostly extra work. I already knew what my code did, so why did I need to explain it to something else? Working on React Query over the years and learning from people who helped move it to TypeScript changed that for me entirely. Eventually I started seeing types as something that I could and should design with, something that could make an API easier to use in the first place. And once all that clicked, it was really difficult to stop noticing all these places where we were asking developers to remember things that tools should just already know. +Believe it or not, I used to think [TypeScript](https://www.typescriptlang.org/) was unnecessary, mostly extra work. I already knew what my code did, so why did I need to explain it to something else? Working on [React Query](https://tanstack.com/query) over the years and learning from people who helped move it to TypeScript changed that for me entirely. Eventually I started seeing types as something that I could and should design with, something that could make an API easier to use in the first place. And once all that clicked, it was really difficult to stop noticing all these places where we were asking developers to remember things that tools should just already know. Building a router around TypeScript was a massive investment, I was betting on something people were telling me wasn't important or wasn't possible, and I didn't even know yet that I was also building the foundation for a full-stack framework, on principles that would help us in the age of AI too. @@ -36,19 +36,19 @@ By around December 2023, there was already work in the repo on server utilities ## I wanted another option -It was around that time I felt like the React ecosystem was really constraining its idea of what an application should look like. Next.js was making a very big bet on React Server Components, as a framework primitive and an ideology, and moving more and more toward a server-oriented model. React Router and Remix were working through their own changes. There were interesting ideas in all of this, but I wasn't really comfortable with how the conversation seemed to land on one answer for everybody. +It was around that time I felt like the React ecosystem was really constraining its idea of what an application should look like. [Next.js](https://nextjs.org/) was making a very big bet on [React Server Components](https://react.dev/reference/rsc/server-components), as a framework primitive and an ideology, and moving more and more toward a server-oriented model. [React Router](https://reactrouter.com/) and [Remix](https://remix.run/) were working through their own changes. There were interesting ideas in all of this, but I wasn't really comfortable with how the conversation seemed to land on one answer for everybody. I wanted to keep building the kinds of apps I already knew how to build, the same kinds of apps I'd been building for the last ten years. State management, client-side navigation, data caching, and in my opinion, all the things that have made SPA development the most productive way to work. But I also wanted all the new things. I wanted server rendering, streaming, server functions, the ability to just put work on the server when I knew that was the right place for it, without having to change everything about the way my app worked. I didn't want adding any of those things to mean relearning an entire application framework and structure. That's honestly still what I love about using Start. It feels familiar. My components are components, my routes are routes, and when I need the server, I have a very direct and explicit way to use it. There's a lot happening under the hood to make that easy, but we don't want you to have to keep a second explanation of your app in your head just to get through the day. Simple doesn't have to mean bare bones, I like conveniences and powerful APIs, I want the common thing to be as easy as possible without running out of useful tools when things get complicated (which they probably will, as most apps do). -With Start, a route can render on the server, load its data there without rendering the component, or render on the client. You can call a typed server function from a loader or an event handler and compose middleware around those calls, including work on the client and the server. It's full-stack middleware that can cross the client and server, with types carrying the context through. These choices fit into the same application model that so many of us have worked with over the last decade, and that so many companies have worked hard to adopt. You get to decide where work truly belongs without giving up the routing and data tools the ecosystem has grown to love, or the architecture that a ton of the interactive web has been built on. +With Start, a route can [render on the server, load its data there without rendering the component, or render on the client](https://tanstack.com/start/latest/docs/framework/react/guide/selective-ssr). You can call a [typed server function](https://tanstack.com/start/latest/docs/framework/react/guide/server-functions) from a loader or an event handler and [compose middleware](https://tanstack.com/start/latest/docs/framework/react/guide/middleware) around those calls, including work on the client and the server. It's full-stack middleware that can cross the client and server, with types carrying the context through. These choices fit into the same application model that so many of us have worked with over the last decade, and that so many companies have worked hard to adopt. You get to decide where work truly belongs without giving up the routing and data tools the ecosystem has grown to love, or the architecture that a ton of the interactive web has been built on. -Start definitely wasn't the first framework to have a lot of these ideas. Many are borrowed from other frameworks we've used, and I've tried a lot of them. React Router has great primitive design, SolidJS has been a massive inspiration on full-stack APIs and performance, and Next.js really knows how to explain and market an idea to the masses. I've disagreed with the direction of many projects over the years, sometimes pretty loudly, but just as they used the work that came before them for inspiration, so did we. +Start definitely wasn't the first framework to have a lot of these ideas. Many are borrowed from other frameworks we've used, and I've tried a lot of them. React Router has great primitive design, [SolidJS](https://www.solidjs.com/) has been a massive inspiration on full-stack APIs and performance, and Next.js really knows how to explain and market an idea to the masses. I've disagreed with the direction of many projects over the years, sometimes pretty loudly, but just as they used the work that came before them for inspiration, so did we. ## Choosing where the code runs -One small example of what I mean by explicit APIs is `createIsomorphicFn`. Say you need the current origin to build an absolute URL. On the server that comes from the incoming request, in the browser it comes from `window.location`, and you can put those two implementations right next to each other. +One small example of what I mean by explicit APIs is [`createIsomorphicFn`](https://tanstack.com/start/latest/docs/framework/react/guide/environment-functions). Say you need the current origin to build an absolute URL. On the server that comes from the incoming request, in the browser it comes from `window.location`, and you can put those two implementations right next to each other. ```tsx import { createIsomorphicFn } from '@tanstack/react-start' @@ -62,29 +62,29 @@ const getOrigin = createIsomorphicFn() const absoluteUrl = new URL('/about', getOrigin()).href ``` -That's a simplified version of something we use on this website for social image URLs. The call stays the same, the implementation depends on where it's running, and Start removes the other environment's implementation from that bundle. Calling it in the browser doesn't make a request back to the server. When you do want a server call, that's what `createServerFn` is for. +That's a simplified version of something we use on this website for social image URLs. The call stays the same, the implementation depends on where it's running, and Start removes the other environment's implementation from that bundle. Calling it in the browser doesn't make a request back to the server. When you do want a server call, that's what [`createServerFn`](https://tanstack.com/start/latest/docs/framework/react/guide/server-functions) is for. The [environment functions guide](https://tanstack.com/start/latest/docs/framework/react/guide/environment-functions) goes into the details. This is the kind of control I want when building an app, I can see where each piece runs without changing the rest of my code around it. ## Other people made it much better -Manuel and Flo took this so much further than I could've taken it on my own. I knew what I wanted Start to feel like to use, but that doesn't necessarily mean I knew how to build every single part of it. There are things in the framework today that are better than what I even knew to ask for. So when I look back at how long this took, I also look at what actually got committed, the compiler work, streaming, server boundaries, hydration, all the combinations people found by putting it into real apps, and how much of that came from people other than me. +[Manuel](https://github.com/schiller-manuel) and [Flo](https://github.com/sheraff) took this so much further than I could've taken it on my own. I knew what I wanted Start to feel like to use, but that doesn't necessarily mean I knew how to build every single part of it. There are things in the framework today that are better than what I even knew to ask for. So when I look back at how long this took, I also look at what actually got committed, the compiler work, streaming, server boundaries, hydration, all the combinations people found by putting it into real apps, and how much of that came from people other than me. -The [SSR performance work](https://tanstack.com/blog/tanstack-start-5x-ssr-throughput) Manuel and Flo did is one of my favorite examples. They profiled what the server was doing and kept finding work it didn't need to do, eventually getting roughly five and a half times the throughput in their benchmark. +The [SSR performance work](https://tanstack.com/blog/tanstack-start-5x-ssr-throughput) [Manuel](https://github.com/schiller-manuel) and [Flo](https://github.com/sheraff) did is one of my favorite examples. They profiled what the server was doing and kept finding work it didn't need to do, eventually getting roughly five and a half times the throughput in their benchmark. -And there's so much work that you can't fit into this announcement around regression tests, benchmarks, allocations we don't need anymore, or compiler bugs caught before they reach somebody's app. That's stuff I'm not sure I would've had the attention or the time to invest in. People say the last ten percent takes the longest and is the hardest, and that's definitely true here, I wouldn't have gotten through that last ten percent without Manuel and Flo. So much of the trust people can put in this framework comes down to the work those guys did. +And there's so much work that you can't fit into this announcement around regression tests, benchmarks, allocations we don't need anymore, or compiler bugs caught before they reach somebody's app. That's stuff I'm not sure I would've had the attention or the time to invest in. People say the last ten percent takes the longest and is the hardest, and that's definitely true here, I wouldn't have gotten through that last ten percent without [Manuel](https://github.com/schiller-manuel) and [Flo](https://github.com/sheraff). So much of the trust people can put in this framework comes down to the work those guys did. ## Freedom takes work -I've spent years on framework agnosticism across TanStack, well before Start, because I don't want all the useful work you build into a library to have to be rewritten or go by the wayside whenever a new UI framework happens to be popular. I want to treat those other frameworks as real options, which means actually designing for them and finding out where we've made assumptions. Supporting Solid will teach you pretty quickly which parts of your supposedly agnostic code are still thinking in React. We went through something similar [adding Rsbuild support](https://tanstack.com/blog/start-adds-rsbuild-support), with assumptions about the build tool that had worked their way into the core of the framework. Being able to make those choices now is pretty freaking awesome. +I've spent years on framework agnosticism across TanStack, well before Start, because I don't want all the useful work you build into a library to have to be rewritten or go by the wayside whenever a new UI framework happens to be popular. I want to treat those other frameworks as real options, which means actually designing for them and finding out where we've made assumptions. Supporting [Solid](https://www.solidjs.com/) will teach you pretty quickly which parts of your supposedly agnostic code are still thinking in React. We went through something similar [adding Rsbuild support](https://tanstack.com/blog/start-adds-rsbuild-support), with assumptions about the build tool that had worked their way into the core of the framework. Being able to make those choices now is pretty freaking awesome. -Hosting has been its own crazy adventure. At one point I was pretty discouraged looking at all the deployment adapters we'd have to maintain. I remember Ryan Carniato's advice was basically to use Vite and Nitro, and that helped us [change direction early on](https://tanstack.com/blog/why-tanstack-start-is-ditching-adapters). I'm really glad we listened, I wanted to spend our time making Start better instead of rebuilding deployment adapters and maintaining them for eternity. I wanted people to be able to choose where to run it without having that choice take over how they build their application. And even though we support Rsbuild too, my hat's off to Vite for the work they've done to make that separation possible. +Hosting has been its own crazy adventure. At one point I was pretty discouraged looking at all the deployment adapters we'd have to maintain. I remember [Ryan Carniato](https://github.com/ryansolid)'s advice was basically to use [Vite](https://vite.dev/) and [Nitro](https://nitro.build/), and that helped us [change direction early on](https://tanstack.com/blog/why-tanstack-start-is-ditching-adapters). I'm really glad we listened, I wanted to spend our time making Start better instead of rebuilding deployment adapters and maintaining them for eternity. I wanted people to be able to choose where to run it without having that choice take over how they build their application. And even though we support [Rsbuild](https://rsbuild.dev/) too, my hat's off to Vite for the work they've done to make that separation possible. ## Yes, we spent a lot of time on RSC -For a while, supporting React Server Components felt like this box we had to check to be taken seriously as a React framework, and I'm not going to lie, that's pretty frustrating. I think a lot of that came from the marketing around RSC, both from Next.js and from the React team themselves. It was propped up as the answer to so many things in the React ecosystem, and in my opinion it got a little too much fuel behind it for the distance you could actually get out of it. Regardless, we decided to spend time on it. A lot of time. And some really good work came out of that, Manuel in particular put a huge amount of work into figuring out how RSC could fit into Start without taking ownership of the entire application model. +For a while, supporting React Server Components felt like this box we had to check to be taken seriously as a React framework, and I'm not going to lie, that's pretty frustrating. I think a lot of that came from the marketing around RSC, both from Next.js and from the React team themselves. It was propped up as the answer to so many things in the React ecosystem, and in my opinion it got a little too much fuel behind it for the distance you could actually get out of it. Regardless, we decided to spend time on it. A lot of time. And some really good work came out of that, [Manuel](https://github.com/schiller-manuel) in particular put a huge amount of work into figuring out how RSC could fit into Start without taking ownership of the entire application model. We wrote about [our approach](https://tanstack.com/blog/react-server-components) and [who owns the component tree](https://tanstack.com/blog/who-owns-the-tree), because after understanding how RSC fits into something that isn't Next.js, the questions around composition and which side owns the tree mattered a lot more than checking a feature off in a comparison table. I'm happy we could build that integration without changing Start's underlying application model or making its core depend on React. @@ -92,7 +92,7 @@ We wrote about [our approach](https://tanstack.com/blog/react-server-components) At the same time, I've been disappointed with parts of the experience of using RSC. I was really excited to use it on tanstack.com, I knew we could get value out of keeping logic on the server instead of shipping it to the client. But understanding exactly what we were shipping where became this long, arduous process, and I could see the fingerprints of RSC throughout our codebase making things more complicated to reason about than I wanted, for us and for our AI models. Ultimately I decided to [stop using it on tanstack.com](https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com). Which is funny, because changes to how we did Markdown and highlighting were enough to make the tradeoff favor removing it. -AI has changed how I approach that work too, including being able to build Markdown and highlighting libraries that do exactly what we need on the front end, instead of having to work around the cost of shipping other libraries to the client. I'm glad we went through that process, and taking RSC out didn't mean rewriting our application. We could choose to put it back if our needs changed again. That's the kind of freedom I wanted, even something as complex and unique as RSC could be something we opted into and out of without it deciding how the rest of our app had to work. +AI has changed how I approach that work too, including being able to build [Markdown and highlighting libraries](https://tanstack.com/blog/introducing-tanstack-markdown-and-highlight) that do exactly what we need on the front end, instead of having to work around the cost of shipping other libraries to the client. I'm glad we went through that process, and taking RSC out didn't mean rewriting our application. We could choose to put it back if our needs changed again. That's the kind of freedom I wanted, even something as complex and unique as RSC could be something we opted into and out of without it deciding how the rest of our app had to work. ## Then agents showed up @@ -110,25 +110,25 @@ Models are great and they're getting better. Maybe someday TypeScript won't be n We didn't have to redesign Router or Start around agents to get there, the design for type safety and explicitness was absolutely deliberate. The timing with agentic development was a happy coincidence, but I'm not going to say we just got extremely lucky, these were problems worth worrying about before AI. Humans and agents run into a lot of the same problems, just on a different scale. -Type safety can't solve everything, though. We did have to teach agents how to use Start and Router. Sarah Gerrard and Kyle Mathews helped bring [TanStack Intent](https://tanstack.com/blog/from-docs-to-agents) into the picture, and we made a massive push across TanStack to get guidance in the form of skills right into our npm packages, with a lot of it anchored around Start and Router. Knowing an API exists and knowing the best practices around it are very different things, and that's something I don't want to rely on training data for. Now we also have [tools for maintaining those skills](https://tanstack.com/blog/intent-0.5-skills-you-can-maintain), checking the examples and keeping that guidance connected to changes in the code. I think there's a lot more we can do to give agents assurances about what they're building, but we'll leave that for another day. +Type safety can't solve everything, though. We did have to teach agents how to use Start and Router. [Sarah Gerrard](https://github.com/ladybluenotes) and [Kyle Mathews](https://github.com/KyleAMathews) helped bring [TanStack Intent](https://tanstack.com/blog/from-docs-to-agents) into the picture, and we made a massive push across TanStack to get guidance in the form of skills right into our npm packages, with a lot of it anchored around Start and Router. Knowing an API exists and knowing the best practices around it are very different things, and that's something I don't want to rely on training data for. Now we also have [tools for maintaining those skills](https://tanstack.com/blog/intent-0.5-skills-you-can-maintain), checking the examples and keeping that guidance connected to changes in the code. I think there's a lot more we can do to give agents assurances about what they're building, but we'll leave that for another day. ## People started betting on it -There have been so many companies and partners willing to take a chance on Start early on. Convex supported it when it was extremely early, and I'm really grateful for that. Vercel took an early bet on us too and was part of the support that helped me go full-time on TanStack, and I'm really happy to have them back as a partner. AG Grid has been supporting our work for years. Clerk had a Start SDK in beta back in 2024, Netlify helped fund development and worked with us on deployment, and Cloudflare has been a massive part of making Start work well on Workers. +One of the things that really surprised me was watching companies go from supporting Start to actually building on it. People were moving their own applications and websites over, and some were choosing it as the foundation for applications their customers would generate. That's a very different conversation from somebody trying it on a side project, because now they're trusting us with things other people are going to build, and we get to find out together what the framework needs to handle. - +Our partners have helped fund the time to do this work, reviewed code, worked with us on security and deployment, and helped us understand how Start needs to fit with authentication, monitoring, and data tools people already use. So much of making a framework useful comes down to that work around it. I didn't want choosing Start to mean giving up the rest of your stack, and getting there has taken a lot of people building integrations, publishing examples, and working through problems with us in real applications. -Lovable really surprised me, though. When I heard they were going to use Start for the applications their product generates, that was a very different conversation from somebody trying it on a side project. They were choosing Start as the foundation for things other people were going to build, a lot of other people. [Lovable started generating new projects with Start in May 2026](https://lovable.dev/blog/building-apps-using-tanstack-start), and their explanation connects so much of what we've been working toward, server rendering, portability, type safety, the things that help generated code fit together. Their trust has been a significant part of helping Start become what it is today. +Our partners have helped through integrations, examples, their own applications, and funding the work across TanStack. -And there's so much work around the framework that makes it possible for people to actually choose it. WorkOS and Clerk help us understand how to make Start work well with authentication without building our own authentication. CodeRabbit helps review work in the repo, Railway and Render help people ship their applications, Sentry has a dedicated SDK, and Prisma has put work into getting people started with their data layer. People have built integrations, published examples, added deployment support, and chosen Start for their own applications, and I'm grateful for all of it. + - +I'm really grateful to the people who took a chance on us early, including the partners and sponsors who helped us get here even if they're no longer sponsoring today. We were still figuring a lot of this out, and having people willing to invest their time, money, and their own applications in it gave us room to keep going and make it better. ## Come build something If you've been waiting for 1.0, we really want you to give Start a try. The [documentation](https://tanstack.com/start/latest/docs/framework/react/overview) is a great place to start, and if you're moving an existing application, we have [migration guidance](https://tanstack.com/start/latest/docs/framework/react/migrate-from-next-js). But honestly, I'd put an agent to work on it with you. In my experience they've become amazingly good at working through both new projects and migrations, especially when they have current guidance, TypeScript, and tests to check the changes. Try telling your agent to “use TanStack Start,” you'd be surprised how far that can get you. -I want to officially and publicly thank Manuel Schiller, Florian Pellet, Brenley Dueck, Birk Skyum, Sean Cassiere, the wider maintainer team, and everybody whose work shows up in the foundation of Start. I also want to thank Jack Herrington, Sarah Gerrard, Kyle Mathews, and Ryan Carniato for the ideas, tooling, explanations, and constant advice that helped us get here. +I want to officially and publicly thank [Manuel Schiller](https://github.com/schiller-manuel), [Florian Pellet](https://github.com/sheraff), [Brenley Dueck](https://github.com/brenelz), [Birk Skyum](https://github.com/birkskyum), [Sean Cassiere](https://github.com/seancassiere), the [wider maintainer team](https://tanstack.com/maintainers), and [everybody whose work shows up in the foundation of Start](https://github.com/TanStack/router/graphs/contributors). I also want to thank [Jack Herrington](https://github.com/jherr), [Sarah Gerrard](https://github.com/ladybluenotes), [Kyle Mathews](https://github.com/KyleAMathews), and [Ryan Carniato](https://github.com/ryansolid) for the ideas, tooling, explanations, and constant advice that helped us get here. And to everybody who wrote a reproduction, answered somebody's question, made a tutorial, improved the docs, or patiently helped us understand what broke in their application, thank you so much. There's tons of that work in this release, and most of it doesn't come with a name attached to a big feature. We owe so much of the polish and quality to that consistent stream of little things and the people who keep giving their support. diff --git a/src/components/markdown/Markdown.tsx b/src/components/markdown/Markdown.tsx index ea95e3713..a44bf211c 100644 --- a/src/components/markdown/Markdown.tsx +++ b/src/components/markdown/Markdown.tsx @@ -16,6 +16,7 @@ import { isSafeHttpUrl } from '~/utils/url-boundary' import { mapStartHostingPartnerElements } from '~/utils/start-hosting-guide' import { mapMarkdownPartnerLists } from '~/utils/markdown-partner-lists' import { PartnerList, PreviousPartnerList } from './PartnerList' +import { StartPartnerContributions } from './StartPartnerContributions' import { CodeBlock } from './CodeBlock' import { LiveExample } from './LiveExample' import { MarkdownLink } from './MarkdownLink' @@ -261,6 +262,7 @@ function createMarkdownComponents( 'md-live-example': LiveExample, 'md-tab-panel': MdTabPanel, pre: CodeBlock, + 'start-partner-contributions': StartPartnerContributions, 'partner-list': PartnerList, 'previous-partner-list': PreviousPartnerList, 'start-hosting-lovable-logo': StartHostingLovableLogo, diff --git a/src/components/markdown/StartPartnerContributions.tsx b/src/components/markdown/StartPartnerContributions.tsx new file mode 100644 index 000000000..6d6f9203d --- /dev/null +++ b/src/components/markdown/StartPartnerContributions.tsx @@ -0,0 +1,120 @@ +import { partners, partnerTierLabels } from '~/utils/partners' +import { getPartnerTierGroupsForPlacement } from '~/utils/partner-placement' +import { usePartnerPlacementContext } from '~/utils/usePartnerPlacementContext' + +const contributions: Record = { + clerk: { + href: 'https://clerk.com/docs/reference/tanstack-react-start/overview', + description: + 'built a dedicated TanStack Start SDK, with authentication components and helpers for both the client and server.', + }, + workos: { + href: 'https://workos.com/docs/sdks/authkit-tanstack-start', + description: + 'built an AuthKit package for TanStack Start, with authentication, session management, and route protection.', + }, + 'ag-grid': { + href: 'https://tanstack.com/blog/ag-grid-partnership', + description: + 'has supported TanStack for years through its Table partnership, helping fund the broader open-source work we do.', + }, + serpapi: { + href: 'https://github.com/serpapi/local-llm-web-search', + description: + 'published a Start application that gives a local language model web search, with the source available to build on.', + }, + openrouter: { + href: 'https://tanstack.com/blog/openrouter-partnership', + description: + 'supports the wider TanStack ecosystem through sponsorship and our work together on AI tooling.', + }, + sentry: { + href: 'https://github.com/getsentry/sentry-javascript/tree/develop/packages/tanstackstart-react', + description: + 'built a dedicated TanStack Start SDK to help developers monitor errors and performance in their applications.', + }, + prisma: { + href: 'https://docs.prisma.io/docs/guides/frameworks/tanstack-start', + description: + 'created Start scaffolding and a database guide that connects Prisma to server functions and route loaders.', + }, + electric: { + href: 'https://electric.ax/blog/2025/07/29/super-fast-apps-on-sync-with-tanstack-db', + description: + 'published examples of building with Start, TanStack DB, and Electric sync to keep application data up to date.', + }, + unkey: { + href: 'https://github.com/unkeyed/unkey/blob/d00fc71f507640eb1cdddef4ca7f8eda773a8cd9/web/apps/portal/package.json', + description: + 'adopted Start, Router, and Query in its open-source portal, putting the stack to work in its own codebase.', + }, + cloudflare: { + href: 'https://developers.cloudflare.com/workers/framework-guides/web-apps/tanstack-start/', + description: + 'built a path to running Start on Workers, with a project generator and Vite integration.', + }, + coderabbit: { + href: 'https://github.com/TanStack/router/pull/6996', + description: + 'helps review changes in the Router and Start repo, including catching cookie-handling issues in the preview server.', + }, + lovable: { + href: 'https://lovable.dev/blog/building-apps-using-tanstack-start', + description: + 'chose Start to power newly generated applications, bringing server rendering and typed server functions to its users.', + }, + netlify: { + href: 'https://app.netlify.com/start', + description: + 'backed Start development and made it the default for its app builder, where you describe what you want and an agent builds it.', + }, + railway: { + href: 'https://railway.com/deploy/tanstack-start', + description: + 'published a Start deployment template so developers can get a full-stack application running on Railway.', + }, + render: { + href: 'https://render.com/templates/tanstack-start', + description: + 'built a Start deployment template with server rendering, server functions, and health checks already wired up.', + }, + vercel: { + href: 'https://vercel.com/docs/frameworks/full-stack/tanstack-start', + description: + 'added Start deployment support through Nitro, with a starter template and automatic scaling on Fluid compute.', + }, +} + +export function StartPartnerContributions() { + const context = usePartnerPlacementContext({ + orderStrategy: 'tier-rotated', + surface: 'start-1-0-contributions', + }) + const partnerGroups = getPartnerTierGroupsForPlacement( + partners.flatMap((partner) => { + const contribution = contributions[partner.id] + return partner.status === 'active' && contribution + ? [{ ...partner, contribution }] + : [] + }), + context, + ) + + return ( +
+ {partnerGroups.map(({ tier, partners: tierPartners }) => ( +
+

{partnerTierLabels[tier]}

+
    + {tierPartners.map(({ id, name, contribution }) => ( +
  • + {name}{' '} + {contribution.description} +
    • + ))} +
+
+ ))} +
+ ) +} diff --git a/src/utils/markdown-partner-lists.ts b/src/utils/markdown-partner-lists.ts index 583bce2b0..73c6acc46 100644 --- a/src/utils/markdown-partner-lists.ts +++ b/src/utils/markdown-partner-lists.ts @@ -10,7 +10,7 @@ export function mapMarkdownPartnerLists( if (block.type !== 'html') return block const match = block.value.match( - /^\s*<(partner-list|previous-partner-list)>\s*<\/\1>\s*$/, + /^\s*<(partner-list|previous-partner-list|start-partner-contributions)>\s*<\/\1>\s*$/, ) if (!match) return block diff --git a/tests/markdown-partner-lists.test.ts b/tests/markdown-partner-lists.test.ts index 5a556e097..07edb8a25 100644 --- a/tests/markdown-partner-lists.test.ts +++ b/tests/markdown-partner-lists.test.ts @@ -4,15 +4,16 @@ import { parseSiteMarkdown } from '../src/utils/markdown' import { mapMarkdownPartnerLists } from '../src/utils/markdown-partner-lists' import { getPartnerTierGroupsForPlacement } from '../src/utils/partner-placement' -it('renders both partner markers but leaves code examples alone', () => { +it('renders partner markers but leaves code examples alone', () => { const document = mapMarkdownPartnerLists( parseSiteMarkdown( - '\n\n\n\n```html\n\n```', + '\n\n\n\n\n\n```html\n\n```', ), ) assert.equal(document.children[0]?.type, 'component') assert.equal(document.children[1]?.type, 'component') - assert.equal(document.children[2]?.type, 'code') + assert.equal(document.children[2]?.type, 'component') + assert.equal(document.children[3]?.type, 'code') }) it('keeps tier order and reproduces the server order from serialized context', () => { From 8e988bfd1355d3609c076376f63a292136b65c67 Mon Sep 17 00:00:00 2001 From: Tanner Linsley Date: Mon, 12 Oct 2026 15:31:29 -0600 Subject: [PATCH 6/6] Set announcement date and credit Manuel and Florian --- src/blog/tanstack-start-1-0.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/blog/tanstack-start-1-0.md b/src/blog/tanstack-start-1-0.md index 994084348..bc8a6586e 100644 --- a/src/blog/tanstack-start-1-0.md +++ b/src/blog/tanstack-start-1-0.md @@ -1,6 +1,6 @@ --- title: TanStack Start 1.0 -published: 2026-10-10 +published: 2026-10-13 draft: true excerpt: TanStack Start 1.0 is stable and ready for production. authors: @@ -10,6 +10,8 @@ library: start # TanStack Start 1.0 +_With contributions from [Manuel Schiller](https://github.com/schiller-manuel) and [Florian Pellet](https://github.com/sheraff)._ + TanStack Start 1.0 is finally stable. And we're really excited to officially call it ready for production. I can't begin to say how proud I am of what we've built here and of the people who have built it. For a long time, I'd hear from people already running Start in production and have to remind them we were still in RC (that conversation happened a lot more than you'd think). I'm really glad we can finally drop that caveat.