Live data from Hacker News

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

nextjs.org

41–50 of 123 posts

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

#41
post #26

Earlier quoted context omitted.

I definitely understand the reaction. This is an existential threat to Remix. However, this is why I don't use Twitter. Remix is not just "an open-source project", it's a full-fledged company. This is definitely not the time (or the forum) to lay your cards out on the table...

It's a full fledged company and somehow Ryan Florence and the other guy are quite heavy handed in pushing their business which irks me. Even react router was moved to a business org called react training if I remember so that they could sell their courses. Now there is nothing wrong with earning money but this new wave of "open source" businesses is a bit yucky.

theres a lot of cognitive dissonance in monetization of open source by consumers of the product.

If you can't charge money for the software, selling courses is the next best thing. Why is it yucky?

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

#43
When learning next recently I was immediately wondering how to do accomplish certain routing patterns that I had used in a previous project… routing to a specific tab of a modal that pops over a particular page…

Luckily that level of deep linking hasn’t been asked for, but this sounds really promising for adding some flexibility

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

#44
post #31

I've stayed at the periphery of front end tech. I am comfortable with react, but often eschew it for the impedance mismatch with the server. With the rise of server side front end practices, it dawns on me that there may be opportunities for integration with other server side runtimes? Asked naively, is there any possibility of an "FFI" integration for Next APIs? Anything more sophisticated than running a subprocess…

This might probably happen a few years down the line. But I’m curious, is there a compelling use-case for this?

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

#47
post #14

Could a smart person please compare and contrast this RFC and the ideas of remix.run?

According to Ryan Florence (Remix's creator) they are "ripping features straight from Remix". https://twitter.com/ryanflorence/status/1528859776930545665

It’s an odd claim, because people have been asking for this (nested routes) more-or-less since Next was first released. In fact, Remix is basically a compiler for the patterns we could achieve back in the days of React Router 2 and 3 (2015-2017).

The fact that the APIs looks similar seems largely inevitable based on the fact that everyone seems to be converging around defining routes using folder and file name conventions.

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

#48
post #14

Could a smart person please compare and contrast this RFC and the ideas of remix.run?

According to Ryan Florence (Remix's creator) they are "ripping features straight from Remix". https://twitter.com/ryanflorence/status/1528859776930545665

Which is a bit silly, to be honest. I understand wanting to see some credit given, and it wouldn't have cost Vercel anything to do so, but this is hardly "new Remix technology" that they're copying (also the condescending "React czar" stuff is just super inappropriate, but par for the course with the way the Remix team has been talking about Remix on Twitter since the days when they were boasting about not taking VC money).

The fundamental approach Remix (and now Vercel) takes to nested routing with React SSR is fairly straightforward. It's how everyone else (not using a framework) has been doing nested routing with React SSR for, what, at least 5 years? Granted, most of us have been using React Router for our React SSR setups, and credit very deservingly goes to the React Router guys (who are now the Remix guys) for that. Remix did a great job of delivering a framework that (via a nice compiler and file structure conventions) makes this React SSR routing architecture very easy to use! But that doesn't mean that anyone else who takes this same fundamental approach is somehow copying Remix. The home-grown React SSR setup I've worked on for the last 4+ years has been doing the same thing this whole time, and while we might be "copying what the React Router community was doing 4-5 years ago," and that might even include demos or articles written by someone who went on to found or work at Remix (again, really, thanks!), I don't think we're in any sense "copying Remix."

edit: Well, I just noticed on Twitter than the cofounder of Remix (also co-creator of React Router) is, contrary to the opinion I expressed in the paragraph above, clearly claiming that he believes Remix deserves attribution for any usage of concepts which ever existed previously in React Router. I don't agree with this. https://twitter.com/ryanflorence/status/1528862791490105344

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

#50

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.

It gets so ugly as soon as you have dynamic routes like `[...postName].ts`
Post reply on HN