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

Next.js is infuriating

blog.meca.sh

Post reply on HN
Print view View original

401–410 of 602 posts

Re: Next.js is infuriating

#401

Post by rustystump »

oompydoompy74 wrote: post #249
9dev wrote: post #177

Earlier quoted context omitted.

Vercel is the cancer of the modern web. The claw into every framework ecosystem and abuse them as sales funnels for their paid plans, pretending they care about open source, competition, and the web.

Vercel funds and sponsors many open source projects that would otherwise be struggling for funding. Their framework is tailored to the platform they build because that’s a good experience. I don’t currently use them, but people get funneled to their paid plans because it’s a good developer experience. I acknowledge that they are a capitalist enterprise with their own motives, but I think cancer of the modern web is a…

Vercel won the techfluencer space like none other. They get a bad rep largely due to the influencer crowd adjacent to them. Influencers are cancer but an almost necessary one like marketing.

Annoying, obnoxious, and always trying to get your email but god damn do they get your attention.

Re: Next.js is infuriating

#402

Post by wild_egg »

DanielHB wrote: post #307
wild_egg wrote: post #208

Earlier quoted context omitted.

Advances in the browser standards are slowly removing the need for most client side JS altogether so standardizing on some concept of bundlers would be a step backwards. Vast majority of web dev projects have zero need for an SPA framework these days and all this pain is self inflicted for little benefit. Those tools do have good use cases still but the chances that your project is one of them I'd shrinking all the t…

I don't think we will ever be able to get away from bundlers because there is no way to solve the waterfall request problem of using modules (one module imports requires another module). Maybe some kind of standard manifest spec that tells the browser which parts of the code to load upfront and which parts of the code to lazy-load, but to generate that manifest in an efficient manner you would need at least part of w…

> Advances in the browser standards are slowly removing the need for most client side JS altogether

I probably wasn't clear enough when I said this.

If you're talking about waterfall requests in module loading, you've missed what I said and are likely sending orders of magnitude more JS to clients than you need to.

It's really worthwhile looking at all the new features in browsers over the last 5-10 years and asking yourself if you really can't do what you need just with vanilla HTML and CSS at this point. You can always sprinkle in a bit of JS to fill in some gaps if needed. My team usually has a 2-300 line JS file in each project. No bundlers or modules ever required at that scale.

Re: Next.js is infuriating

#403

Post by dminik »

OtherShrezzing wrote: post #114
ddanieltan wrote: post #72

A bit of a tangent, but how do you implement the feature when I highlight text on this blog, I get an option to generate a unique link directly to what I highlighted?

Each paragraph/element has a unique ID, starting at 0, incrementing by 1. You originally land at the page https://blog.meca.sh/3lxoty3shjc2z . When you create a link, you're linking instead to a different page at https://blog.meca.sh/3lxoty3shjc2z/l-quote/64_25-65_174#64 . The format of the extra link metadata is `64_25-65_174#64`, which means: - Start the highlight on the 64th element/paragraph. Inside of that parag…

The blog itself is build on leaflet.pub.

I'll take a look and file an issue.

Re: Next.js is infuriating

#404

Post by jakubmazanec »

mvdtnz wrote: post #63
solatic wrote: post #14

Half these issues stem from a relative misunderstanding of exactly where the code is running. Next.js has layers upon layers upon layers due to the interplay between the browser, middleware, edge vs. node, SSR... It's an enormous amount of complexity and it really only fits under the following set of circumstances: * You sell a B2C product to a potentially global audience, so edge semantics actually help with latency…

> Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR. Just write your SPA the grown up way. Write your APIs in a language and framework well suited to such work (pick your poison, Rails, Spring, whatever Microsoft is calling this year's .NET web technology). And write your front-end in Typescript. There's absolutely no reason to tightly couple your…

> There's absolutely no reason to tightly couple your front-end and backend

I'll give you one reason: Gel [1] and their awesome TypeScript query builder [2].

[1] https://www.geldata.com/ [2] https://www.geldata.com/blog/designing-the-ultimate-typescri...

Re: Next.js is infuriating

#405

Post by rustystump »

rozenmd wrote: post #195
YuukiRey wrote: post #79

I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else. In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts. Next.js is easily the worst technology I've ever used.

I've been running a SaaS on Next.js + GraphQL for 4.5 years now, sticking to Pages router has eliminated most of the complexity. I recently rewrote my auth to use better-auth (as a separate service), which has allowed me to start moving entirely off Next.js (looking at either React Router 7 or Tanstack Router). Back when I started, Next.js made server side rendering incredibly easy, but it turns out I didn't need it.…

I regret “upgrading” my personal site to app router. Big mistake esp for is an almost purely static site.

Sadly tan stacks releases a new version every other day and react router was complete 5 versions ago but cannot seem to keep changing the api to stay relevant in the never ending js relevancy ending war.

Re: Next.js is infuriating

#406

Post by fragmede »

ncphillips wrote: post #132
solatic wrote: post #14

Half these issues stem from a relative misunderstanding of exactly where the code is running. Next.js has layers upon layers upon layers due to the interplay between the browser, middleware, edge vs. node, SSR... It's an enormous amount of complexity and it really only fits under the following set of circumstances: * You sell a B2C product to a potentially global audience, so edge semantics actually help with latency…

> Half these issues stem from a relative misunderstanding of exactly where the code is running. I used to think Javascript everywhere was an advantage, and this is exactly why I now think it's a bad idea. My company uses Inertia.js + Vue and it a significantly better experience. I still get all the power of modern frontend rendering but the overall architecture is so much simpler. The routing is 100% serverside and t…

> If it's PHP it's on the server. It's JS it's in the browser. Never needing to question that has been a huge boon for us.

In what way has that been a boon? Context switching between languages, especially PHP, seems like an even bigger headache. Is it strlen($var) or var.length or mb_strlen($var)?

Do you ever output JavaScript from PHP?

My biggest question though is how do you avoid ever duplicating logic between js and PHP? Validation logic, especially, but business logic leaks between the two, I've found. Doing it all in Next saves me from that particular problem.

Re: Next.js is infuriating

#407

Post by fragmede »

b_e_n_t_o_n wrote: post #94
mvdtnz wrote: post #63

Earlier quoted context omitted.

> Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR. Just write your SPA the grown up way. Write your APIs in a language and framework well suited to such work (pick your poison, Rails, Spring, whatever Microsoft is calling this year's .NET web technology). And write your front-end in Typescript. There's absolutely no reason to tightly couple your…

Agreed. It's a bit insane that updating a button padding redeploys your entire backend.

Are you paying for computer time by the CPU cycle?

Re: Next.js is infuriating

#410

Post by fragmede »

tacker2000 wrote: post #385
nonethewiser wrote: post #288

Earlier quoted context omitted.

People will complain about Next but there is no perfect solution. The complexity driving the problems with Next materialize in other forms elsewhere. Remix is a competitive option with its own quirks. You can always roll your own with Vite, Tanstack router, etc. but then of course you're manually implementing the same stuff albeit better suited to your needs. Which isn't necessarily bad but it's not the right choice…

The perfect solution is to use React for the frontend (where its main purpose and strengths lie) and use something like PHP, Java, ruby or whatever for the backend. This insanity of server side react introduces all kinds of unnecessary quirks. Also, the VC-funded Vercel is of course purposely dumbing down Next.js, so that everyone pays them. Its a trap everyone should be aware of.

Sounds like a conspiracy theory. What's wrong with making the framework easier to use? Yes, the company that's paying for development on the framework is also paying those developers to make the golden path for deployment to use that company's PaaS offering, but unless we all band together and GoFundMe a framework that doesn't, how else do you want framework development to happen? Heroku/Cloudflare/AWS/GCp's entirely able to also pay those devs to make it easier to deploy to their platform.
Post reply on HN