After 2+ years, it's finally time to announce @Tan_Stack Form v1! ✅ Type Safe 🚀 Framework Agnostic 🎭 Headless 🔄 Isomorphic 🛡️ Advanced Validation 📜 Standard Schema ➕ More!

🎉🥳 Announcing @tan_stack Router - Routing for Apps! 🛡️ 100% TypeSafe 🔎 URL State Management 🔁 Built-in Caching ✅ Search Param Schema/Validation ⏲️ Auto Prefetching 🔀 Loaders/Actions ⏳ Async Elements + Code-Splitting 🌎 Framework Agnostic Core tanstack.com/router

We just hit 4 Billion Downloads for @Tan_Stack! 📈

🚀 Announcing @Tan_Stack Start v1 Release Candidate! Upgrades ↓ ✨ Unified Route Tree: no more server-specific files 🔐 Type-safe middleware & server context upgrades 🛡 CSP/nonce support ⚡ Now works with any native Vite Env plugin 🌀 Zero-JS: any server handler can render!

Big news… As of 1 month ago, I am officially working full-time on @Tan_Stack! It’s been amazing to see it grow from a tiny react-specific table library into the multi-framework brand that it is today, but I'm even more excited about the future. TanStack is just getting started. 🧵

ChatGPT may have moved from Next.js to Remix, but some things are better left alone: @Tan_Stack Query4Lyfe

This is Tanners wife, it’s his birthday today!!! 🎉🎂🥳 show him some love! Happy birthday T! We love you!

🎉🥳 Announcing #ReactLocation, a brand new router for React! ⏳ Async Loaders & Elements 🔀 Parallelized ⏲️ Prefetching 🗄 Caching 🔎 1st-class Integrated Search Params API 🗂 Code-Splitting ⚠️ Error/Pending/Timing States 🪆 Nested Layouts react-location.tanstack.com #TanStack

Coming soon: @Tan_Stack Router's `intent` preloading can now predict where your users cursor will go (you can even customize proximity) to preload the routes that users are most likely to visit *before* they even hover the link. Prefetch smarter, not harder.

I'll continue to die on the hill of "magic directives are bad API interfaces". They're not type-safe, they're not extensible, no native runtime control, they're just strings. ... I can't believe I'm saying this, but I would rather debate @ directives. Pls rewind history.

📣 Time to announce "create-tsrouter-app" or CTA, a drop-in CRA replacement: - Powered by @Vite_js + @Tan_Stack Router, built by @jherr - TypeScript/Tailwind/File-Route templates (more coming) - Pre-ejected with full control over Vite and (soon) upgradeable to TanStack Start

Only minutes in and the GitHub issues for the @Twitter algo are a dev-trolling mess 🤦‍♂️

Typescript just got way better github.com/yoavbls/pretty-ts…

Announcing #ReactQuery v3!!! 🎉🥳 💧 Better SSR ♻️ keepPreviousData ↕️ Bi-Directional Infinite Queries ✂️ Selectors ⏭ useQueries 🔁 Retry/offline support for mutations 🍎 Agnostic core 🛠 Bundled Devtools 💾 LocalStorage Cache (experimental) react-query.tanstack.com/gui… #React

Stoked to announce that @Tan_Stack Start is now officially BETA! 🎉 🎊 Please come and try it and help us get it ready for 1.0!

A wild full-stack React framework appears! It's very early, but TanStack .com's `tsr` branch is already being built and deployed to @vercel using our new experimental full-stack template "TanStack Start", which uses TanStack Router and a splash of @nkSaraf98's Vinxi. More info coming soon!

🌶️ React should have been more accurately named Rerender.

