Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

nextjs.org

Post reply on HN
Print view View original

91–100 of 123 posts

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#91

Post by snorremd »

amcsi wrote: post #73
GeertJohan wrote: post #70

Next.js is very nice. One thing that always strikes a nerve with me though is that it goes against 12 factor. There is no proper way to build once, deploy (with config) multiple times. So either you have to build for each environment, which on kubernetes means building different container images (one for each environment). Or do a full re-build when the container starts, which means slower container startup, but at l…

Nearly all front end metaframeworks/starters are like this, which is why I've given up on trying to run them in Docker, because it's just over-complicating the deploy process with no real benefit due to what you mentioned, and I'd rather just use simpler tools like Netlify.

Pretty much. I've been able to use some regex-replacements on the build output in the past with varying luck. But it definitely feels like a hack and can break in weird ways. Another option is building all environments into a single container image and then selecting the right build runtime using an environment variable. This makes the build costlier, even if you can build in parallell, and a bigger image takes longer to distribute into your environment.

At that point dedicated frontend hosting infrastructures like Netlify, Vercel, Cloudflare Pages and others seems like a better choice.

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#92

Post by amcsi »

mcintyre1994 wrote: post #84
amcsi wrote: post #75

Earlier quoted context omitted.

I've heard people suggest to always use Next.js, because the alternative (Creat-React-App) is being developed too slowly.

CRA isn’t really an alternative because it doesn’t have a server-side component. It’s also a lot less opinionated around things like routing. I’d say Remix is probably the main competitor to Next, that’s built around React Router and already has support for nested routes/layouts, and has opinionated support for the server-side too.

I'm implying that if you "don't need Next.js", because it's too heavy-weight (because e.g. you already have a dedicated team working on the back end API using a different language), then too bad: there's no lighter-weight alternative that is viable.

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#93

Post by andrewingram »

GeertJohan wrote: post #70

Next.js is very nice. One thing that always strikes a nerve with me though is that it goes against 12 factor. There is no proper way to build once, deploy (with config) multiple times. So either you have to build for each environment, which on kubernetes means building different container images (one for each environment). Or do a full re-build when the container starts, which means slower container startup, but at l…

The fact that Vercel can do deploys to different environments almost instantly, suggests to me that internally they use some variant of the solution suggested in the first reply in that discussion.

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#94

Post by rozenmd »

onion2k wrote: post #79
amcsi wrote: post #76

Every time I hear any news about routing in a React framework I always get disappointed that the news isn't that they're introducing type-safe (TypeScript) routes to enable type-safe linking.

I'm curious about what you mean. There's no way to embed type information into a URL - every GET parameter is a string. Are you suggesting that visiting a link like /123 would go to the ' string: "123" ' route, while clicking a would route you to ' number: "123" '? That would make deep linking in an app really hard to manage. I'm struggling to understand why you'd want to overload routes like that.

This may be of interest: https://www.npmjs.com/package/hono

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#95

Post by wdb »

hermanradtke wrote: post #49

I am not a fan of the “directory structure creating an implicit router” convention of next.js. I wish I would define a handler in code instead.

I prefer the directory structure approach as it makes it a lot easier to find the code related to a route. In other approach you can spend a lot of time finding the right files. The directory structure based routing really makes things a lot more convenient. I can imagine it's annoying when you move routes/urls a lot

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#96

Post by [deleted] »

ostenning wrote: post #69

Frameworks like nextjs are in an eternal existential battle to stay relevant. In my 4 years of using Next, I experienced a large number (6 or 7 releases) of major version releases. What the industry needs is not more breaking changes, but solidified frameworks that companies can rely on. Every major release adds another wave of technical debt as things become deprecated. I appreciate updates, but to me this particula…

[deleted]

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#97

Post by harg »

fabian2k wrote: post #61

Potentially pretty stupid question, I've never used any React framework like Next.js but I have used React for a while. Are these frameworks always meant to provide the backend as well? I'm using .NET as the backend, so I'm curious if they are something I should look closer at. I mean for SSR they have to run on the backend, but even that I could imagine running parallel to the main backend. I'm just not sure if you…

There's nothing stopping you from wiring the Next.js backend up to your databases and external APIs and for simple apps it's likely quite a nice solution. But if your backend consists of complex business logic and needs to talk to lots of different services it can be a lot cleaner to have better distinction between the backend part of your app and the frontend, and just use Next.js' backend for data fetching for the UI.

You can also not use Next.js without a Node.js runtime at all and just compile your whole app to static files to be served by a static file server like S3, nginx, etc. The advantage of this over CRA is that you get statically-rendered html (as well as normal client-rendered React interactivity) which is good for SEO and FCP[1]

[1]: https://web.dev/fcp/

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#98

Post by bennettdams »

aemre wrote: post #81

There will be too many `page.js`, `layout.js` in the editor at the same time, which can be confusing.

I can recommend giving your component name (not file name) some identifier (like an underscore), so using VS Code's "Symbols" via command palette makes it easy to find and open them.

Screenshots: https://twitter.com/BennettDams/status/1529051702351085568

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#99

Post by smoe »

fabian2k wrote: post #61

Potentially pretty stupid question, I've never used any React framework like Next.js but I have used React for a while. Are these frameworks always meant to provide the backend as well? I'm using .NET as the backend, so I'm curious if they are something I should look closer at. I mean for SSR they have to run on the backend, but even that I could imagine running parallel to the main backend. I'm just not sure if you…

We have built our new corporate website with NextJS. After getting some used to the framework's particular opinions about how to do things, it was an overall good experience.

The main benefits of such a framework for us in our use case:

- 90% of the content is essentially static and can be pre-rendered, the rest is dynamic. With NextJS we can easily mix and match these cases, re-using the same code

- We use the backend part to act as a gateway to fetch content from different APIs like the CMS, HR tool, email service, etc. The very little custom backend code required we put into nextjs api functions

- It comes with a couple of niceties built-in for page speed like image optimization.

- Any frontend dev with some react knowledge can work on it. This is my problem with say WordPress, you fairly quickly hit the point where you need specialized knowledge that you can't re-use that much for other projects in the company.

Of course, the same and more can be achieved by selecting libraries to build a bespoke stack, but don't think a fairly standard website that doesn't need to change a whole lot warrants the upfront effort.

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#100

Post by mcintyre1994 »

nsonha wrote: post #78
gliiics wrote: post #66

I like the way this works, it feels inspired by SvelteKit's __layout.svelte files and I think it's just very intuitive to work with. Edit: welp, seems i glanced over too quickly, it's literally written there: > The layout.js file convention was inspired by the work done in SvelteKit

why do I remember that nextjs always has had layout. Only worked with it briefly 2 years ago.

It’s always (or at least for a long time) had a layout, where you can define components that your page fits into. It’s really nice for putting a login status in a navbar, or something like toast notifications, because the layout components don’t get replaced when you navigate client-side.

But it’s not nested currently, you only get one layout - so if you want some pages to have a sidebar or something then you’re not getting the benefit of the layout system for that.

Post reply on HN