Next.js Layouts RFC: Nested routes and layouts, designed for Server Components | Hacker News Reader

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

nextjs.org

229 pointstodsacerdoti119 comments

We're irrationally excited about this internally and we're super happy with how the Vercel team has continued to push Next.js forward. Thank you!

We're using a version of the persistent layout pattern Adam Wathan [blogged about](https://adamwathan.me/2019/10/17/persistent-layout-patterns-...) but having first-class support for this paradigm will be awesome.

Thank you! We've added documentation[1] on the current layouts solutions, which is similar to Adam's post. It's a good workaround, but I'm very excited for improving the developer experience here.

[1]: https://nextjs.org/docs/basic-features/layouts

There's a fundamental flaw with the solution proposed in the documentation (getLayout as a function), which could be fixed by using a pure JSX approach: https://github.com/vercel/next.js/issues/36029

"irrationally excited" - what does this phrase mean? that there is no basis for your excitement? sounds so cheesy

excited beyond reason? try lactaid.

being more excited that you can readily account for

I love this approach and use it, but just realized it does not prevent Layout components from re-rendering upon navigation... have you found a fix for this?

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

So we need to give credit now to every little bit of inspiration we get when coming up with new features and ideas?

Not really sure what the problem is here.

You'd have to ask Ryan :)

IMO it's really just a matter of time before good ideas end up in other projects. It's inevitable. Obviously everyone wants their framework to be as good and popular as possible.

It's really not an especially novel idea either- there's not really a good reason for remix itself to be getting the credit here.

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?

It's not the training, it's the fact that they moved the project repo under the React Training organization, and now it's under Remix... Just comes off as a cheap attempt at marketing while ruining the OSS image of the project.

You can make convoluted software which creates an artificial need for your training or consulting service.

Also using OSS as a funnel for your business and then use your training to hype up your OSS projects

We've deviated from the OP, but I wanted to mention that this is why react-table and react-query bother me endlessly.

https://mobile.twitter.com/sebmarkbage/status/15288585107544...

> No shame in copying but the first prototype of this started before Remix was available. It was more inspired by traditional server routing techniques (like FB used) with React Router locality with Next.js file conventions. So it's more about convergent evolution in this case.

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.

It reminds me of patent trolls who patent obvious software designs. I was looking for such feature long before I heard of Remix. I know he's the react-router guy, but nested views isn't exactly some novel idea - sites have been using it forever.

> Remix is basically a compiler for the patterns we could achieve back in the days of React Router 2 and 3

Well, Remix and react-router are by the same people.

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

I don’t understand why you’d ever expect your competitors not to copy your good ideas. That’s business sense 101 as far as I’m concerned.

Remix creators inspired by Ember.js as they mentioned years ago in one of the blogpost about the new concept and philosophy.

It's weird to me: I don't use Twitter and I don't intentionally follow influencers or celebrities in the tech world. Yet somehow RF has been the center of several bouts of developer of drama I've come across. Any idea why that might be?

Credit's been added: https://twitter.com/leeerob/status/1528887380681588736

Ryan and his insufferable Remix evangelists are the reason I never went beyond a quick hello world. And I like the concept.

A while ago he had a Twitter series “spot a React app” where he just shits on other peoples work.

Such an odd way to promote his work.

And this weird obsession with form methods and the way they make it like if you dont use form method you are an idiot.

Like get on with it, are there are other things in remix? I'd like to hear about them too!

> insufferable Remix evangelists

That is so true. It's been driving me insane since Remix was announced/opened but I couldn't quite put my finger on why. It's because overnight there was an army of people preaching the new religion of Remix all over the place, and not a single one I asked could (at the time at least) tell me why it was better/different than Next.js (a project which IMHO rose on its merit and had to fight for every inch). They had clearly never looked seriously at Next.js before because every "feature" of Remix they were excited about was something Next.js already did. After a bit they started linking to a very long blog post from the Remix creator that supposedly explained why they were different, but after 10 minutes of looking through a post that was supposed to answer my question, all I had was anecdotal performance numbers about how Remix is "faster."

In software we definitely do tend to cargo cult and worship good languages/frameworks, but the Remix "love" is (or was at least) over the top even for us.

Yeah this is really common in people trying out niche things.

Not only in software. Remember the "Don't worry, they'll tell you" jokes about vegans and crossfit?

I think it must be some sort of evolutionary strategy to justify the risk/anxiety of going against the group.

And remix is ripping features from Vercel. Such as they business model, and the idea of creating their own framework for it.