I don't want to take too much time here, so here's some hip-shot observations: - The Start app is using an outdated version of both Start and Router (old vinxi-powered alpha), which likely accounts for a significant portion of memory leaks. Regardless, we're going to make sure the most recent version is leak free. - SEO hit in Start is largely due to a missing <title> tag (misconfigured as a meta tag, but we'll make it even easier and type-safe to spot this) - Some links gained forced prefetching directives during the migration to Next to preload on render instead of intent (TSS is still visibly imperceptible here despite being hover-intent only) - We noticed some non-framework related changes to base image sizes, Query Client staleTime defaults that could have contributed, but it's hard to tell without isolation. - It's possible that *some* of the page that was tested was statically generated at build time. You'll have the same ability with Start by 1.0 ☺️ - TanStack Start lacks an <Image> component like Next's... for now. - Despite all of the above, Start still performed equally as fast as Next in their UI/UX comparisons, so I like those odds. We didn't really get an opportunity to address any of these concerns or their implementation. I wish they had reached out for help/feedback (and received a bunch of free help from us) before putting in the time to migrate. I also think writing a "We migrated from [Beta Software] to [Steel-hardened Market Leader]" article is just a weird thing to do, but here we are. Either way, we're using it to improve Start even more.

Oh @dhh, you make me chuckle. The vast majority of "TS devs" don't live anywhere near here, so maybe loosen the grip on your anti-TS baseball bat? 😆 Your quoted tweet screams library author/code. If anything, this is a simple testament that writing libraries and abstractions is definitely a 1% path. Even a vast majority of "just JS" devs can't be trusted to write decent library-level abstractions, let alone type-safe ones. Nothing is ever this binary, you know that. Just for kicks, let's write some "just JS"! Look ma! No TS! ... Well, spoiler alert, this is 100% type-safe code, backed by the kind of code you just slighted (and not even that much of it). Because of the 1% that invest the time into understanding static typing, generics, type-safe architecture that make writing TS virtually the same as never writing it. nitter.app/dhh/status/17885798739…

I'm happy to announce: 🎉 React Query Devtools! 🎉 Visualize, sort, debug, manipulate and explore your queries in real-time! This is just the beginning! #TanStack #React #javascript github.com/tannerlinsley/rea…

Totally real numbers

🎉 @Tan_Stack Start now has Selective SSR Opt-in/out of server-side rendering per route, even dynamically: 🌎 ssr: true – full SSR 💽 ssr: 'data-only' – server runs loaders but skips HTML 💻 ssr: false – pure client-side 🧪 ssr: (ctx) => any of the above Another win from the one and only @schanuelmiller tanstack.com/start/latest/do…

I'm excited to officially release TanStack Table v8! 🎉 🌎 @reactjs, @solid_js, @vuejs, @sveltejs 💙 100% @typescript 📦 <= 13kb 🙈 Headless! 🎮 Opt-in Full Control ⚡️ Faster & Simpler API 🤝 @ag_grid Partnership FTW! 📚 New Docs! tanstack.com/table/v8

So stoked to finally get to announce and release: React Query!!! - Agnostic data fetching - Auto Caching & Refetching (Window Focus, Polling/Realtime) - Dependent Queries - Mutations - Auto Garbage Collection - Pagination + Scroll Recovery - 4.1 kb github.com/tannerlinsley/rea…

Tailwind still remains 5x better than any other approach to styling I've ever used.

You inspired me, @cassidoo. Since hooks and the early conception of the suspense API, I have personally felt that React has been obsessed with just a handful of concepts. While technically impressive and undoubtedly pushing the limits and boundaries of what a single-threaded UI API can do, these new concepts have had very little impact on what I do day to day to deliver value to my users (other than making it more complex to "safely"/idiomatically do the same thing or dancing around experimental APIs that my open source users think are officially ready for prime time). I want so badly for React to return to the client-side-focused and client-performance-obsessed utility I originally loved (or at least help me know better that it still has my interests in mind). It's painful to see other frameworks continuing to deliver on the same motivations that led me to React from day one. React Forget has drummed up some of that old excitement, but it's easy to get caught up in a new "feature" that in reality is a reactionary answer to a deeper issue. The most brief I can be on this topic is that I really wish we could just drop this obsession with immutability and address true reactivity. Whether that's through signals (please) or not (still fine), this has felt like the most ignored low-hanging fruit for a while (sorry I've been following @RyanCarniato's signals for much longer than most). Like Cassidy, I'm still using React very heavily and I'm still reaching for it regularly... but with increasing resentment.

