6 ms·

I Won't Use Next.js

121 points by danfritz 3y ago

thomasfromcdnjs 3y ago
Side note: That typography hurts my brain/eyes when I try read it, might be the line height.
rco8786 3y ago
> Whatever you use is probably fine. Yes, correct.
phpisatrash 3y ago
That's said, I totally agree with the author. The fact is that Next.js is becoming complicated. It's not simple anymore. Now you have to use a app folder with "page.js" to make it as a route. It's not file system routing anymore. It's folder router. Besides that, app folder is slower than pages. The amount of complexity to build a simple react app is overwhelming. You need to know the conventions created by a so called convention free framework. I've been building nextjs apps for 1+ years, but for the next one I will be looking for an alternative, maybe Remix, Redwood, I don't know. Vercel became Apple. They really like to make great presentations, and events, to their releases, but, instead of increasing the developer experience, they are decreasing it. The only good thing about vercel, as said by the author, is the Next.js deploy, that is really easy to do.
- bosch_mind 3y ago
  I dabble in UI and just started a new next project and it really kind of sucks now. What do you recommend?
  - bizzletk 3y ago
    [Astro](https://astro.build https://astro.build) is a production-ready alternative to Next.js and has been giving me great results. You can render simple HTML/CSS/JS snippets where required, and go all the way up to Svelte/React/etc TSX components without ceremony when you need more complexity.
  - poetril 3y ago
    This is largely personal opinion as someone who uses Next at work all day. But Svelte/SvelteKit or Astro are my personal goto's/favorites outside of Next. Both are robust enough to handle pretty much anything you throw at them, add a complier to help catch errors before build time, and most importantly have incredible developer experiences.
- pier25 3y ago
  > Now you have to use a app folder with "page.js" to make it as a route Reminds me of the +page.svelte in SvelteKit.
  - synergy20 3y ago
    both are bought up by Vercel and becomes Vercel focused, left community behind
    - dackerlunghack 3y ago
      Monopoly is not just the name of the game Law of antitrust lays in a grave Pay us, go bust In money we trust From dawn to dusk Use Vercel you must
compacct27 3y ago
We’re slowly getting back to the “I don’t know who’s right” phase of web framework “innovation”. I can at least tell that Next.js is winning on growth. More new startups are building with it according to the job boards I’m seeing, esp. compared to Remix and even the other contenders (Vue, Svelte)—-at least in the States. Kent’s point about Vercel platform lock-in is pretty eye-opening, though. Not able to easily deploy Next.js outside of Vercel? And, it’s a platform ran by a startup? It’s also not profitable? Um…
- tmpz22 3y ago
  > I can at least tell that Next.js is winning on growth According to a quick google search Vercel has raised at least $313M.
- dham 3y ago
  And less startups will be successful now then when most startups were using Rails. Next.js is not a fullstack framework. Never will be. Fullstack frameworks will never work in the NodeJS ecosystem as the community is incapable of landing on a single solution to do anything.
- poetril 3y ago
  I'm not really sure where the comment on Vercel platform lock-in is coming from. Personally I've deployed Next apps on Cloudflare Pages/Netlify, and I have multiple Next apps at work are all deployed via AWS codebuild or Github Actions (all hosted on AWS). The process is very straightforward and requires little to no extra steps when compared to Vercel.
  - BoorishBears 3y ago
    It's coming from the fact Next.js is all in on serverless, but the reference implementation for deploying it in a serverless environment is closed-source. It's certainly possible you just don't use any of the features they're pushing in that direction, but I mean, they literally dropped basic Request compat just to enable serverless runtimes, and you can't use an img tag without being warned to use their Image Optimization feature, which has no open implementations... Pretty much, most of the energy being spent on Next.js development is towards serverless deploys which use a build format that has to be reverse engineered by outside parties.
thoradam 3y ago
I haven't tried Remix but I can relate to Next.js being too much magic. I've had errors in `getServerSideProps` that happen on the server and then again in the client, causing a client side error instead of simply rendering the 500 page. I've accidentally bundled server code in the client because there's no clear separation. The automagical client side navigation with <Link> has caused scroll position to be forgotten when navigating back. I recently tried Deno Fresh and it has made many different choices that I resonate with: - "When you create a route, all of the components used are rendered on the server. No javascript is sent to the client, unless you specifically include something from the /islands/ folder." - "For stronger resiliency and user experience, Fresh relies on native browser support for form submissions with the HTML <form> element." For example a route that renders a form and accepts a `POST` with that form is trivial, which amazingly can not be said for many server side React frameworks.
- BoorishBears 3y ago
  Deno Fresh pushing "islands" is a huge negative... but that's to be expected when Vercel's VC enforcers are behind it. 99% of the React ecosystem does not function without reactivity enabled: it's literally in the name. As a result most applications written in React depend heavily on interactivity. The only category that is an exception is ecommerce where you're normally pulling from a CMS... and Vercel needed to fight Shopify for that space so they went and "helped" the React team turn the framework into something it's not with RSC. _ Also most of your complaints aren't at all addressed by Deno? It uses an amount of magic closer to current Next.js than pages-era. It actually removes some conventions for separation that Next.js has (all routes potentially being api routes for example). And as far as I can tell both libraries expect you to explicitly handle errors during data fetching (and your users would probably appreciate that too) _ One of these days I might get annoyed enough to fork Next.js 1.0, sprinkle in a folder router for express and call it a day on a framework that doesn't fight React and just stays out of my way.
mortallywounded 3y ago
I tried Next.js 13 (with app directory) for ~3 months building out an MVP for a product idea I had. I am unsure if the things that bothered me are still an issue, but they were... 1. Ridiculously long build/reload times (1~3 seconds for a fairly simple app). 2. Lots of memory/cpu usage while developing (2+ GB of memory, cpu spikes). I got tired of listening to my laptop rev its engine every time I saved a file and it built/reloaded. 3. Complicated logic for simple things like authentication. Really? I need to make a request to get the user/auth state on every page load? Potentially cache it and try to manage/pass it down everywhere? Maybe I'm old school and like the simplicity of the server doing all of that for me, but it felt so janky... especially dealing with styles/components while a refresh is occurring before it knows if it's authenticated or not. Yes-- you can sorta do it on the server with Next, but you can't mix server components and client components in one file, so it became a mess of both in different files with complex props/passing. 4. Although Next is open source and doesn't require Vercel, I kept getting the sinking feeling I was being locked into something (edge functions, etc). 5. Large (20-30ms) latency between the app server and the database. Maybe this is me being old school again and the benefit of running my app server on the same box as my database, but I like having 0-1ms latency from the app server and the database. I always strive for 50-150ms round-trip latency for my requests and that's hard when the database is adding 30ms. Needless to say, I tossed it and re-wrote the entire thing. I don't consider it a waste of time.. I gave Next and the SPA gang a fair try.
- acdha 3y ago
  I watched a team deliver a Next.JS app slower than it would have taken using Django a decade and a half ago. It doesn’t use less memory on the server, has multi-second second page load times, and nobody was sure how to get the client-side JavaScript below 3MB for very, very modest functionality. On the plus side, it has many constantly-changing dependencies to support.
- ttt3ts 3y ago
  I used next 12 for a frontend with a Django backend and I was fairly pleased with it. Little slow on the build but tooling I could give to a fairly novice engineer and be pretty hands off. Then recently, for another client, I tried nextjs 13. What a POS. A lot of the patterns I had learned were tossed replaced with something more complicated. My first client is still happy but I will never use the stack again. Waste of time.
yoav 3y ago
I tried nextjs. I had a route with console.log(request) and some db stuff. I removed the console.log and it broke my build. Because their magic compiler thinks if you don’t reference the request param then the code should execute at build time. So it tried to query the database from CI. Insane. Switched to remix which while still completely asinine and similar in many ways has slightly less magic footgunnery. Next app will be built with something less dumb tbd.
- qudat 3y ago
  If you don’t need SSR/SEO then just use vite.
- nsonha 3y ago
  exactly how I think about these, article would be more genuine if written by someone less biased toward Remix. They are saying "nextjs is bad" only to recommend something bad in a different way. Unfortunately I have not seen anything better than them for javascript. Of course I am a bit hesitant to venture out of React's comfort zone to try something like Astro, that doesn't help
fuzzythinker 3y ago
I wasted much time trying to make Next.js work, both the new and old version. Way too much complexity and issues, not to mention build/reload took > 10 secs. Switched to Vite with vite-plugin-react-pages and things are back to simple. refresh/reload is a sec or less like it should be.
mzronek 3y ago
The author argues multiple times that Next uses the React canary release channel and that's unstable. I think the name for this release channel might be misleading: "We’re introducing an officially supported Canary release channel for React. Since it’s officially supported, if any regressions land, we’ll treat them with a similar urgency to bugs in stable releases." And: "Unlike the Experimental channel, React Canaries only include features that we reasonably believe to be ready for adoption. We encourage frameworks to consider bundling pinned Canary React releases." While I think that Next.js 13's release was bumpy and about a year too early (let's blame it on the VCs), the App Router is in nice shape today and ready for production. It has a steep learning curve though and your brain needs to painfully unlearn some well-established patterns. Source: https://react.dev/blog/2023/05/03/react-canaries https://react.dev/blog/2023/05/03/react-canaries
darepublic 3y ago
I use next and it's been fine for me but I only use pre rendered builds and I do not use any of the server side logic. I assume all these complaints are related to using SSR with next? I have noticed next getting more in my way though I assume it's the noxious presence of investor money. Investment money would f up a cup of coffee if it could
radicalriddler 3y ago
"Next.js is eating React" and "Independence" are definitely two sections where I massively agree. I don't like Vercel, they seem... subtlely villainous. Hearing how much of a pain it was to maintain Next support for Netlify, and personal experience trying to work with Next on Cloudflare is kinda shitty, yet it works perfectly on Vercel. Kinda scared what that means for Astro, having Vercel as their primary hosting partner, hope they don't get bribed into poor choices.
jmtucu 3y ago
Biased since he was hired by Remix.
- AirMax98 3y ago
  Exactly... and Remix is the old team from React Router, who break their API every version. I understand the author's arguments against Next.js, but having just set up a hello-world in Remix and being immediately confronted with a hydration error, I don't think Remix is the path forward either.
  - TranquilMarmot 3y ago
    What's funny is he calls this out in the post: > This is also why there has effectively only been a single breaking change in 8 years of React Router. https://twitter.com/ryanflorence/status/1715023981340967214 https://twitter.com/ryanflorence/status/1715023981340967214 I do agree with it; I've had to do some huge react-router upgrades and the only one that was truly painful was v3 to v4
    - alabhyajindal 3y ago
      2 breaking changes from the 6 versions released. Also, releasing a "backwards compat layer" a year after releasing a version of a library doesn't mean the original release was not a breaking change.
- pier25 3y ago
  Yeah but it's a very fair take. I don't have a horse in the race. I don't use Next, Remix, or even React.
taylodl 3y ago
My advice? Focus on solutions, not tools. For the past forty years I've watched people search again and again for the perfect development tool. Always looking. Not saying it's not a good idea to look at different tools from time-to-time (like every 3-5 years take a look what's available now), but the way you get to the point of doing this work for forty years is delivering solutions.
synergy20 3y ago
The key info here to me is that Vercel hijacked React project to some extent, hired many of Meta's react developers, and forcefully turning React to whatever Vercel favors that has nothing to do with KISS, what a pity. Hope Meta spins off React and hope Vercel stop ruining React, the way it bought up Svelte and made it whatever Vercel likes.
alabhyajindal 3y ago
React Router changed heavily every major version and I had a bad experience using it. Maybe Remix will be stable than that considering it's backed by Shopify.

I Won't Use Next.js

121 points by danfritz 3y ago

thomasfromcdnjs 3y ago

Side note: That typography hurts my brain/eyes when I try read it, might be the line height.

rco8786 3y ago

> Whatever you use is probably fine. Yes, correct.

phpisatrash 3y ago

That's said, I totally agree with the author. The fact is that Next.js is becoming complicated. It's not simple anymore. Now you have to use a app folder with "page.js" to make it as a route. It's not file system routing anymore. It's folder router. Besides that, app folder is slower than pages. The amount of complexity to build a simple react app is overwhelming. You need to know the conventions created by a so called convention free framework. I've been building nextjs apps for 1+ years, but for the next one I will be looking for an alternative, maybe Remix, Redwood, I don't know. Vercel became Apple. They really like to make great presentations, and events, to their releases, but, instead of increasing the developer experience, they are decreasing it. The only good thing about vercel, as said by the author, is the Next.js deploy, that is really easy to do.

bosch_mind 3y ago
I dabble in UI and just started a new next project and it really kind of sucks now. What do you recommend?
- bizzletk 3y ago
  [Astro](https://astro.build https://astro.build) is a production-ready alternative to Next.js and has been giving me great results. You can render simple HTML/CSS/JS snippets where required, and go all the way up to Svelte/React/etc TSX components without ceremony when you need more complexity.
- poetril 3y ago
  This is largely personal opinion as someone who uses Next at work all day. But Svelte/SvelteKit or Astro are my personal goto's/favorites outside of Next. Both are robust enough to handle pretty much anything you throw at them, add a complier to help catch errors before build time, and most importantly have incredible developer experiences.
pier25 3y ago
> Now you have to use a app folder with "page.js" to make it as a route Reminds me of the +page.svelte in SvelteKit.
- synergy20 3y ago
  both are bought up by Vercel and becomes Vercel focused, left community behind
  - dackerlunghack 3y ago
    Monopoly is not just the name of the game Law of antitrust lays in a grave Pay us, go bust In money we trust From dawn to dusk Use Vercel you must

compacct27 3y ago

We’re slowly getting back to the “I don’t know who’s right” phase of web framework “innovation”. I can at least tell that Next.js is winning on growth. More new startups are building with it according to the job boards I’m seeing, esp. compared to Remix and even the other contenders (Vue, Svelte)—-at least in the States. Kent’s point about Vercel platform lock-in is pretty eye-opening, though. Not able to easily deploy Next.js outside of Vercel? And, it’s a platform ran by a startup? It’s also not profitable? Um…

tmpz22 3y ago
> I can at least tell that Next.js is winning on growth According to a quick google search Vercel has raised at least $313M.
dham 3y ago
And less startups will be successful now then when most startups were using Rails. Next.js is not a fullstack framework. Never will be. Fullstack frameworks will never work in the NodeJS ecosystem as the community is incapable of landing on a single solution to do anything.
poetril 3y ago
I'm not really sure where the comment on Vercel platform lock-in is coming from. Personally I've deployed Next apps on Cloudflare Pages/Netlify, and I have multiple Next apps at work are all deployed via AWS codebuild or Github Actions (all hosted on AWS). The process is very straightforward and requires little to no extra steps when compared to Vercel.
- BoorishBears 3y ago
  It's coming from the fact Next.js is all in on serverless, but the reference implementation for deploying it in a serverless environment is closed-source. It's certainly possible you just don't use any of the features they're pushing in that direction, but I mean, they literally dropped basic Request compat just to enable serverless runtimes, and you can't use an img tag without being warned to use their Image Optimization feature, which has no open implementations... Pretty much, most of the energy being spent on Next.js development is towards serverless deploys which use a build format that has to be reverse engineered by outside parties.

thoradam 3y ago

I haven't tried Remix but I can relate to Next.js being too much magic. I've had errors in `getServerSideProps` that happen on the server and then again in the client, causing a client side error instead of simply rendering the 500 page. I've accidentally bundled server code in the client because there's no clear separation. The automagical client side navigation with <Link> has caused scroll position to be forgotten when navigating back. I recently tried Deno Fresh and it has made many different choices that I resonate with: - "When you create a route, all of the components used are rendered on the server. No javascript is sent to the client, unless you specifically include something from the /islands/ folder." - "For stronger resiliency and user experience, Fresh relies on native browser support for form submissions with the HTML <form> element." For example a route that renders a form and accepts a `POST` with that form is trivial, which amazingly can not be said for many server side React frameworks.

BoorishBears 3y ago
Deno Fresh pushing "islands" is a huge negative... but that's to be expected when Vercel's VC enforcers are behind it. 99% of the React ecosystem does not function without reactivity enabled: it's literally in the name. As a result most applications written in React depend heavily on interactivity. The only category that is an exception is ecommerce where you're normally pulling from a CMS... and Vercel needed to fight Shopify for that space so they went and "helped" the React team turn the framework into something it's not with RSC. _ Also most of your complaints aren't at all addressed by Deno? It uses an amount of magic closer to current Next.js than pages-era. It actually removes some conventions for separation that Next.js has (all routes potentially being api routes for example). And as far as I can tell both libraries expect you to explicitly handle errors during data fetching (and your users would probably appreciate that too) _ One of these days I might get annoyed enough to fork Next.js 1.0, sprinkle in a folder router for express and call it a day on a framework that doesn't fight React and just stays out of my way.

mortallywounded 3y ago

I tried Next.js 13 (with app directory) for ~3 months building out an MVP for a product idea I had. I am unsure if the things that bothered me are still an issue, but they were... 1. Ridiculously long build/reload times (1~3 seconds for a fairly simple app). 2. Lots of memory/cpu usage while developing (2+ GB of memory, cpu spikes). I got tired of listening to my laptop rev its engine every time I saved a file and it built/reloaded. 3. Complicated logic for simple things like authentication. Really? I need to make a request to get the user/auth state on every page load? Potentially cache it and try to manage/pass it down everywhere? Maybe I'm old school and like the simplicity of the server doing all of that for me, but it felt so janky... especially dealing with styles/components while a refresh is occurring before it knows if it's authenticated or not. Yes-- you can sorta do it on the server with Next, but you can't mix server components and client components in one file, so it became a mess of both in different files with complex props/passing. 4. Although Next is open source and doesn't require Vercel, I kept getting the sinking feeling I was being locked into something (edge functions, etc). 5. Large (20-30ms) latency between the app server and the database. Maybe this is me being old school again and the benefit of running my app server on the same box as my database, but I like having 0-1ms latency from the app server and the database. I always strive for 50-150ms round-trip latency for my requests and that's hard when the database is adding 30ms. Needless to say, I tossed it and re-wrote the entire thing. I don't consider it a waste of time.. I gave Next and the SPA gang a fair try.

acdha 3y ago
I watched a team deliver a Next.JS app slower than it would have taken using Django a decade and a half ago. It doesn’t use less memory on the server, has multi-second second page load times, and nobody was sure how to get the client-side JavaScript below 3MB for very, very modest functionality. On the plus side, it has many constantly-changing dependencies to support.
ttt3ts 3y ago
I used next 12 for a frontend with a Django backend and I was fairly pleased with it. Little slow on the build but tooling I could give to a fairly novice engineer and be pretty hands off. Then recently, for another client, I tried nextjs 13. What a POS. A lot of the patterns I had learned were tossed replaced with something more complicated. My first client is still happy but I will never use the stack again. Waste of time.

yoav 3y ago

I tried nextjs. I had a route with console.log(request) and some db stuff. I removed the console.log and it broke my build. Because their magic compiler thinks if you don’t reference the request param then the code should execute at build time. So it tried to query the database from CI. Insane. Switched to remix which while still completely asinine and similar in many ways has slightly less magic footgunnery. Next app will be built with something less dumb tbd.

qudat 3y ago
If you don’t need SSR/SEO then just use vite.
nsonha 3y ago
exactly how I think about these, article would be more genuine if written by someone less biased toward Remix. They are saying "nextjs is bad" only to recommend something bad in a different way. Unfortunately I have not seen anything better than them for javascript. Of course I am a bit hesitant to venture out of React's comfort zone to try something like Astro, that doesn't help

fuzzythinker 3y ago

I wasted much time trying to make Next.js work, both the new and old version. Way too much complexity and issues, not to mention build/reload took > 10 secs. Switched to Vite with vite-plugin-react-pages and things are back to simple. refresh/reload is a sec or less like it should be.

mzronek 3y ago

The author argues multiple times that Next uses the React canary release channel and that's unstable. I think the name for this release channel might be misleading: "We’re introducing an officially supported Canary release channel for React. Since it’s officially supported, if any regressions land, we’ll treat them with a similar urgency to bugs in stable releases." And: "Unlike the Experimental channel, React Canaries only include features that we reasonably believe to be ready for adoption. We encourage frameworks to consider bundling pinned Canary React releases." While I think that Next.js 13's release was bumpy and about a year too early (let's blame it on the VCs), the App Router is in nice shape today and ready for production. It has a steep learning curve though and your brain needs to painfully unlearn some well-established patterns. Source: https://react.dev/blog/2023/05/03/react-canaries https://react.dev/blog/2023/05/03/react-canaries

darepublic 3y ago

I use next and it's been fine for me but I only use pre rendered builds and I do not use any of the server side logic. I assume all these complaints are related to using SSR with next? I have noticed next getting more in my way though I assume it's the noxious presence of investor money. Investment money would f up a cup of coffee if it could

radicalriddler 3y ago

"Next.js is eating React" and "Independence" are definitely two sections where I massively agree. I don't like Vercel, they seem... subtlely villainous. Hearing how much of a pain it was to maintain Next support for Netlify, and personal experience trying to work with Next on Cloudflare is kinda shitty, yet it works perfectly on Vercel. Kinda scared what that means for Astro, having Vercel as their primary hosting partner, hope they don't get bribed into poor choices.

jmtucu 3y ago

Biased since he was hired by Remix.

AirMax98 3y ago
Exactly... and Remix is the old team from React Router, who break their API every version. I understand the author's arguments against Next.js, but having just set up a hello-world in Remix and being immediately confronted with a hydration error, I don't think Remix is the path forward either.
- TranquilMarmot 3y ago
  What's funny is he calls this out in the post: > This is also why there has effectively only been a single breaking change in 8 years of React Router. https://twitter.com/ryanflorence/status/1715023981340967214 https://twitter.com/ryanflorence/status/1715023981340967214 I do agree with it; I've had to do some huge react-router upgrades and the only one that was truly painful was v3 to v4
  - alabhyajindal 3y ago
    2 breaking changes from the 6 versions released. Also, releasing a "backwards compat layer" a year after releasing a version of a library doesn't mean the original release was not a breaking change.
pier25 3y ago
Yeah but it's a very fair take. I don't have a horse in the race. I don't use Next, Remix, or even React.

taylodl 3y ago

My advice? Focus on solutions, not tools. For the past forty years I've watched people search again and again for the perfect development tool. Always looking. Not saying it's not a good idea to look at different tools from time-to-time (like every 3-5 years take a look what's available now), but the way you get to the point of doing this work for forty years is delivering solutions.

synergy20 3y ago

The key info here to me is that Vercel hijacked React project to some extent, hired many of Meta's react developers, and forcefully turning React to whatever Vercel favors that has nothing to do with KISS, what a pity. Hope Meta spins off React and hope Vercel stop ruining React, the way it bought up Svelte and made it whatever Vercel likes.

alabhyajindal 3y ago

React Router changed heavily every major version and I had a bad experience using it. Maybe Remix will be stable than that considering it's backed by Shopify.