Additionally, I wouldn't trust ever again the guys that rewrote and broke react-router with incompatible changes like... 6 times already? And now bragging on podcasts "Remix is 10 years old because is just built on top of react-router". Bullshit, it's just the npm package name that is this old. It is so deceptive all the ugly marketing they're doing.

It's almost an exact copy aside from the conventions and names. It very much _is_ Remix. This is pretty wild. It also brings one of my gripes from Remix: parallel fetching. In practice it makes sense, but at times there needs to be a way to fetch data on a parent route first so that child routes don't fetch again. I'm sure Vercel will find a way to solve this.

Doesn’t Outlet context solve your issue? It let you share data between parent and child path. Of course it is during rendering so you can’t use parent data in your loader.

> Of course it is during rendering so you can’t use parent data in your loader.

I specifically want the parent data to perform redirects in child routes. The only solution is to manually add the redirects at the parent level (like a whitelist).

The surface-level approach and APIs/conventions looks very similar, just with some slight differences that people may subjectively prefer over Remix. Personally my immediate reaction is that I prefer Vercel's convention of requiring all visitable routes to be represented by a leaf called page.js. In Remix, you can have a file anywhere in the routes that will create a navigable path segment using the same name as the file, e.g. the file /dashboard/settings.js will be visitable at the URL /dashboard/settings, whereas in Vercel this will need to be /dashboard/settings/page.js. I prefer Vercel's way of doing things, because with Remix you often end up with a .js file as a sibling of a directory with the same name, e.g. /dashboard/settings.js and /dashboard/settings/advanced.js, which means that you can't just look in the /dashboard/settings/ directory to see all of the routes with the prefix /dashboard/settings.

The routing is pretty similar. A concept that predates Remix, but Remix made popular again.

What sets Remix apart is how it handles network requests through its own <Form /> wrapper, which anecdotally leads to incredibly simple data handling. Even cooler, if you restrict yourself to GET and POST, your app will work without JS. Nifty, if you ask me.

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 least you can re-use the container across environments and properly inline environment variables. There's a discussion about this; https://github.com/vercel/next.js/discussions/24010

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.

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.

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 get much benefits out of these frameworks without the tight integration on the backend.

Are next.js and other similar React frameworks worth looking at if you don't use node.js on the backend?

No, there are many frontend only frameworks.

You need some form of backend if you want Server Side Rendering, and SSR is why most people opt-in to a React framework.

And then you already have a backend so it's an easy jump to just using Nodejs on your backend as well.

But a lot of people also just use NextJS as is and never build any server side code and just run their own API beside it.

Or use other frameworks that don't include any SSR features, such as Create-React-App

> Are next.js and other similar React frameworks worth looking at if you don't use node.js on the backend?

It depends on why you’re doing so. We’ve recently moved from a C# .net backend to a TypeScript node backend and in such a case it (well obviously) makes perfect sense to utilise next.js.

In other cases where you split your front end and backend quite clearly, like using .net APIs and a JS front end it can make sense to use some degree of nextjs if you need to integrate some compiled parts into your react, maybe you need a fast loading and/or front page then it can be valuable to mix it.

If you don’t know why you’d need it, you probably don’t, however.

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.

Nextjs has useful defaults and enough basic elements for front-end.

create-react-app is just a bunch of oppinions on how to config your app that dont really add much productivity if you are already familiar with webpack. Depending on the need I'd either go with react and my webpack config copied from last project or nextjs. Don't see the point of cra

Next.js works well in the case you have a separate possibly non-Node backend with a JSON (or otherwise non-HTML) API.

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/

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.

What amazing news! Nextjs is fun to use, but the pages concept has felt a little clunky. Nuxtjs (vue's version) has a great pages abstraction, but it doesn't nest layouts, like this proposal.

There's some obvious inspiration from other frameworks, as Remix and Angular 2.x have had nested routing for years.

Hopefully this will allow for less repetition in pages and a more elegant structure to projects.

Exactly. Remix creators wrote in a blog post that they inspired by Ember.js. It looks to me people reinvent the wheel all the time. Luckily Ember.js provides all these functionalities for a decade now and just getting better.

Lee from Vercel, happy to answer questions about the RFC or future plans for Next.js. This RFC has been years in the making – and I'm pretty happy with where we've landed.

Excited to try this out in my next project :)

Open to any feedback you have – we've already started work on the implementation, and will adjust as necessary based on the RFC discussion.

Not seeing it in the article, but how are you handling `index` routing in the `app` folder? If you are putting it in the top directory (e.g. `/app/index.js`), is it not able to get a custom `layout.js` file (as that position is used for the global variant)?