As a user of a library, moving your TS to JSdoc or declaration files is totally fine. I still get types. But this is just... weird. The information loss alone is hard to justify for me. "Need info here?, Consult the docs, if we have them and they're up to date."

It's 2025 and the React docs still don't show Vite + vite-react as a 1st class valid target despite an ocean of developers still using CRA for SPAs likely never caring in the slightest what blessed fullstack meta framework is the "idiomatic" way to use react.

Announcing React Virtual 🎉 A React hook for virtual scrolling of rows, columns and grids in fixed, variable, and dynamic measurement modes! #TanStack #react #javascript GitHub.com/tannerlinsley/rea…

We're getting @Tan_Stack Start 1.0 ready, but we're also slowly working on our post 1.0 RSC impl that I genuinely think people are going to gush over... as long as they can get passed the initial "what the..." moment. We've shown it to ~10 people and it was 🤯😍 every time.

Lots of us should genuinely up the empathy for @dan_abramov. Effects are hard. Docs about them even harder. Have you ever written docs for a prolific library? He's balancing core learning material with loads of ecosystem expectations. Keep pushing Dan. The new docs are great ✊

It’s a @Tan_Stack Christmas!… again! Fun fact, I used to be a roofer at my Dads company. I learned to work hard, take pride in my craft and earn an honest living. And that’s literally the biggest reason I get back on the roof every year, to honor his legacy. Miss you Dad!

If I were to start a full stack app today, I would most likely use Remix.

GDPR banners are exhausting. What a terrible user experience. It’s like being approached to sign a waiver at the entrance of every store you enter for the rest of your life.

An awesome new @Tan_Stack package is about to drop soon. Keep your 👀 peeled.

Hello, my name is Tanner "Cringe-Stack" Linsley and I have officially lost all OSS self-control.

I'm *very* thankful that React rolled back the v19 suspense gate and were willing to work with us. I think the future is as bright as ever. Now, this is where I want to go next: I'm increasingly concerned how much React is pushing render-as-you-fetch (hoisting+preloading) as the blessed (and last week, almost required 😜 too soon?) approach for client side data fetching, despite the current state of ecosystem. Regardless of the library you use to fetch client-side data, if you're not using a framework's SSR-level route loader or async paradigm, your solution probably resembles some kind of hook (like useQuery, or heaven forbid, one that you rolled on your own). I'm happy about the concern we all have for perf, UX, parallelism, etc, but not super happy that some of use are so quick to give up the amazing DX that is data colocation. AFAIK, Relay is one of few libraries that can really handle hoisting data requirements out of components automatically (not without a lot of buy-in and convention) and get you the best of both worlds. It's naturally that RSC is the spiritual evolution of this pattern. You could argue that a router with a loader lifecycle solves a lot of this, but (1) this assumes that your data usage-site is close to your route boundary and if it's not (2) you likely had to either move that data out of a deeper component that uses it and into the loader that then passes it back via prop 😮‍💨. Or.. duplicate your work by doing a split preload/use-later approach, which is the most monotonous feeling thing in the world and prone to error. Colocation on the other hand feels natural for projects that require this level of data dynamism in components (think dashboard widgets or productivity app). And for the most part, this works amazing.. unless you need SSR. And that's where I imagine React has likely been thinking server-components would fill in nicely. As always, SSR is the crux of it all and Relay was on to something. Regardless, If you need both colocation and SSR, you have to jump through hoops to get there. Annoying ones. Even with those annoyances though, it's hard for me to imagine many of these highly dynamic apps moving to an RSC future (unless SEO/SSR is in the bread and butter of their product, e.g. if you're a social network or e-commerce thang, it makes perfect sense). My point is that RSCs are not the only answer to colocated data fetching and honestly still require some kind of hoisting convention if you want to avoid server-side waterfalls. For starters? RSCs require architecture and opinion buy-in beyond `npm install react`. So when I see render-as-you-fetch, what I really see is a pretty hefty checklist: - Data Hoister (Compiler, router convention, etc) - Cache Coordinator (QueryClient, etc) -Consumer (useQuery, use, etc) And a whole much of hairy code to make sure that SSR works (streaming, hydration, etc) Yes, it's can be more performant to some KPIs and if you need those or SSR, you'll have to do it anyway, BUT it would be a mistake to think *everyone* is in that bucket. I would really like to see more attention going into retaining the awesome DX of being able to colocate data requirements with usage sites without forcing more cognitive load around prefetching patterns. I don't know what those solutions are yet. I have ideas. But even if we as an ecosystem were to go down that road, it would be 1000 times better if it was a problem React itself would consider as first-class instead of some cursed pattern that needs to be squashed or discouraged. This is why @Tan_Stack Query is so awesome IMO. Yes, there's some extra preloading to do if you need SSR, and for RSCs and frameworks, we're already hard at work on some pretty cool stuff (despite missing React primitives) to make it just work with RSCs. TanStack Start/Router will be no different. Reducing cognitive load is our goal and trying to remember if you preloaded or kicked off a fetch in a loader is high on my list of mental tasks to destroy. Please, don't kill colocation.

