
Explore TanStack DB’s new feature, Query-Driven Sync, and how you can leverage it to build efficient, scalable React applications.

Error boundaries catch only render-time failures, which isn’t enough for modern async UIs. Signals treat errors as reactive state, giving you consistent handling across your app.

Build fast, scalable UIs with TanStack Virtual: virtualize long lists, support dynamic row heights, and implement infinite scrolling with React.

CI/CD isn’t optional anymore. Discover how automated builds and deployments prevent costly mistakes, speed up releases, and keep your software stable.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
One Reply to "Comparing Next.js and After.js for SSR React apps"
The elephant in the room with Next.js is lack of nested routing[0]. In any moderately complex site, you don’t want to re-render all your components (header/footer) on a page transition. Which also requires you to include your React components on every route path (page.tsx). I was excited to migrate from a Vue.js SSR project to next.js/react, but these basic requirements seem to be lacking. After.js recognises this and uses React Router. But After.js does not have the momentum Next.js has.
Another issue with Next.js that I think stems from the lack of nested routing is the fact that routes with a getServerSideProps() are called even on client side page transitions[1]. This means that if you fetch data for the entire page, eg user, menu and footer data in getServerSideProps(), this will be fetched again and again on each and every page navigation. There are hacks for these issues, but After.js seems to not have these in the first place.
[0] https://github.com/vercel/next.js/issues/8193
[1] [https://github.com/vercel/next.js/issues/11897]