If it's in an `index` folder (e.g. `/app/index/page.js`), how would one create a route for `example.com/index`?

The current working idea is that you wouldn't use index.js. There are Layout Components and Page Components, both explicitly defined by `layout.js` and `page.js`. We are open to other opinions here, though. Others have shared similar sentiment: https://github.com/vercel/next.js/discussions/37136

Am I correct thinking this will help create a simpler integration with - just hypothetically - Prisma calls that are dependent on app auth states in a single page? Replacing auth providers and moving them into Layouts?

Daily user, very excited!

Yes, I believe you are correct. This would be a good example to add as the updates to `next/router ` start to materialize.

>happy to answer questions about the RFC

Would love to hear about the parts of the RFC where you guys took some inspiration from Remix!

https://twitter.com/sebmarkbage/status/1528858510754459648

I like that you have thought about incremental adoption. However it looks like you're effectively deprecating the "/pages" directory. Which kind of sucks, as it's much more informative name, than the new generic "/app" folder.

Also, does this mean you cannot have a page named "layout" anymore?

Lastly, I appreciate all the hard work that goes into nextjs, it's a great developer experience and my goto framework.

Part of the thinking behind `app/` is that each section of your application can become its own app. Separate layouts, separate data fetching, and more. `pages/` was mapped very linearly to routes – `pages/index.js` was the index route. But with `app/`, that is not the case.

That's a good point about having a route `/layout` – I will check with the team about that.

Since segments are determined by folders, you should be able to do `/layout/page.js` for a `/layout` route.

I'm excited to see the wheels turning, but it feels a bit like the best feature of Next.js IMHO (SSG) is going to get more difficult, or possibly become unusable. A deprecation feels incoming. It could be confirmation bias as I've been a little worried about that for awhile since people using SSG aren't as likely to buy cloud services, so there's some incentive misalignment there, but ever since the Image component was only supported with SSR it's felt like SSG was going to either become less usable or disappear. Am I the only person who loves that feature? It really revolutionized how I approach web dev and enlarged my imagination of what was possible, so there's definitely some emotional attachment for me :-)

Am I correct about SSG's future?

Naw, I don't agree. SSG is a killer feature. The fact that Next.js is able to do both SSG and SSR means that it's positioned to be a wholesale replacement for most React tech stacks. You can still have a "CSR-like" app with SSG, while having all of the Next.js conventions (such routing, layouts, etc.). Additionally, it's actually pretty useful for sites that need to be heavily SEO-optimized. Next.js is an impressive framework.

Static isn't going anywhere. In my opinion, one the best parts about Next.js is you can blend static with dynamic, on a per-page basis. Your landing page can be completely static + periodically updated in the background (i.e. ISR) and your /dashboard page could be a fully server-rendered application behind auth. You can do both without ejecting from the framework and being able to update and receive performance/security improvements. We've called Next.js a "hybrid framework" because of this, but I don't have a great name for it.

I suspect the fear was about "next export" going away, not the SSG functionality within a next.js server-side app.

