
Solve coordination problems in Islands architecture using event-driven patterns instead of localStorage polling.

Signal Forms in Angular 21 replace FormGroup pain and ControlValueAccessor complexity with a cleaner, reactive model built on signals.

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the February 25th issue.

Explore how the Universal Commerce Protocol (UCP) allows AI agents to connect with merchants, handle checkout sessions, and securely process payments in real-world e-commerce flows.
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]