
Micro frontends boost autonomy but they make CSS a nightmare. In this guide, I break down how to scale styling without collisions using design tokens, CSS Modules, and the Shadow DOM.

Learn how ChatGPT’s new browser Atlas fits into a frontend developer’s toolkit, including the debugging and testing process.

Users don’t think in terms of frontend or backend; they just see features. This article explores why composition, not reactivity, is becoming the core organizing idea in modern UI architecture.

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the November 19th issue.
Hey there, want to help make our blog better?
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]