Yes you are correct, thanks this is a great clarification!

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`

I never liked it either. At my last job I actually had a system which generated the Next.is pages folder based on a route config. The irony being that at build time, Next would then turn this folder into an internal route config that probably looked quite a lot like mine.

Oh interesting. Why not? Directory and file based routing is my favorite feature of Next.js, Remix, and other frameworks that do it.

It makes route localization a second-class citizen in the framework at best, or a totally unsupported hack-your-own-solution thing at worst.

if it helps, you could use middleware in next.js to handle routing to separate folders easier.

Middleware won't work if you use "next export" to get a truly static site though, which is by far my preferred mode of operation whenever possible.

This is what I meant when I said "second-class citizen at best".

ah I see. Maybe try the route rewriting in next.conf.js? I think thats what the file is. That might work for static sites.

It seems like a path prefix like "/en/books" or "/es/books" could be supported with a base url config.

Localized path segments like "/books" or "/libros" could be supported with a path segment mapping configuration.

It should work fine in theory. I guess those configs don't exist yet. Or is there something else that route localization requires?

I don't like this approach either as maintenance gets complex over time. Changing routes in my React-router project is one file, one commit that's easy to verify, try changing a dozen routes with Next and you end up with a dozen of files moved around, with folder structure possibly impacted as well, I see this as an anti-pattern.

That's true, the pull request diff viewer does not make viewing file renaming very clear and there could be conflicts.

On the other hand, what I see in practice is adding or removing context providers and layout components in the react router file, it becomes huge, and all the diffs change all of the lines with new indentation.

Coming from a React Router background, the Nextjs file structure is a bless to work with

I've worked with both. There are days when I prefer a programmatic approach, and days I love the file-based router. With the introduction of routing middleware [0], Next.js finally offers anything I'd want to build.

An option would be to add a catch-all route [1] at the root and implement your own code-based routing. You can still define the desired paths using getStaticPaths [2] but my guess is that some functionality like route-based code splitting will stop working.

0 - https://nextjs.org/docs/advanced-features/middleware

1 - https://nextjs.org/docs/routing/dynamic-routes#catch-all-rou...

2 - https://nextjs.org/docs/basic-features/data-fetching/get-sta...

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

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.

I'm totally not sold about this.

Next.js routing was wrong from the start, and now it introduces a tons of new concepts that will inevitably require the rewriting of entire apps in a far future, since it will be "the new way to do routing in Next.js".

What I really don't like is the coupling between the filesystem hierarchy and the actual routes, that is difficult to reason about when you have non english routes names with multiple route parameters.

I mean, the routing problem for server side applications was solved a lot of time ago: a simple regex for the route definition, and the related handler that will responde to that route.

I never understood why Next.js guys went with this inconvenient approach of the file system routing.

Looks like a nice improvement, looking forward to trying this out.

Nested layouts was the one stumbling block we had with next and felt very odd that we had to invent our own TabPane component to handle this pretty common use case.

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 <Link to={123}> 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.

I'm pretty sure what they are looking for is that something like a Link that takes a route name and a params object that are both typed.

Generating a set of links from the routing as a union of strings as type Route. And a <Link /> component that only accepts an href of that type.

Like so: https://www.typescriptlang.org/play?jsx=4#code/C4TwDgpgBASg9...

TS' string literal types are powerful.

https://www.typescriptlang.org/docs/handbook/2/everyday-type...

edit: I did implement this a while back but found it gave me only so much additional value. Though I can imagine that large applications with dozens of developers might indeed benefit from type-safe routes to avoid dead links.

That's an interesting idea. Cheers.

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

Shameful ad for our own router: https://swan-io.github.io/chicane, with type-safe route consumption and creation (and other goodies).

No weirdness or magic API, the useRoute hook just return a discriminating union with typed params. It's fully-featured and used in prod.

The API is quite simple:

const Router = createRouter({ UserDetail: "/users/:userId" });

Router.UserDetail({ userId: "xxx" }); // safe

Will there ever be a fix or blessed workaround re: #32216?

https://github.com/vercel/next.js/discussions/32216

previously: https://github.com/vercel/next.js/issues/2581

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

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 javascript VM?

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

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

Next.js Layouts RFC Discussion is Here > https://github.com/vercel/next.js/discussions/37136

> With this RFC, you can start using React features

I’m guessing this should say React 18 instead?

Fixed!

Does this affect in any way the `api` routes? Could these also be moved under the new `app` folder?

Sell me next.js in a tweet sized paragraph. Why should I use next.js?

Easy SEO-optimized and performance optimized pages in a small package.

Quickly develop websites in React. Build statically generated pages or dynamically generated server-rendered pages, and deploy them almost anywhere.

"try to use react bare bone"

looks similar to what Nuxt 3 has

https://v3.nuxtjs.org

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 particular proposal shows a lack of long term vision for the framework, attempting to throw in all the exciting bells and whistles from competing frameworks.

This philosophy of “lets stay relevant” will ultimately cost businesses.

We've been very intentional about incremental adoption and reducing the number of breaking changes, as well as giving folks codemods when they upgrade and providing escape hatches. For example, when upgrading to Next.js 12, which turned on SWC by default, we had already been testing an experimental version for many months which folks could try out. Then with 12, you could opt-out in the config if you didn't want to use it by default.

My comment is probably not super helpful, but after several years in javascript land I found myself exhausted by the churn and constant rapid change. I've found myself really happy to be using the PETAL stack (Phoenix Elixir Tailwind Alpine LiveView) where the pace is a lot slower. There are now similar options in Rails (Hotwire) and Laravel (LiveWire), and probably others. If you haven't heard of those, it's definitely worth a look. The only situations in which I don't use them now are when there's a need for rich offline functionality. I still have several static sites in Next.js that I'll leave in place but I've been a lot happier since shifting my bulk to PETAL. (I'm also close to replacing my last big WordPress site with an Elixir one!! Knock on wood.)

Reply on news.ycombinator.com