13 ms·

Next.js 14

107 points by creativedg 3y ago

deleted 3y ago
[deleted]
jjice 3y ago
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.
hackandthink 3y ago
I missed this: https://vercel.com/changelog/vercel-postgres-is-now-available-for-pro-users https://vercel.com/changelog/vercel-postgres-is-now-availabl...
- CharlesW 3y ago
  FWIW, “Vercel Postgres” is a white-label of Neon: https://neon.tech/blog/neon-postgres-on-vercel https://neon.tech/blog/neon-postgres-on-vercel
  - leerob 3y ago
    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.
    - CharlesW 3y ago
      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.
lgkk 3y ago
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!
- ldjkfkdsjnv 3y ago
  I just made basically the same comment, I'm pessimistic, but open minded. Hoping someone can drop some insight on this thread
  - cyral 3y ago
    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.
shmde 3y ago
Wait wtf, I clearly remember 13 came out of beta 4-5 months back. At this rate Next.js will be on version 20 by the end of next year.
- hyperfuturism 3y ago
  It's been about a year since Next.js 13 - so a bit more than 4 - 5 months.
  - thesdev 3y ago
    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.
- runjake 3y ago
  13 came out in Oct 2022. https://nextjs.org/blog/next-13 https://nextjs.org/blog/next-13 PS: I’m not sure why hyperfurism’s reply was downvoted to oblivion. They were correct.
  - deleted 3y ago
    [deleted]
  - shmde 3y ago
    I was talking about the App Router coming out of beta 4-5 months ago and we already have a new version today.
- willsmith72 3y ago
  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.
joduplessis 3y ago
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.
- pjmlp 3y ago
  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.
  - joduplessis 3y ago
    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.
- johnfn 3y ago
  > 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!
  - BoorishBears 3y ago
    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.
hdlothia 3y ago
How do these companies make money offering so much for free?
- johnnypangs 3y ago
  Their enterprise version is super expensive, their integration with Amazon can give you an idea of their enterprise pricing https://aws.amazon.com/marketplace/pp/prodview-lwqascgzju3bo https://aws.amazon.com/marketplace/pp/prodview-lwqascgzju3bo
- samspenc 3y ago
  Vercel makes most of its revenue through its PaaS platform - which supports NextJS first-class, and is their recommend solution for hosting NextJS apps.
- pjmlp 3y ago
  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.
batmansmk 3y ago
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.
- leerob 3y ago
  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.
  - batmansmk 3y ago
    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.
ldjkfkdsjnv 3y ago
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
- MajimasEyepatch 3y ago
  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.
thinkingkong 3y ago
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.
- JCharante 3y ago
  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.
  - leerob 3y ago
    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.
    - ervine 3y ago
      Please take this seriously: stop advising in github issues to switch to App router as a solution to bugs in page router. It's not an option for large next.js projects, and certainly does not convey what you're saying here.
      - leerob 3y ago
        Can you be more specific on the issue? It’s possible there’s a reason why App Router was recommended in this case.
- boredtofears 3y ago
  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.
samschooler 3y ago
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.
- cyral 3y ago
  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.
CafeRacer 3y ago
Can you set a cookie from server component now?
- leerob 3y ago
  You can set cookies in Server Actions or Route Handlers. https://nextjs.org/docs/app#how-can-i-set-cookies https://nextjs.org/docs/app#how-can-i-set-cookies
orf 3y ago
Fuck next.js. Honestly. Check out how it bundles and sends the entire react-dom library twice to every user on every page view https://github.com/vercel/next.js/issues/51508 https://github.com/vercel/next.js/issues/51508. Fuck 1MB of JS to render a static HTML page. 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. Use Astro. It’s what next.js pretends to be https://astro.build/ https://astro.build/
- richbell 3y ago
  Tangent, but I hate projects that automatically lock issues.
- veeti 3y ago
  Can we get a fuck for these automatic "stale" issue locking bots too? Ridiculous.
  - Shakahs 3y ago
    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.
- euazOn 3y ago
  Astro is great! As a tangent, do you have any favorite Astro resources to share, or great minds to follow?
- rickstanley 3y ago
  > Fuck 500kb of JS to render a static HTML page. Funny, trying to open the post's link (https://nextjs.org/blog/next-14 https://nextjs.org/blog/next-14) with JS disabled, it renders a "beautiful" blank page.
JCharante 3y ago
Server actions sounds great for small projects. Type safety in those calls seems like it can replace a tRPC server in small projects and SaaS MVPs.
- leerob 3y ago
  Yeah, best part for me is end to end type safety across the server and client. tRPC really led the way here.
creativedg 3y ago
Just update my free and open source Next.js Landing Page template to version 14 without any issue: https://github.com/ixartz/Next-JS-Landing-Page-Starter-Template https://github.com/ixartz/Next-JS-Landing-Page-Starter-Templ...
aliston 3y ago
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?
- Spixel_ 3y ago
  That would be Remix: https://remix.run https://remix.run See: https://www.epicweb.dev/why-i-wont-use-nextjs https://www.epicweb.dev/why-i-wont-use-nextjs
