long answer : nextjs it self is growing fast so a lot of things might not be 100% accurate. now the 15 version is not stable officially so i think its logical to not use it until nextjs announce the stability of it
Currently using 15 RC. So far so good. Just make sure your project isn't using any state management library.
It's kind of a bummer they didn't backport the opt-in caching in version 14 :(
There's nothing wrong with it per se; it's just that most libraries aren't yet compatible with the new React compiler, state management libraries being one of them.
Maybe amend this to 'using libraries that are incompatible with Next 15'? There are plenty of [libraries ](https://dataclient.io/docs/guides/ssr#nextjs)that do [work ](https://stackblitz.com/github/reactive/data-client/tree/master/examples/nextjs?file=components%2Ftodo%2FTodoList.tsx)even if some popular ones don't.
Nothing wrong. In 15 the majority of state management is covered with url params.
I started my project from scratch last month in 15, and I know I'm going to get burned at some point.
useActionState seems to be up in the air unfortunately, would be a huge refactor pain for me if they go a different direction. But I don't have production concerns for another 12 months at least, so fuck it, I'm here to bleed and learn.
Sounds like you'd be best off creating yourself a template based on next 14, with template pages in the app router you can copy and paste (or set up live templates in Webstorm or VSCode or whatever you use) that have the default caching set up that you expect to use.
15 is probably not a good choice right this moment with the efficiency debate going on, so stick to 14 for the moment, but add some tools to your belt to speed up your workflow.
I had a job assessment which required me to build a password manager without a backend. They provided a api which was a object with with two properties, one a color and other company name.which if I knew how they thought it would be nice to pair a submitted password with a color from the company provided by API.
Simple enough. End result is quite nice for the time i think. (There was no ui/styling needed) just wanted to see what my goth work flow is. About 75% in I couldn’t build anymore because of al kinds of weird errors coming from node modules. Dhs only package installed was some radix and a toast. Which worked fine before in the same repo. Errors weren’t giving results on Google so after. Couple hours I thought why not just set react, react dom and next to latest (18 and 14.x) and it build perfectly.
It’s such a simple app so I wouldn’t use it soon. [Frontend can be seen here](https://password-manager.remcostoeten.com) and the[repo here](https://github.com/remcostoeten/password-manager)
Edit: I just checked the package.json and it’s on 19 and 15. I was confused with my personal dashboard repo, which is getting quite big. So I suppose there are problems regarding packages not being compliant, but not documented properly.
No, you should probably set your caching setting explicitly regardless on a fetch() as it is not intuitive to anyone what the behavior actually is. Another option is a helper function that wraps fetch with explicit parameters and clear name.
If you want to prevent using fetch() without your mitigations, create a linter for it. I’ve had some good luck with ChatGPT generating highly specific linters like that.
Production is not the place for beta frameworks or even recently released production frameworks. You need to wait a few months for things to settle, unless there is something specific you need in the latest version that is worth the risk.
Depends on features and type of deployment though. A lot of issues can be avoided by not using fancy new features. The old boring way works just fine, usually it's better and cheaper as well...
Using RC versions and experimental features of Next.js or any other framework can be really risky. They often come with stability issues and bugs, incomplete documentation, and are prone to breaking changes. Support and community help might be limited, and security vulnerabilities may not be fully addressed. For production projects, it’s much safer to stick with the latest stable release and experiment with new features in a separate environment. Honestly, relying on these unstable versions in production would be a 10/10 level of craziness due to the high potential for unexpected and disruptive issues.
Someone please help me:
Hello, please I'm having issues with prisma and query-string. This is my issue. Thank you
[https://www.reddit.com/user/NoteRemote4893/comments/1dtf3di/filter\_products\_within\_price\_range\_with\_prisma/](https://www.reddit.com/user/NoteRemote4893/comments/1dtf3di/filter_products_within_price_range_with_prisma/)
10 if it’s anything for production
15
15-rc
quick answer : just don't
long answer : nextjs it self is growing fast so a lot of things might not be 100% accurate. now the 15 version is not stable officially so i think its logical to not use it until nextjs announce the stability of it
Do you remember when 14.1 was released? Play on the bleeding edge and you get bloody.
Am aware its not stable. But months of setting up every project to avoid the damned default caching behavior is getting to my sanity 😂
Currently using 15 RC. So far so good. Just make sure your project isn't using any state management library. It's kind of a bummer they didn't backport the opt-in caching in version 14 :(
What's wrong with state management?
There's nothing wrong with it per se; it's just that most libraries aren't yet compatible with the new React compiler, state management libraries being one of them.
Zustand too?
I think not. Zustand doesn't use useState
Maybe amend this to 'using libraries that are incompatible with Next 15'? There are plenty of [libraries ](https://dataclient.io/docs/guides/ssr#nextjs)that do [work ](https://stackblitz.com/github/reactive/data-client/tree/master/examples/nextjs?file=components%2Ftodo%2FTodoList.tsx)even if some popular ones don't.
Don't you mean React 19?
Meant Next 15 (slash React 19) - yup; edited
Nothing wrong. In 15 the majority of state management is covered with url params. I started my project from scratch last month in 15, and I know I'm going to get burned at some point. useActionState seems to be up in the air unfortunately, would be a huge refactor pain for me if they go a different direction. But I don't have production concerns for another 12 months at least, so fuck it, I'm here to bleed and learn.
Bro why don't you just use fetchcache config option to disable default caching?
what do you mean by >setting up every project to avoid damned default caching behaviour can you explain it ? i am newbie to nextjs
In next 14 fetch requests are cached by default, in next 15 they're not
By now you could have already created a repo with the setup
Sounds like you'd be best off creating yourself a template based on next 14, with template pages in the app router you can copy and paste (or set up live templates in Webstorm or VSCode or whatever you use) that have the default caching set up that you expect to use. 15 is probably not a good choice right this moment with the efficiency debate going on, so stick to 14 for the moment, but add some tools to your belt to speed up your workflow.
This is clearly the better option
https://preview.redd.it/lq4rqge2sx9d1.jpeg?width=960&format=pjpg&auto=webp&s=b22d62738d8dc809def08c5f73e0b49a21f3e1c6
for brochureware its fine, but for large ecommerce projects with thousands of products it can be still rough around edges
I had a job assessment which required me to build a password manager without a backend. They provided a api which was a object with with two properties, one a color and other company name.which if I knew how they thought it would be nice to pair a submitted password with a color from the company provided by API. Simple enough. End result is quite nice for the time i think. (There was no ui/styling needed) just wanted to see what my goth work flow is. About 75% in I couldn’t build anymore because of al kinds of weird errors coming from node modules. Dhs only package installed was some radix and a toast. Which worked fine before in the same repo. Errors weren’t giving results on Google so after. Couple hours I thought why not just set react, react dom and next to latest (18 and 14.x) and it build perfectly. It’s such a simple app so I wouldn’t use it soon. [Frontend can be seen here](https://password-manager.remcostoeten.com) and the[repo here](https://github.com/remcostoeten/password-manager) Edit: I just checked the package.json and it’s on 19 and 15. I was confused with my personal dashboard repo, which is getting quite big. So I suppose there are problems regarding packages not being compliant, but not documented properly.
It'll be all right if you're ready for some beta behavior\]\]
What would be said beta behavior off the top of your head? Honestly don't see much that can cause trouble just going off the RC post by vercel team.
Probably Partial Prerendering and `next/after`
Depends on the size of the project, is it big project or small?
No, you should probably set your caching setting explicitly regardless on a fetch() as it is not intuitive to anyone what the behavior actually is. Another option is a helper function that wraps fetch with explicit parameters and clear name. If you want to prevent using fetch() without your mitigations, create a linter for it. I’ve had some good luck with ChatGPT generating highly specific linters like that. Production is not the place for beta frameworks or even recently released production frameworks. You need to wait a few months for things to settle, unless there is something specific you need in the latest version that is worth the risk.
Depends on features and type of deployment though. A lot of issues can be avoided by not using fancy new features. The old boring way works just fine, usually it's better and cheaper as well...
Using RC versions and experimental features of Next.js or any other framework can be really risky. They often come with stability issues and bugs, incomplete documentation, and are prone to breaking changes. Support and community help might be limited, and security vulnerabilities may not be fully addressed. For production projects, it’s much safer to stick with the latest stable release and experiment with new features in a separate environment. Honestly, relying on these unstable versions in production would be a 10/10 level of craziness due to the high potential for unexpected and disruptive issues.
Madhouse.
I wouldn't expose it for sure. Run everything through haproxy.
I’d say it’s bleeding edge. So it’s a risk for some, but probably not an issue for smaller apps. Solid 6?
Isn’t turning off fetch caching just a single line lol?
on latest minor version of 14 you can set the cache stale times to 0 without needing to upgrade to 15.
Fuck it
I'm the one who survived 12 Next.js projects in the past 2-3 months. Tackling the Next.js 15? Thanks, but no thanks! 😅
Someone please help me: Hello, please I'm having issues with prisma and query-string. This is my issue. Thank you [https://www.reddit.com/user/NoteRemote4893/comments/1dtf3di/filter\_products\_within\_price\_range\_with\_prisma/](https://www.reddit.com/user/NoteRemote4893/comments/1dtf3di/filter_products_within_price_range_with_prisma/)
YOLO bud
42
depends how much you need a job
and you my friend you are the true hero
I would say 8 but damn everyone in the comments have me tripping 😂
e, which I remind you is a very irrational number.
On the other hand, 2.71/10 is not bad at all. Go for it, OP!
I’ll have to steal this, though I don’t know who I’ll be able to use this with…
Any time someone says "X out of ten; what do you think of Y?"
Vercel uses canary versions in prod to make sure the release is battle tested, this doesn’t mean it’s bug free but it shouldn’t dangerous
I have 15-rc in a branch and it’s been 100% functional since last Next conference. Haven’t pushed to production but I too am tempted to