Easy to forget how cool this is. Each element remembers where it was scrolled to, even the virtualized element list, which is WAY dynamic and only rendered after the DOM has been measured.

11 years today! 🔥

Woah, @Tan_Stack Router just hit 1M weekly downloads! tanstack.com/stats/npm?packa…

We just announced it on stream, but let's be official... 🎉 @Tan_Stack Solid Router is now available! Have fun @solid_js-ers! tanstack.com/router/latest/d…

🎉🥳 Announcing TanStack Query v4! 🪪 Name Change! 🌎 Framework Agnostic! ✅ @reactjs 🚧 @vuejs 🔜 @solid_js @sveltejs 🔀 Concurrent React Support 🏕 Offline + Network Mode 💾 Stable Persisters ⚡️ Tracked Queries Default / Perf+ 📚 New Docs! 🙏 @TkDodo tanstack.com/query/v4

This opinion will likely be very divisive, but I believe if you can get past your syntax pride, it might just 🤯 your 🧠 and increase your productivity. carbon.now.sh/h2sWO3OdShbaj3…

TanStack DB is an extremely gratifying realization of the years-long vision I had for React Query from day 1. To be honest, most of us wouldn't have been ready for sync back then and many still aren't, which is exactly why Query exists today, as an incrementally adoptable tool to bring you (and pretty much any existing FE tech you have) out of the data fetching stone-ages into the modern JS world. But that's just the first step. We knew from the start that despite being transformative, Query could only get us so far, even if that was 90% of the way. A foundation for us to stand on to conquer the the last mile. DB delivers similarly massive UX/DX improvements and simply put, goes where Query never could, all while likely removing code you had to write in Query (or any other pseudo-sync-engine client) We're just getting started. DB is already a game-changer for DX and UX even though it's beta. Buckle up.

Server components are going to be great for bundle size and hydration payloads. But I don’t see them becoming my preferred way of orchestrating data fetching. I have other plans for that.

.@Tan_Stack is quickly becoming more of an incubator for much needed projects that embrace what the brand stands for. A few of these libraries were created completely by contributors, and many of them, including some of your favorites, are fully maintained by those same individuals.

React Table will here-forth be known as... TanStack Table! - It's now in BETA 🎉 - Adapters for React, Solid, Svelte & Vue - New docs (and new TanStack.com)! - Release candidate coming very soon tanstack.com/table