- chasd00 3y ago
  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.
cphoover 3y ago
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.
- leerob 3y ago
  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.
  - nvm0n2 3y ago
    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.
- ervine 3y ago
  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.
  - leerob 3y ago
    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.
tirey 3y ago
For anyone looking for a better alternative to the current web dev landscape: use hyperwave. https://github.com/tireymorris/hyperwave https://github.com/tireymorris/hyperwave 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.
- kavaruka 3y ago
  this is just an hype-driven "glue code" which combines the most popular buzzwords at the moment, a framework is something else
lprd 3y ago
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?".
- 0xblinq 3y ago
  I’ve moved to use Laravel + Inertia (with react) and I’m so glad I did.
holoduke 3y ago
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.
jowday 3y ago
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.
- leerob 3y ago
  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.
  - ervine 3y ago
    https://github.com/vercel/next.js/issues/22319 https://github.com/vercel/next.js/issues/22319 https://github.com/vercel/next.js/discussions/46722 https://github.com/vercel/next.js/discussions/46722 Let us take control when self-hosting, please!
    - leerob 3y ago
      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)?
garganzol 3y ago
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.
- leerob 3y ago
  Community Notes: Vercel did not acquire Gatsby.
  - garganzol 3y ago
    Sorry, you are right - it was Netlify who acquired Gatsby. I have fixed the original message.
turtlebits 3y ago
Local development performance improvements are great, but only after end user optimizations! This blog article is absolutely bloated, and a huge problem I see with JS frameworks. 87 requests 2.9 MB transferred 23.2 MB resources
10xDev 3y ago
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.
jjkeddo199 3y ago
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".
- garganzol 3y ago
  The idea is not to "work for free", the idea is to avoid single vendor situation when it comes to hosting.
kavaruka 3y ago
I believe that many people who criticize Next.js or consider it difficult have not understood what the RSCs are for and how they work It's a paradigm shift compared to the old way of thinking about React apps In my company we've been using Next.js in production for a long time now and for us the app router has been key to increasing DX
- Inviz 3y ago
  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.
kyleee 3y ago
I’m particularly looking forward to nextjs 15
andrasbacsai 3y ago
Why don't people use Laravel/Rails/Django and make good web apps in no time? So much pain could fly away instantly.
- wavo 3y ago
  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.
  - kugelblitz 3y ago
    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.
cockatiel_day 3y ago
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.
- leerob 3y ago
  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?
  - cockatiel_day 3y ago
    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.

107 points by creativedg 3y ago

deleted 3y ago

[deleted]

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.

hackandthink 3y ago

I missed this: https://vercel.com/changelog/vercel-postgres-is-now-available-for-pro-users https://vercel.com/changelog/vercel-postgres-is-now-availabl...

CharlesW 3y ago
FWIW, “Vercel Postgres” is a white-label of Neon: https://neon.tech/blog/neon-postgres-on-vercel https://neon.tech/blog/neon-postgres-on-vercel
- leerob 3y ago
  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.
  - CharlesW 3y ago
    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.

lgkk 3y ago

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!

ldjkfkdsjnv 3y ago
I just made basically the same comment, I'm pessimistic, but open minded. Hoping someone can drop some insight on this thread
- cyral 3y ago
  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.

shmde 3y ago

Wait wtf, I clearly remember 13 came out of beta 4-5 months back. At this rate Next.js will be on version 20 by the end of next year.

hyperfuturism 3y ago
It's been about a year since Next.js 13 - so a bit more than 4 - 5 months.
- thesdev 3y ago
  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.
runjake 3y ago
13 came out in Oct 2022. https://nextjs.org/blog/next-13 https://nextjs.org/blog/next-13 PS: I’m not sure why hyperfurism’s reply was downvoted to oblivion. They were correct.
- deleted 3y ago
  [deleted]
- shmde 3y ago
  I was talking about the App Router coming out of beta 4-5 months ago and we already have a new version today.
willsmith72 3y ago
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.

joduplessis 3y ago

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.

pjmlp 3y ago
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.
- joduplessis 3y ago
  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.
johnfn 3y ago
> 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!
- BoorishBears 3y ago
  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.

hdlothia 3y ago

How do these companies make money offering so much for free?

johnnypangs 3y ago
Their enterprise version is super expensive, their integration with Amazon can give you an idea of their enterprise pricing https://aws.amazon.com/marketplace/pp/prodview-lwqascgzju3bo https://aws.amazon.com/marketplace/pp/prodview-lwqascgzju3bo
samspenc 3y ago
Vercel makes most of its revenue through its PaaS platform - which supports NextJS first-class, and is their recommend solution for hosting NextJS apps.
pjmlp 3y ago
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.

batmansmk 3y ago

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.

leerob 3y ago
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.
- batmansmk 3y ago
  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.

