Hacker News new | past | comments | ask | show | jobs | submit login
I Won't Use Next.js (epicweb.dev)
121 points by danfritz on Oct 25, 2023 | hide | past | favorite | 38 comments



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.


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


both are bought up by Vercel and becomes Vercel focused, left community behind


  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


I dabble in UI and just started a new next project and it really kind of sucks now.

What do you recommend?


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.


[Astro](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.


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.


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.


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.


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


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…


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.


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.


How is the implementation not open? They have it all on Github.


No they don't, hence projects like https://open-next.js.org/ and the multitude of stories of 3rd party serverless offerings being half-broken. They also keep breaking at time goes on since they're playing catch up on the build output:

https://www.reddit.com/r/nextjs/comments/1685dyr/avoid_aws_a...

https://www.reddit.com/r/nextjs/comments/160ui01/is_aws_ampl...

https://betterprogramming.pub/beware-of-next-js-on-aws-ampli...

_

To actually use the build output format, you need an implementation that Vercel does not open source.

Compare that to Remix which maintains an open reference implementation for their adapter format, which in turn makes supporting additional platforms incredibly simple.


It's not all in on serverless and saying so is spreading misinformation.

You can use (almost) all their backend features as if it's a single server (which it is in the end) and you can also use their image tag when self-hosting and it processes the images for you.

If you're annoyed and don't want to use their image tag, then disable the linting rule. However after having used it for a large scale e-commerce store I'm gonna be honest: It works damn good and not paying for Cloudinary or something along those lines is really nice

There are SOME questionable choices like the middleware only being compatible with an edge runtime that can't be turned off, but apart from that one it really is like any other SSR framework....

Edit: added an almost because well, middleware is pretty bad-ish


> I can at least tell that Next.js is winning on growth

According to a quick google search Vercel has raised at least $313M.


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.


> We’re slowly getting back to the “I don’t know who’s right” phase of web framework “innovation”.

I think we've probably been there for over a decade since we left the PHP/Django/Rails + jQuery paradigm.


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.


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


If you don’t need SSR/SEO then just use vite.


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.


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.


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.


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.


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.


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


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


> Whatever you use is probably fine.

Yes, correct.


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.


Biased since he was hired by Remix.


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.


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

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


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.


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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: