It's hard to take Vercel at face value these days with all of these improvements and announcements. Are we supposed to - in hindsight - understand that odd version numbers of their codebase were really just unstable releases all along? The app server implementation wasn't really meant to be used because it was an experimental release?
I'm having a difficult time not being salty about this entire situation. There are basic production requirements that haven't been addressed for years because their hosting platform provides it. You don't like the way they do logging? Sounds like you need an attitude adjustment.
I stopped paying attention when someone recently told me that everyone uses nextjs because “nextjs is meta right now”. Mind you this person has been a developer for about 3 years (not that there’s anything wrong with that but it gives you an idea of whose buying into this stuff)
Vercels devrel is by far the best thing that they do, miles ahead of their engineering.
What's wrong with that? I have no illusions that Next.js is part of a larger strategy to get me to pay money for services. I feel the same way about VSCode and Azure, or Github and Copilot, etc. I don't have any problem with paying money for products that deserve it.
I am not arguing that it is not. I very much agree Next is a product because it very much fits its definition: "an article or substance that is manufactured or refined for sale.".
But this is wrong by definition: "Many types of software are also products, whether they're VC funded or not."
well to me part of the reason to identify "the meta" is not to go along with it, but so you can develop tactics to counter it -- but maybe not everyone thinks that way
Really though, it's not true that "everyone is using nextjs", so it's not "the meta" anyhow. I think most developers can safely ignore it
I think anyone who says everyone uses X now exists in some kind of bubble when it comes to technology.
I don't want to counter their point just for the sake of countering it but if a person's only supporting argument for using a tool is "everyone uses it" there isn't much of an argument to be had in the first place.
I read the release notes but don’t understand what you’re talking about re: app router. They mentioned that they’re still supporting app router and pages router.
Correct, the Pages Router is very much still supported with new improvements being made. The performance improvements in this post apply there. The same APIs and features included in Next.js 1.0 still work today with the Pages Router.
One weird issue I had with next 13 was radio button groups did not work. The suggested fix from a core next contributor and fb employee was to "Upgrade to a canary release"...
I get that you are building all these new cool features, but that cannot put basic functionality and backwards compatibility at risk. Radio buttons have been around forever, I'd assume that they are being used by tons of websites all ove the place. Yet hydration of SSR radio buttons was not being done properly and so you could not set a default value for your radio button...
This kinda shit is just basic. You can't add new features at the expense of basic functionality.
Absolutely, this is the number one issue I have with next.js - they did a huge ecosystem-splitting update, but now recommend switching to the new paradigm for any issues with the old all while saying they are maintaining the old.
Which issue? There are certain issues that are non-issues in the App Router, and simply not possible in the Pages Router without a significant amount of foundational changes. Which, those changes are, the App Router. That’s why we’ve been focusing on making incremental adoption easy. I think there’s still room to make it smoother (hard navigations between pages/app, metadata codemods for next/head) ad well.
The reason we suggest upgrading is because it’s extremely common that issues are already fixed or they cannot reproduce when we ask them to upgrade. It helps with issue triage so we can properly prioritize and fix issues.
If you can link the issue with a reproduction, I’m happy to look into it.
Generally, the expectation is that developers know what bugs have been fixed or can quickly check, so users aren't expected to just constantly retry on whatever today's HEAD is. That takes a lot of their time, and you already know what changes you're making so should be able to determine quickly if a bug was fixed.
My ongoing concern with Next is the Vercel's team unresponsiveness to page-breaking bugs coming off of features marked "stable" and in the docs.
Lately, it seems like most issues aren't even being acknowledged. It's pretty frustrating to encounter a bug in a documented use case, spend hours trying to fix it, realize it's a Next issue that was filed months ago but has yet to receive a response from Vercel, or to have reproduced and explained the issue and be ignored for months and counting.
The issue count at Next is huge, and I'm sure overwhelming, but if you're going to hype "stable" features that are beta at best, there ought to be some measure of support (or at least acknowledgment) for when they don't work.
People invest their livelihoods in these frameworks, and false claims are damaging. I'm currently knee deep in a project that can't budget a rewrite, so I'm just hoping someone at some point notices these issues and they get fixed. Not great. I've yet to encounter a project that calls features "stable" as carelessly as Next does. I've never felt so burned by open-source marketing.
If I was starting a new project today, I would stay away from Next.
I'm sorry that we haven't been able to respond fast enough. Hundreds of issues are opened every month, and the rate is increasing. We're working hard to try and triage as best as possible and hopefully hiring more folks to help out as well, too.
Could you share the issues you're running into? While there's going to continue to be bugs and things to improve in the framework (it will never be "perfect" or "done"), that does not mean that it's not stable. We mentioned in our conference keynote today that 8,000 of the top 1 million sites on the web are now using the App Router in production.
Regardless, we want to keep improving. It sounds like you have had issues with the Pages Router specifically, and not the App Router, as you mentioned budgeting a rewrite. Is that correct?
Hey Lee, thank you for replying. It's nice to be heard! I know that everyone is working hard, and no software of Next's ambition is perfect, much less at this stage, but all the same, I think there's a threshold for stable that isn't being met, and I think that's doing your users a disservice.
The issues I'm experiencing are for the App Router. Namely, and to keep things reasonable scoped, with parallel routes. These are being recommended for common use cases, but a lot of things are broken along their way (along with intercepting routes)... I'd recommend searching issues for the full breadth, but here are a few that jump to mind:
Parallel routes don't unmount if navigated from with anything other than router.back()... this might be a documentation issue, as I recently got this to work as expected in one case with a null page.js at the root of the parallel route:
https://github.com/vercel/next.js/issues/49662
Speaking of CSS Modules, they import multiple times in indeterminate order. This breaks precedence and the cascade, making styles indeterminate. There are hacks that mitigate this, but even with the hacks it causes problems:
https://github.com/vercel/next.js/issues/51030
These aren't exactly edge cases, and to get at the heart of my complaint, they haven't been acknowledged, or haven't been followed up on for months, despite being marked stable. I don't mean to suggest that you all aren't doing the best you can, and I certainly don't mean to suggest that you can do better technically, but as a user it's concerning to get in deep and continually run into beta issues on what's meant to be stable, and be in the dark as to when they'll get resolved, much less if the team is even aware of them.
I'll add, it's kind of baffling to hear that things are stable, there are just ton of issues you can't get to.
I'd posit that Next has a ton of users, and a ton of issues, because it prematurely marks features as stable, and then markets them aggressively. Instead of working through these issues in beta with a manageable number of early adopters with aligned expectations, Next gets more than they can handle, frustrated that features sold as production ready are not. This, to me, is a questionable business strategy, not a sound technical one.
The general direction React (+ Next) is going worries me a bit at times. I might be too conservative, but I want my JS on the frontend and not hot loaded from the server. For this reason I'm much more excited about Vite/Bun/Dino/etc. Also thank god for shit like Preact.
> I want my JS on the frontend and not hot loaded from the server
I'm fascinated by this. Literally, in every other HN thread in existence, you find stadiums of people shouting that they hate slow-loading SPA pages, and that all the work should have been done on the server, as God intended. Only on the release of Next.js 14, of all things, do you find people saying that actually SPAs are great and SSR is a regression!
You're falling for the trap Vercel laid by having RSC co-opt the concept of SSR.
People are complaining about server components and the machinery to enable them: but those are actually unrelated to SSR.
Client components are rendered on the server.
-
SSR was the sane middleground that worked since Next.js 1.0: You generated some content, and the frontend had all the Javascript and used that content to give a snappier SEO friendly experience.
Next then turned around and convinced everyone that this wasn't good enough, and you actually want to try and have the server take chunks out of the Javascript your frontend has so that a bunch of metrics that they inflated the performance of would improve.
For people with medium and high end devices, SPAs are mostly fine. For those with low end devices (which is a large part of the world), SPAs sometimes don't work well and this is true of many UI frameworks.
Real human beings benefit with you ship less code. And, if people are paying for data, which a lot of people still do, this matters.
Impressive to try and moralize this, but as someone born in "the large part of the world" you're aggrandizing for the typical project made in Next... I assure you that shipping a basic non-React project will be infinitely more appreciated than what RSC is enabling when combined with the style of frontend React encourages even if you do just render it down to a string.
> Real human beings benefit with you ship less code.
Real humans beings benefit from reliable and well-made applications more.
The difference between an good engineer and a truly excellent engineer is understanding how "worse" technical choices can result in a better user experience.
Junior engineers obsess over low level metrics like how many lines of code they right, but for some reason people graduate to obsessing over how many bytes of JS they shipped and don't think for a second:
- "how much of a surface area did I just open up for bugs in my chase?"
- "how much productivity spent catching up on this new paradigm would have been better spent making what my users want and need rather than tinkering with implementation details?"
- "how is adding this convoluted multifaceted multistep approach with an unstable technology going to affect the stability of my application?"
- "how much harder did I just make it to solve the bugs I do know about due to indirection?"
You're shipping less code down the pipe but you're dragging in insane amounts more code at every step of the way from compilation to the server runtime to enable it: the net result is a buggier, more complicated, less reliable application.
Of course, when you make money off people not thinking about this stuff, you don't encourage discussion of it.
What is wrong with that? I agree that Next 1.0-12.0 SSR was great. But, you were always shipping a ton of JS that may never be called for components that don't have any interaction. NextJS 13 now only ships what JS is needed.
The framework is called React. As in Reacts. RSC is a standard that makes it so that, by default, a component will break your build if you try to react to state.
It's not until you brand it with a "use client" directive, which doesn't opt out of SSR despite the intentionally deceptive name, does the literal basic tenant of React work again.
The RFC literally states libraries should embed this directive to not break builds: that means Vercel managed to fund an effort that breaks the underlying value proposition of a decade old framework by default
The part about including "use client" by default is referring to component libraries. e.g. you don't want to import <ReactPagination/> and have it break because it uses useState. When writing your own components you can decide which need to be marked as client and which don't. I don't think NextJS is doing any harm by not magically including "use client" on your own files. I agree that it is confusing to be called "use client". Maybe "use interactive" would have been better, but regardless the "use client" directive is from React so I'm not sure why it's related to a complaint for NextJS.
I pointed out that the directive is for libraries, and stated the framework React is built on reactivity. The vast majority of the ecosystem is built on using state.
Didn't realize I needed to put this together for you, but that means the vast majority of the ecosystem defaults to breaking your build.
_
And frankly, I really have to question your understanding of the topic when you say things like "NextJS is doing any harm by not magically including "use client" on your own files"
Vercel drove RSC home for Next.js. Shopify tried it (because eCommerce) the effort petered out, and then Next.js, needing a bullet in the chamber against Remix and Hydrogen went and dragged a half-baked concept antithetical to the underlying technology over the finish line.
Next.js is still the only actual implementation of RSC: Remix tried it and wrote it off for very obvious reasons... since Vercel/Next.js got to write the framework side and the implementation, there are a massive number of gaps in the standard.
Your comment sounded like you expected NextJS to add "use client" to everything to prevent it from breaking, I misunderstood, which is what my comment was referring to. I see that you mean they funded this effort that results in other libraries breaking. You may want to consider using more precise language instead of questioning others intelligence, it really isn't necessary.
I questioned if you understood the topic of my comment, and you replied that you misunderstood the topic. Jumping from that to somehow being an attack on your intelligence is ridiculous.
Also not sure how much more precise I can be in saying "they funded this effort" than my original comment which says "Vercel managed to fund an effort"
Yeah: an pre-alpha toy project, and a blog post. Dan Abramov shipped a toy implementation too in a blog post right, I think you missed that?
When I said actual I meant it. RSC is a Next.js feature baked into React.
PS: I'm not the target market for Vercel, Mr. Robinson. I think you can skip the damage control for my comments: I don't have your reach so maybe just pretend it's an old man yelling (very truthful things) at the clouds, it can't actually hurt your PR machine.
No, we only want JavaScript for the SPAs, nothing else.
SSR has been doing just fine for the last 25 years, now we have to put up with Next.js, due to the ongoing partner agreements Vercel has been doing to push Next.js as the only framework in MACH products.
> hate slow-loading SPA pages, and that all the work should have been done on the server
I'm not disagreeing with this actually - but I've also never been a massive fan on SSR for React. In addition - NextJS goes further in inhibiting React functionality - for instance: useLayoutEffect doesn't work at all.
What worries me are the partner agreements Vercel is making with several enterprise products, making Next.js the only official frontend stack for their products.
With everything else being DIY integration, and lesser tooling.
I think for me the saving grace is the pervasiveness of the React paradigm. Porting code from React to Preact (obvs), Vue3, Stencil or Solid is easy peasy because the patterns are the same. And thanks god for that.
EDIT: Honestly a web components framework with 1-to-1 likeness in API would be first class. I'd jump immediately.
That would be because their goal is tooling and not to be a framework?
Bun is the worst example here cause it's literally now a runtime for Javascript! If rewriting all the Node APIs, directly executing TS files etc. isn't pushing a "paradigm" I don't know what is.
Next.js and Vercel are the same company. This means that the projects are susceptible to conflicts of interest. For example, pushing the server side forward while degrading the client story is the exact result one may get when such conflict is in effect.
I'm sorry if this sounds too dark or unwarranted, but this playbook is too old to be dismissed.
I think I'll be taking a step back from React/Next.js for the foreseeable future. I feel fortunate in that, for most of my projects, I can make architectural decisions such as this. Things took a turn with hooks (I have a feeling that's the general consensus, too). The nail in the coffin (at least for me) was React Server Components.
I gotta admit that its been liberating working outside the javascript/react realm. Using Go + HTMX + [insert tool here] has been a fairly easy transition. Is it a 1:1 replacement? No. Does it solve most of my use cases whilst providing a better developer experience? Absolutely.
I'm not trying to hate on React here. I just think its time to stop and ask ourselves "is this REALLY the best idea/tool for xyz?".
As someone new who started with NextJS v13.4 on AWS, I am also disappointed that AWS/GCP/Others don't support all of Vercel's features. That being said, the commenters here are being unfair and unreasonable.
NextJS 13.4+ is nothing short of incredible. Are you telling me I can get a free, faster, opinionated, React implementation with 10's of finicky/unreliable/3rd-party Node_Module dependencies now seamlessly baked in for free? With a unified/simple build process too?
NextJS is nothing short of a lifesaver for small/indie web dev teams!
I do have my struggles + bloat + bugs using AWS instead of Vercel to host, no doubt, but that's out of my own cheapness/stubbornness. Vercel is not a charity, its a business -- I'm disappointed by commenters here basically complaining they don't "work for free".
Don't use tools that have turned into a product where they have people trying to lock you into whatever platform or any service they have. These aren't just engineers trying to help other engineers solve problems. These are marketeers trying to sell you hype.
Really not interesting for us. Makes what’s simple simpler and what’s hard harder. Sure for a quick prototype website with 10min only that would help, but any decently sized app that needs auth/localization/high performance in memory/offline/optimistic updates/batch fetching … all become way harder. It feels like react unchained from Meta’s constraints and it looses its appeal.
Which part of this release do you find more difficult? For applications that need those dynamic constraints, like auth and personalization, we’re working to make this even easier starting this this version.
This version also includes stability for Server Actions, which includes a hook useOptimistic for optimistic updates.
I agree the offline story isn’t great today and we could do better there.
Thanks for checking with us. SSR makes auth based routing harder as well as any faceted renders like localization (because now not only the cli needs to query the api, but also the rendering server, with all the CORS/security config that goes with it). Offline is obviously harder. Integrating some specific build features like css pre processors are harder too, as the SSR needs to hook itself up in the build process in very specific ways. The mixed approach with pages/ and apps/ makes it so hard for 3rd party supported libs: mantine 7 wants to sit in apps/ ad that was the only way their css preprocessor could hook cleanly with nextjs whereas the previous version wanted to sit in pages/ etc. Sharing components with our emailing platform isn’t possible anymore. It only runs on web now.
I understand the need as a business to address more use cases that buys servers. But as a current user, upgrading to a new nextjs has been mostly painful and unrewarding.
We've had an awful experience with Next. There are undocumented, broken things all over the place. Migrating to the App Router was a huge mistake. 'use client' didn't work as expected, and we had to install workarounds and try out different hacks to get access to the most pedestrian features we could expect from any other web framework.
This is the broad consensus among everyone else I know using Next - they felt like the Next 13 release and the app router was a rug pull from a previously pleasant experience.
And whenever you complain about this or ask for support, some devrel guy from Vercel shows up in your replies, saying something to the effect of "Wow! That's crazy, we worked really hard on Next 13! This is my first time hearing about this!"
Edit: Since I know the devrel guys are in this thread: If you want people to keep using Next, something fundamental about how you guys write the framework needs to change. The instability and lack of documentation makes developing with your framework a massive pain in the ass - anyone I know who can is migrating off it as quickly as possible.
It's like the devs never tried building anything real with their own framework. Internationalisation support was dropped in the app router and the docs just tell you to DIY... but just to make the app support RTL languages you need to do some hacky things to update the <html dir="rtl"> in the root layout.
I’m sorry you haven’t had a good experience. And if you more specifics if anyone on the Next team replied to you in that way, please let me know.
I’ll be the first to say the launch of the App Router could have been smoother. Definitely not the first time I’ve heard the feedback. I’m optimistic Next.js 14 is a step in the right direction based on this.
What do you feel is undocumented? I’ll get that added.
Can you share a bit more about what you're trying to build? Is there a specific library you're wanting to have in Middleware versus putting it in a layout or page (which does support all of Node.js)?
Not trying to be offensive here and you're getting a lot of flak already, but these two issues are pretty self-explanatory...
It's a matter of configuration, it feels bad in the first one that a configuration is not possible if so desired and even worse having to jump through hoops in the second one because the edge runtime is enforced which one may not care about if all that's done for hosting is `next build` followed by `next start`
- more comprehensive documentation & tutorials around your own MDX solution would be great. It feels like you put that together, but don't intend anyone to really use it in production, expecting people to go for next-mdx-remote or mdx-bundler
- fix internationalization: I've heard multiple people complain that you now can't do mydomain.com/blog/first-post & have the French version at mydomain.com/fr/blog/first-post. Instead, you need to put everything under a locale, so the English version needs to be mydomain.com/en/blog/first-post
...just in general, it would be nice to see more documentation & tutorials for next 13 / 14 and the app router. People are also not very responsive on github, it feels like you are just moving forward, without waiting for anything to be stable.
I'm currently investigating the feasibility of using Next.js for a major refactor of our service and the one thing that stands out to me is how fractured the Next ecosystem is. More than 6 months after the App router was introduced the most important libraries are still in beta and don't have conclusive documentation for integrating with App dir.
For my projects localisation is a necessity. I tried both i18n and next-intl and found them both lacking in functionality, buggy and missing documentation. This should just be part of the framework or at least have a tighter integration.
The same story with next-auth.js, which confusingly still exists while promoting https://authjs.dev/. For the most basic implementation it probably works, but the app router documentation is spliced into the normal documentation which creates a whole lot of ambiguity.
There's been a lot of discussion surrounding caching for Next.js 13 as well. I personally find it confusing and the behaviour described in the documentation regarding revalidateTag/revalidatePath and client-side caching does not match my real world experience. I would love some more documentation regarding user-specific caching as well, for instance with personalised user dashboards.
It feels a bit ridiculous to release Next.js 14 today as we're still getting used to Next.js 13. And though there might not be any big/breaking changes it creates a feeling where Vercel is racing forward without keeping other library maintainers or its users in mind.
You can continue to use the Pages Router until there's broader ecosystem support for the larger React changes like Server Components. You don't need to use a library to handle localization or i18n.
i18n was part of the framework in the Pages Router, but it was limiting. We heard a lot of feedback that folks wanted better access to the raw primitives versus an opinionated i18n setup. So now you have full flexibility when using Middleware https://nextjs.org/docs/app/building-your-application/routin....
NextAuth.js just released a new beta version with full support for all App Router features, including Server Actions. It's what we're using in the official Next.js Learn course that teaches authentication https://nextjs.org/learn.
We mentioned this in the keynote today at Next.js Conf, but it wasnt in the Next.js 14 post, but next we're working on simplifying caching. We do now have extensive documentation on caching, but it kind of highlights that it's a bit much right now https://nextjs.org/docs/app/building-your-application/cachin....
Next.js 14 doesn't have new APIs to learn, so if you're learning Next.js 13 (which I believe you're referring to the App Router model), nothing changes. The major version is for semver, because there's a few small breaking changes like bumping the Node.js minimum version. We have some codemods https://nextjs.org/docs/app/building-your-application/upgrad....
I'm part of the team from inlang, we are developing solutions to make i18n both easier and more efficiently (e.g. with a web editor, vscode extension and CLI to automate your workflows). Our ecosystem is agnostic to every stack which means it can be integrated with every tech-stack out. We even have our own i18n library called paraglideJS.
Hard to say specifically, especially because I spent about a month trying to deal with this when we first migrated from Next 12 to 13 - but it essentially seemed that if you were using any web tech that wasn't built with SSR in mind, there were issues that were unaddressed in the documentation at the time.
Someone else in these comments mentioned:
- Fuck spending 3 hours working out why you’re not able to use relative image paths in MDX files and have to shove everything in /public.
- Fuck fighting five layers of configuration and bundlers and libraries and GitHub issues to try and load a WASM file without having the whole thing break.
These were both issues we had to deal with, and similarly lost many hours to trying to resolve.
At one point you guys seemed to have shipped a release that, for some large fraction of users, caused the devserver to start OOMing rapidly. When this started happening to me, I spent about a day trying to debug it, since I assumed that such an a huge and imminent issue would arise from my mistake, not the web framework's. I eventually texted a friend of mine about the problem, only for him to tell me that they had been having the same issue, and linked to this thread.
Working with a web framework that's so unstable that fundamental features like the devserver break periodically isn't fun. I stop trusting the web framework, and when a bug arises I find myself having to check both my own code and Next's. Now this applies to some degree with any open source framework, of course - there's bugs in everything. But I have so little trust for Next at this point. We've collectively lost weeks of eng hours to just dealing with quirks of Next.
Right now we're really affected by the fact that the recommended way to cache database connection objects is broken in our repo (and some other users' repos, evidently).
This is another example of something where I naively assumed that the error was on my end, and spent days trying to debug our database configuration, hosting provider, etc, before realizing that at some point something broke and the recommended way of persisting these connections on the global object doesn't work anymore. What's the point of using a framework if I have to question whether it's working correctly every time an error arises?
I gotta say, your responses in this thread more or less typify the interactions with Vercel devrel that I complained about in my parent comment. Every time I, or someone I know, complains about Next or try to raise an issue on social media, you or someone else at Vercel shows up asking for more info. If we give you any info we get a polite "Ah thanks for letting us know, yeah that sucks!", and nothing is done, as far as we can see, to address the issues we brought up or course correct Next's development.
I plan to look into the issues that you mentioned in your previous comment. I'm sorry that I can't get to it today, but I will follow up on those issues.
Correct, I'm not sure what problem you're having but here's an upbeat response nicely stating it's not Vercel's fault, and/or explaining why it's not a real problem.
Honestly, I've had a great experience because I've read a lot of experiences like yours and stuck with pages router & Next 12, which works nicely for everything I've needed it to do.
There might be a point where app router is stable & smooth but it's pretty clearly not right now, so havn't really seen the need to upgrade. I think there was a pretty decent comms issue with the stability of it from both the Next and React teams, but I have a hard time faulting an otherwise fairly stable and useful framework for adding features when they're not breaking the existing stable path.
Hooks was a bit of a bumpy transition as well, but I do think that I prefer the code written with them to the code before them. I think it's OK to wait a year or two to let the rough edges get filed down when these types of frameworks release big new feature sets.
Edit: I'll note that we don't use next/image or API routes either, both of which I've seen some churn / pain with. Possible I just hit on the framework when it was in a pretty happy place and most of the new features or suggested defaults have had pain points that I havn't experienced.
Remix is like the Next.js Pages Router + a helper similar to Server Actions. It does not support Server Components (what the App Router uses) and they're exploring using RSC in the future. So definitely different.
For example, `getServerSideProps` in Next.js is the same as a `loader` in Remix.
Astro probably, if they want to keep using React components.
Otherwise they might also be looking at Nuxt, Sveltekit or Solidstart, but if they're switching top-level frameworks they may as well use Astro because they can mix and match React/Vue/Svelte/Solid
I've been out of the web-dev game for a while, and have been pretty blown away by how much has changed. Suddenly, it seems like everything is a 1-page application, SSR, and doing a lot more on the client than I was used to back when jQuery was the standard. Next.js seems like a pretty beginner-friendly way to get a lot of the "new stuff" without having to learn the multiple technologies in a MERN stack.
On the other hand, it seems like a lot of folks (particularly in this thread), think of Next.js as a well-intentioned, but unstable shiny toy that more or less breaks when you try to do more complicated stuff. Is that accurate? If so, what is the standard stack that most companies are using these days to build high quality web apps?
heh yeah it seems like there's a lot of hate here for a release with only 4 bullet points. I'm using NextJS to learn react for my own interest (i don't do front-end work like this at work) it seems reasonable enough to me. My biggest complaint so far is getting use to everything being named page.tsx, layout.tsx etc and directory naming conventions having so much control over functionality. Otherwise, it seems like a typical Nodejs stack with Express abstracted away and React included.
I'm confused by next.js, and previously considered vercel to be an AWS wrapper with a nicely styled website and some high level APIs over AWS. Any opinions someone could provide about what the value prop of these libraries/companies are?
I dont see many real technology companies running these stacks, more so barely funded startups
React is a pretty narrow framework. It focuses on the components and doesn't really dictate how your app should be structured, which is part of why it's been successful: you can adopt it gradually and replace pieces of an existing app with it, until eventually your whole app is React.
Next.js is a framework built on top of React. It has a more defined structure for things like routing, and it provides useful tools for server-side rendering. It is definitely used in production by major companies and not just by "barely funded startups."
Vercel makes Next, among other popular JS and serverless offerings, and they offer various managed hosting services. I don't use Vercel's paid offerings, but they strike me as operating in the Heroku space, where they make it easy to get a simple app off the ground.
I think they were thinking of the App Router becoming stable a few months back, and that was kind of the main feature of 13 I'd argue. Personaly that's when I migrated my codebase too and was a little shocked to hear they are already releasing a new major version.
Yeah they have 14 versions in 7 years, 2/year. Angular has 15 in 7 years (counting ang 2+), so it's a close race but Angular is still coming out ahead.
How does this offering (and other serverless postgres) do when there is a ton of data and read/write happening? In my case the most data I've dealt with had a few tens of billions of records.
I haven't really worked on small-ish scale things until starting to work on my startup.
I've always depended on managed postgres, and I use Go for all my services. I don't really have any experience using things like Vercel that combine UI + some kind of backend.
Are these technologies meant for use on "large" platforms or are they mainly targeted towards small / hobby SaaS? Would love to know more!
Vercel definitely pushes combining your backend into NextJS. It's probably a lot easier for beginners (Reminds me of all the tutorials pushing the MERN stack years ago) and also allows them to sell them on their managed hosting. However, you do not need to use NextJS as your "backend" like that. I'd assume most real apps are not doing that, you don't want your data access and logic coupled with your rendering code like that (whether it's NextJS or any other templating engine).
Basically rather than making your DB calls directly in NextJS server side code, you can make an HTTP call to your API written in Go or whatever. This is how I've used Next for years and it makes a lot of sense. One common API for the website and mobile app. NextJS just becomes another consumer of the API. It does feel a little bit funny that your server-side code is calling your API, but think about any large tech company where there are layers upon layers of APIs that every request is flowing through.
i guess 'possibly' the holy grail could be the laraval/rails/django mental model of serving routing and page behavior from the bandend, however using the same language for back as front and having things linked up in a typesafe way. wouldnt be perfect for every situation but would have a good mental model when youre developing a web app type of product where there's little distinction between front and back and theres only one client in mind for consuming server behavior.
Now with htmx, you can actually just generate the html in the backend and send the fully formed stuff to the frontend. No need to JSON-Api-fy everything first, then de-jsonify again in the frontend.
I stick with backend development personally, but I will say that their new Server Actions look super handy for quick development. We've used TRPC for that currently and will probably continue to do so, but I really like the concept if you're keeping your API purely isolated to your web app. The fully stack type safety and communication wrapping seems great.
I agree. RSC is extremely powerful and impactful, compared to everything that has been going on for React since hooks. It is easy to understand as a concept, and it allows for proper composition of features on the server side. In fact it's remedying a lot of unnecessary complexity that React brought originally. RSC is what allowed me to accept doing SSG at all.
Server actions seems like a neat idea. Probably does nothing for large projects, but at least IMO it can be very useful for the smaller use cases.
Looking at this i am so happy that i am still using my own component framework. In combination with a nice bundler like parceljs only 100kb for an entire frontend application. Less than 10ms to render a webapp. No trillions of layers. Just a page/render engine and small components like panels, buttons etc.
Why would you need all these fancy provided by next and other frameworks? In the end you constantly face limitations and performance issues.
Anyone using Next.js in production? Can you speak to the resources needed or optimizations to reduce said resources? I'm worried with how much lifting the server does that, it could rack up a pretty hefty AWS bill if I'm not careful.
I run a large production app on NextJS and the resources needed for it are tiny in comparison to everything else (actual backend services doing heavy lifting). Rendering some HTML on the server is not intensive.
Correct. Same price and limits. It’s just making integrating it into Vercel. So you can get Postgres/Redis/object storage and more with your frontend, in one bill.
That’s great! There’s nothing wrong with a convenient integration. For me personally, even as a happy Vercel user, it makes the service more credible as a competitive option.
Fuck the image component, and not being able to optimise your image unless you use their cloud service for no reason at all.
Fuck spending 3 hours working out why you’re not able to use relative image paths in MDX files and have to shove everything in /public.
Fuck fighting five layers of configuration and bundlers and libraries and GitHub issues to try and load a WASM file without having the whole thing break.
Fuck some half-assed play at being a static site generator and a backend framework, that conveniently works best on your overpriced cloud service.
> This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
This is gold level comedy. I am not sure how no one in the tech industry is seeing this.
It really is counterproductive. If projects are going to take months to work on critical issues, they need to change the definition of "stale" to match, or just not auto-close issues at all.
It accomplishes nothing and obscures the sign posts that would help the next developer that encounters the same issue.
I recently tried to rebuild my Jekyll blog with Nextjs. This felt way too hard for something that was basically a nunch of static pages, but I pushed through and ignored that feeling.
This, though? It's confirmation that my type of use case wasn't a priority for this library.
Ah this was me when I moved to next 13 and finally said fuck it and moved back to plain templates and some webpack (for ts for doing non ajaxy js). Even as a backend/platform I actually gave the modern JS ecosystem a really decent try (about 2 years on next/react alone). And before that I had written fairly complex fe code in typescript (granted these weren't doc oriented apps but were more like IDEs). The moment I had to serve static-ish sites the complexity just ballooned!
No that's not true! Svelte is a standalone project. Rich Harris, the founder and face behind Svelte, is paid by Vercel to work on it full-time.
From the same link above:
>> "Joining Vercel enables Rich to work on Svelte full-time, giving the project its first dedicated contributor. The governance of Svelte does not and will not change – it's still the same independent, open-source project and community. With Vercel's backing, Svelte can get even more ambitious."
I know Rich Harris explicitly says, at least when Vercel ownership comes up, that he has a lot of leeway and total control of the project; is there any reason to think that Vercel will force Sveltekit to adopt similar things as Nextjs?
The image component works fine when self-hosting, I use it on several production sites. What is it that doesn't work well without their cloud service?
The default bundle size is also nowhere near 1MB. Next 13 and server components entire point is to reduce the bundle size by not shipping JS that is only ever called on the server.
How do I optimise and convert all my static image files to webp with a PNG fallback, then render them as a srcset so the client can pick the best image?
I.e everything that’s done here[1]
Oh no. You can’t. You need to set “images.unoptimized = true” and be happy about it if you’re not using a cloud image service.
I'm not sure why this is your experience, but the site I am referencing does exactly that. The images are even being pulled from an external domain. They are not PNGs but I am not sure if that makes a difference (they are 100 quality .webp), they get optimized to a lower quality and have srcset, no vercel involved because I do not want a dependency on Vercel.
You just use the image component and specify the sizes. The png fallback is provided via the server looking for the Accept header so when it supports webp it gives you webp, otherwise you get png (or jpg depending on the original extension)
It allows you to build full-SSR apps with Tailwind and JSX, has support for SQLite and HTMX, and is in general a great return to how web dev used to be / should be.
Vercel makes most of its revenue through its PaaS platform - which supports NextJS first-class, and is their recommend solution for hosting NextJS apps.
By making partner deals with SaaS products like Sitecore, contentful,.... where they become the main SDK for their products, leaving everyone else to DIY their integrations.
So you end up having to use Next.js if not in the mood to use less capable integrations, and then eventually end up deploying the application in Vercel infrastructure.
It allows you to build full-SSR apps with Tailwind and JSX, has support for SQLite and HTMX, and is in general a great return to how web dev used to be / should be.
I'm having a difficult time not being salty about this entire situation. There are basic production requirements that haven't been addressed for years because their hosting platform provides it. You don't like the way they do logging? Sounds like you need an attitude adjustment.