ldjkfkdsjnv 3y ago

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

MajimasEyepatch 3y ago
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.

thinkingkong 3y ago

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.

JCharante 3y ago
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.
- leerob 3y ago
  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.
  - ervine 3y ago
    Please take this seriously: stop advising in github issues to switch to App router as a solution to bugs in page router. It's not an option for large next.js projects, and certainly does not convey what you're saying here.
    - leerob 3y ago
      Can you be more specific on the issue? It’s possible there’s a reason why App Router was recommended in this case.
boredtofears 3y ago
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.

samschooler 3y ago

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.

cyral 3y ago
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.

CafeRacer 3y ago

Can you set a cookie from server component now?

leerob 3y ago
You can set cookies in Server Actions or Route Handlers. https://nextjs.org/docs/app#how-can-i-set-cookies https://nextjs.org/docs/app#how-can-i-set-cookies

orf 3y ago

Fuck next.js. Honestly. Check out how it bundles and sends the entire react-dom library twice to every user on every page view https://github.com/vercel/next.js/issues/51508 https://github.com/vercel/next.js/issues/51508. Fuck 1MB of JS to render a static HTML page. 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. Use Astro. It’s what next.js pretends to be https://astro.build/ https://astro.build/

richbell 3y ago
Tangent, but I hate projects that automatically lock issues.
veeti 3y ago
Can we get a fuck for these automatic "stale" issue locking bots too? Ridiculous.
- Shakahs 3y ago
  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.
euazOn 3y ago
Astro is great! As a tangent, do you have any favorite Astro resources to share, or great minds to follow?
rickstanley 3y ago
> Fuck 500kb of JS to render a static HTML page. Funny, trying to open the post's link (https://nextjs.org/blog/next-14 https://nextjs.org/blog/next-14) with JS disabled, it renders a "beautiful" blank page.

JCharante 3y ago

Server actions sounds great for small projects. Type safety in those calls seems like it can replace a tRPC server in small projects and SaaS MVPs.

leerob 3y ago
Yeah, best part for me is end to end type safety across the server and client. tRPC really led the way here.

creativedg 3y ago

Just update my free and open source Next.js Landing Page template to version 14 without any issue: https://github.com/ixartz/Next-JS-Landing-Page-Starter-Template https://github.com/ixartz/Next-JS-Landing-Page-Starter-Templ...

aliston 3y ago

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?

Spixel_ 3y ago
That would be Remix: https://remix.run https://remix.run See: https://www.epicweb.dev/why-i-wont-use-nextjs https://www.epicweb.dev/why-i-wont-use-nextjs
chasd00 3y ago
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.

cphoover 3y ago

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.

leerob 3y ago
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.
- nvm0n2 3y ago
  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.
ervine 3y ago
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.
- leerob 3y ago
  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.

tirey 3y ago

For anyone looking for a better alternative to the current web dev landscape: use hyperwave. https://github.com/tireymorris/hyperwave https://github.com/tireymorris/hyperwave 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.

kavaruka 3y ago
this is just an hype-driven "glue code" which combines the most popular buzzwords at the moment, a framework is something else

lprd 3y ago

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?".

0xblinq 3y ago
I’ve moved to use Laravel + Inertia (with react) and I’m so glad I did.

holoduke 3y ago

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.

jowday 3y ago

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.

leerob 3y ago
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.
- ervine 3y ago
  https://github.com/vercel/next.js/issues/22319 https://github.com/vercel/next.js/issues/22319 https://github.com/vercel/next.js/discussions/46722 https://github.com/vercel/next.js/discussions/46722 Let us take control when self-hosting, please!
  - leerob 3y ago
    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)?

garganzol 3y ago

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.

leerob 3y ago
Community Notes: Vercel did not acquire Gatsby.
- garganzol 3y ago
  Sorry, you are right - it was Netlify who acquired Gatsby. I have fixed the original message.

turtlebits 3y ago

Local development performance improvements are great, but only after end user optimizations! This blog article is absolutely bloated, and a huge problem I see with JS frameworks. 87 requests 2.9 MB transferred 23.2 MB resources

10xDev 3y ago

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.

jjkeddo199 3y ago

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".

garganzol 3y ago
The idea is not to "work for free", the idea is to avoid single vendor situation when it comes to hosting.

kavaruka 3y ago

I believe that many people who criticize Next.js or consider it difficult have not understood what the RSCs are for and how they work It's a paradigm shift compared to the old way of thinking about React apps In my company we've been using Next.js in production for a long time now and for us the app router has been key to increasing DX

Inviz 3y ago
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.

kyleee 3y ago

I’m particularly looking forward to nextjs 15

andrasbacsai 3y ago

Why don't people use Laravel/Rails/Django and make good web apps in no time? So much pain could fly away instantly.

wavo 3y ago
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.
- kugelblitz 3y ago
  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.

cockatiel_day 3y ago

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.

leerob 3y ago
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?
- cockatiel_day 3y ago
  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.