This weekend @Tan_Stack passed: - 2 Billion NPM downloads - 100k Github Stars - 1 Million Github Dependents - 2.3k Contributors Thanks for the stats @convex

🎉 @Netlify is now the official deployment partner for @Tan_Stack Start! We trust Netlify now more than ever to deliver on TanStack's vision: 🔹 Unmatched DX from code to user 🔹 Simple and Flawless Performance 🔹 Ultimate Flexibility and Composability This partnership is all about making web development smoother, faster, and more powerful for everyone. I'm excited for what this has already and will continue to enable us to do at TanStack! tanstack.com/blog/netlify-pa…

Just use <select>, right? I wish. My life right now: - Async - Multi-Select - 100,000's of options - Fuzzy search - Multi-faceted filtering & sorting - Virtualized/Paginated I should really publish my @Tan_Stack Select package soon...

“My code is so safe! We have so many tests!” I can’t imagine anyone’s written enough tests to fully cover @typescript’s StrictNullChecks. This rule alone will literally enforce you to be the most defensive, edge-case-aware, error-handling programmer you can imagine. It’s 💯/💯

Announcing React Query v1.0.0 🎉🎉🎉 - usePaginatedQuery - useInfiniteQuery - QueryCache Utilities - Enhanced Query Keys - Better SSR & initialState - Improved Suspense Support esp. for Fetch-As-You-Render Prefetching - Suspense Mutation Error Boundaries github.com/tannerlinsley/rea…

A little reminder of what it takes to write a fully type-safe router (and framework too, I guess) "Don't try this at home, kids." Just use @Tan_Stack Router.

#ReactQuery Users: What if I told you that you would never have to see another spinner again (...maybe just one on bootstrap? 🤔), and you wouldn't even have to use suspense at all? Let's just say I'm almost done with the alpha release for a new library you'll want to try! 😃

“It Starts…” 🔥 🔐

It's almost ready to save you... @Tan_Stack #Router #React #Solid #Vue #Angular

🚨 Woop 🚨 Woop 🚨 Woop!

3rd time’s a charm 👂

Approaching 2.5B 🤯

Just built another app that will probably never benefit from server components or streaming. It’s an SPA, behind a login, with zero SEO concerns for users that will never care about or appreciate “It streams, baby” and instead immediately asked about offline support. Also, is it that hard to believe that the DX is 🔥…because we’ve spent the last 10 years optimizing for this. It’s all trade offs, it just comes down to knowing what you can trade or not.

TanStack DB has me just as excited as Query and Router did in their early days. So exciting watching the API and DX unfold.

GitHub has a home page? I had no idea.

As if the FOMO to try @Tan_Stack Start wasn't 🔥 enough... 🚀 We're doing a TanStack Start hackathon! Hosted by @convex , @coderabbitai, @firecrawl, @Netlify , and @autumnpricing. 🤩 Build a full-stack app and compete for $10k in cash prizes and credits! 🔗🧵↓

30% of React installs also use @Tan_Stack Query now. That’s wild. 🤯

Ahhhhhh!!!! 🤏

Sorry, but even after a while of giving 🦋 a real shot with double posting, setting up lists, deck.blue etc, it's nowhere near X/Twitter and not trending up for me. I've had way better chats, seen better content, and overall enjoyed it here more.

Currently rewriting some massively dumpy code from my vibe coding session the other night. It did its job: proof of concept, fast. But my serious rewrite is already half the LOC, more accurate, easier to understand etc. And I’m not even done yet. Vibe responsibly, folks.

Okay, this is insane that I can just `useSuspenseQuery` in @Tan_Stack Router and not worry about SSR, streaming or anything. It just works. If the data is there before first-byte, it's dehydrated, and if it suspends after that, it streams the query down. 🤯 Combine that with Start's `createServerFn` (isomorphic server-only RPCs) and it's way powerful. This is how Query + SSR was meant to feel all along.

You may *think* this is just @Tan_Stack Start's default demo app, and you'd be right... But it's inside @astrodotbuild

