Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js 15.1 is unusable outside of Vercel

omarabid.com

Post reply on HN
Print view View original

51–60 of 113 posts

Re: Next.js 15.1 is unusable outside of Vercel

#51

Post by hn_throw2025 »

ImprobableTruth wrote: post #47
Aeolun wrote: post #16

Next has become a joke. It’s mildly frustrating that with Remix’s inexplicable transformation into react-router, there’s few great react frameworks left (for me), I’m back to plain vite with tanstack router.

What's the issue with the remix -> react-router transition? As far as I can tell it's just a branding thing.

I started learning Remix, which was then relaunched as RRv7. Now Remix is going to be revived, and based on Preact instead[0].

I have given up and started learning NextJS. At least it has marketshare, while Remix will never gain traction because it keeps getting torpedoed by a couple of pivot artists.

[0] https://remix.run/blog/wake-up-remix

Re: Next.js 15.1 is unusable outside of Vercel

#52

Post by pas »

aitchnyu wrote: post #48
jowday wrote: post #28

Don’t ever use Next. Terrible developer experience, vendor lock in, weird undocumented conventions that make building anything other than some kind of B2B SaaS CRUD site full of undocumented foot guns. My favorite thing I’ve encountered is the Next tag somehow dropping the FPS on a webgl scene on the same page to 2 FPS.

How was Vercel able to frog-boil normal React users with vendor lock-in? React was supposed to be Meta's baby and open source was supposed to defeat vendor lock-in.

because they pushed shiny new features that are reaaaallly good for a certain set of commercial users (think webshops, where time to first contentful paint equals time to money)

and the tech is not bad, it's just meh (immature and a bit misguided) after all

by flipping the whole thing upside down, defaulting to server-side, a lot of previously hard problems became easy (the usual glueing of different APIs - user, CMS, metadata, "security", adtech, blablabla - translate to `const user = await auth();` and so on, and still after processing the request emitting a React page is kind of nice, Server Actions are also nice because Next manages the API URLs for you), and since mobile technology (phones and networks) evolved a lot it's not a problem to do a request for each page (especially on webshops where Next prefetches the ha$$y path))

but it's still a very subpar backend framework :/

Re: Next.js 15.1 is unusable outside of Vercel

#53

Post by koakuma-chan »

celicoo wrote: post #50
koakuma-chan wrote: post #38

Earlier quoted context omitted.

It's mostly running Vercel spyware.

Do you care to elaborate?

It's a joke but also https://nextjs.org/telemetry

It is unknown though what causes it to take 10 seconds to compile a route in dev mode after each change. They have a development environment guide[0] but it's all lies and doesn't actually work.

[0]: https://nextjs.org/docs/app/guides/local-development

Antivirus? Imports?

```

Compiled /analytics in 3.8s (3123 modules)

GET /analytics 200 in 5185ms

```

Doesn't explain the 10 seconds.

Re: Next.js 15.1 is unusable outside of Vercel

#54

Post by bravesoul2 »

I don't know. I felt NextJS got too complicated for me years ago and may have had a sweet spot back then when it felt magic. Now id just use a boring web server for most things. Chuck on a front end framework when needed for a SPA. If you choose classic or SPA things are far more simple.

Re: Next.js 15.1 is unusable outside of Vercel

#55

Post by bravesoul2 »

aitchnyu wrote: post #48
jowday wrote: post #28

Don’t ever use Next. Terrible developer experience, vendor lock in, weird undocumented conventions that make building anything other than some kind of B2B SaaS CRUD site full of undocumented foot guns. My favorite thing I’ve encountered is the Next tag somehow dropping the FPS on a webgl scene on the same page to 2 FPS.

How was Vercel able to frog-boil normal React users with vendor lock-in? React was supposed to be Meta's baby and open source was supposed to defeat vendor lock-in.

Does Vite at least create enough competition?

Re: Next.js 15.1 is unusable outside of Vercel

#56

Post by bravesoul2 »

christophilus wrote: post #22
koakuma-chan wrote: post #15

Everybody should be talking about how it takes Next.js 10 seconds to compile a route in development mode. Rust compiler is smoking in the corner.

It’s unusable. The worst devx I’ve experienced since… dunno. I can’t think of a stack I’ve worked with that I loathed more since that one and only time looked at helping someone fix their Sharepoint site.

Yeah it's at least 200 millisharepoints of bad.

Re: Next.js 15.1 is unusable outside of Vercel

#58

Post by bravesoul2 »

Illniyar wrote: post #25
jasoncartwright wrote: post #9

Post suggests the underlying problem is the metadata takes too long to put in the HTML? A few tags? Really? This kind of problem, and the vendor lock-in, is completely unimaginable for any web framework I can think of. Bizarre.

I think it was that if metadata requires getting data from third parties or something, it takes a long time, and it doesn't affect what the user sees. It did say this was a problem for very few people.

That's "deprecating EKS for Omega star at the end of the month" level of dumb.

Let the programmer do high latency shit if they want. Give them a damn catch if they need it.

Re: Next.js 15.1 is unusable outside of Vercel

#59

Post by skeptrune »

Vite has gotten really good and I don't need NextJS anymore to make React easy.

However, it did really feel like magic a few years ago and has become the default choice. At this point it's a legacy framework that we all have to deal with the same way Spring is.

Re: Next.js 15.1 is unusable outside of Vercel

#60

Post by 5Qn8mNbc2FNCiVV »

This seems blown out of proportion. Anyone who knows how streaming in React works knows, that you can't stream your HTML line by line. And there was the need to not block first paint (HTML, not JS) just because of metadata. It's reasonable to have a list of user agents that are exempt from that behavior since those are also not the bulk of your traffic where you want to show something as fast as possible.

How would you instead solve this, with the requirement that some users have metadata that takes a while to load?

Post reply on HN