I'm highly considering moving from [var, setVar] pairs when using React.useState to a [var, varSet] pattern. The amount of time I lose by not being able to cmd+d or find-replace those vars is adding up. #react #reactjs #javascript

Yes, we will be announcing ANOTHER awesome @Tan_Stack library tomorrow. Be there or be 🔲

Every tweet I like about TanStack is me actually clicking/tapping the ❤️. I read all of them personally and do not use a bot, promise!

Fun fact... This was built with #ReactTable! 🎉 react-table.tanstack.com #TanStack #React

I'm convinced that React's concurrent rendering model is fundamentally at odds with fine-grained reactivity/updates/rerendering. I have users who are clawing at me for fine-grained updates and rendering subscriptions in TanStack Router, but you simply can't have both fine-grained updates AND things like transition/suspense-aware state. Let me explain. To get fine-grained subscriptions in react, you have to use an external store (literally anything that doesn't trigger rerenders out of the box) and wire up the subscriptions to where they are used in react, hopefully with something like selectors, proxies, signals or atoms. However, as soon as you move your state out of useState/useReducer, you will experience state tearing when you attempt to use concurrent rendering, especially with startTransition. This is because React can't "version" your state, create new fibers based on it, etc. So if fine-grained reactivity and subscriptions are important to your application or library, you kinda just have to swallow the bitter pill that you can't *really* support startTransition at the same time... and tell some of your users (who may totally *need* concurrent rendering, but refuse to use a library if it doesn't check that box) to take a hike. Maybe you decide it's worth trying to figure out though, just like I did 2 months ago, so you can get that high-quality A-grade startTransition support people are asking you for. To do this, you must put ALL of your state into either useState or useReducer and ensure you're not breaking ANY concurrent rendering rules. However once you do this, you'll quickly realize the only way to propagate that state down to subscribers is via React context... So you start to do the song and dance of splitting your state into multiple contexts. But then you also realize that updating any useState or useReducer will trigger renders all the way down... unless you useMemo to bail out... and teach your users to do the same. At the end of the day, you essentially have to tell your users to embrace frequent rerenders and optimize the crap out of their entire application. But hey, that's not too different than what they're used to. But it's important that people realize this is the reason that the "useMemo as an optional optimization" speak is a bandaid lie we've been told to so we can deal with React's lack of reactivity. So here I am with two patterns that are essentially at odds with each other and I'm on the verge of picking one over the other. Can you guess which one? Is concurrent rendering - and more specifically in this case, holding paints until all suspense boundaries inside of your startTransition resolve - more important than fine-grained performance? Why do we have to choose?

By popular request, TanStack.com examples now default to a newly designed in-house file explorer and code preview panel! You can continue to access the sandbox mode, too! Huge shoutout to @seancassiere and @KevinVanCott for putting this together for @Tan_Stack!

Yeah, someone should do that.

After 3 months of development, the first alpha example of @Tan_Stack Start was deployed today! 🎉

TanStack.com is now running React 19, on the latest version of Start and Router 🎉

When I build libraries for React, ironically, I don't really use hooks like useState, useReducer, etc. One of the best perks (and footguns) of managing your state *outside* of react is that you get to have full control over when a component should rerender.

One of TanStack's greatest maintainers, @seancassiere, is looking for his next big engineering role. Let's find it for him! A true 💯 with autonomy, architecture, throughput, teamwork, etc. He always delivers. DM him for offers! Use TanStack? You use his code. Repost this.

It's going to be 10x easier to build server routes in TanStack Start very soon (AKA API routes or resource routes) - Unified route tree - Same old createFileRoute - Route-wide middleware - Handler-level middleware - Type-safe Context - Access server context via beforeLoad/loader

Trigger Warning Error: Hydration failed because the initial UI does not match what was rendered on the server.

Query-Driven Sync is going to be transformational IMO. It's already changed my perspective on not just modern server state, but also app state. It's bred from so many great ideas and tools that have come before it, built on top of bulletproof patterns and even some of our own libraries to do what I dreamt of being possible over 5 years ago when I started the original React Query.

I built something last night/morning I’ve been thinking about for a while. Had so much fun I was irresponsibly up until 3 AM. I’ll show it to you soon.

Hey @lyft and @usairforce, thanks for using my open source software! 🎉 Please consider becoming a sponsor at github.com/sponsors/tannerli… 🤝

The very minute @t3dotchat launches a desktop app with an Option + Space launcher, I'm gone from @ChatGPTapp. The UI on GPT doesn't *look* bad, but lacks so many obvious low-hanging fruit features that drive me insane every day. A new one I found today: If I move a chat into a "project", I can't rename it... 🤦‍♂️

😱 I was just made aware (by @tkdodo and @danielgriesser.com) that @steamdeck uses @Tan_Stack Query and Virtual for their SteamOS 🚀. Amazing to get a glimpse of what the TanStack is getting used for 😄

If Astro ever comes out with 1st class client side routing... every framework is in trouble.

Just about every SPA I've ever used could use a lot less <Button>, and a lot more <Link>. I'm not talking about pathname routing either. A vast majority of the time, the state you're about to manage belongs in the URL and I'd wager you're not putting it there because either you didn't know you could/should or your URL/Routing tools don't care about state management enough to help you manage it properly. It should be as easy as: <Link search={prev => ({ ...prev, sortDesc: !prev.sortDesc })} /> - Should NOT require me to pass/concatenate paths, use URLSearchParams 🤢, or devolve into single-level string/string key-value nonsense. - Should completely hide serialization/deserialization - Should generate a valid a href that you can command click - Should handle deeply structure JSON, including structural sharing to appease React's "reactivity" 😝 - Should be type-safe in context of your current relative route. - Should have matching "active" options powerful enough to handle more than "this path starts/ends with this path" - Should provide the *same* great expectations via imperative means e.g. navigate({ search: prev => {...} })

Announcing @Tan_Stack NPM Stats (Beta) 🔗 Shareable deep links 📦 Group related packages together 📊 Daily/weekly/monthly/yearly binning 📈 View absolute or relative growth 🎯 Set baseline for comparison 👁️ Toggle package visibility 🎨 Customize package colors 📋 Popular package comparisons 🔍 Smart package search 📅 Flexible time ranges (7d to all-time) 🌙 Dark mode support 🌎 Open source

Alright, I pushed it live! 🎉 However... it's beta. So I decided that to become an early beta tester, you must find it! Mwahahahah Rules: *If* you find it, don't tell anyone lest you be shunned (temporarily), but feel free to join the TanStack Discord to openly discuss it :)

Internally achieved: Server function RPCs with *just @vite_js *. 🤯

Finished my first half marathon today! Despite an AirPod mixup and running sans-music (this sucked), it went great! 2:33 and can’t wait to do it again!

We're right in the middle of "devinxi" (removing Vinxi from @Tan_Stack Start for just Vite + Nitro + h3), and we decided to give Start some awesome quality of life improvements while we're in the guts of it. Here's *some* of the lower hanging fruit (there's even more): - Jumping on the "just a Vite plugin" train. It's a good one! - Fewer files/changes when moving from Router to +Start (like one new file, and 1 line-change in another. We'll probably offer an "upgrade" command or something, too) - Single server entry for more unified control over everything http including api, server functions, sockets - Which means API routes can live anywhere, not just /api - Easier rewrites, redirects and proxying, websockets - Unified routing API for app routes and API routes - And finally the bedrock to to proper SPA/SSG/Hybrid-SSR support across the board Even more in the works too, but I'll let you salivate over these aromas for a hot minute.

Even when I’m sick, tired and feeling useless, @getsentry somehow still has my back. Literally. 4 days of fever and this has been my daily uniform.

The demand is so real, it’s on. We’re shipping something amazing @Tan_Stack tomorrow.