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

You should know this before choosing Next.js

eduardoboucas.com

Post reply on HN
Print view View original

111–120 of 147 posts

Re: You should know this before choosing Next.js

#111

Post by [deleted] »

hombre_fatal wrote: post #104
nonethewiser wrote: post #62

Earlier quoted context omitted.

>I now just use a React SPA with Vite. To be fair it sounds like you didnt need Next.js in the first place then? SPA is more of an alternative than an analog. 6-7s for HMR is terrible though. Agreed.

Next.js' main offering is that you basically get SPA architecture but with a single browser server round trip on first load instead of two round trips. That's where ~all of Next.js' complexity comes from, and it should definitely be appreciated for that because it's a hard problem. But if you don't need that, I don't see why you'd use something so brittle, complicated, and experimental.

[deleted]

Re: You should know this before choosing Next.js

#112

Post by 9rx »

hombre_fatal wrote: post #104
nonethewiser wrote: post #62

Earlier quoted context omitted.

>I now just use a React SPA with Vite. To be fair it sounds like you didnt need Next.js in the first place then? SPA is more of an alternative than an analog. 6-7s for HMR is terrible though. Agreed.

Next.js' main offering is that you basically get SPA architecture but with a single browser server round trip on first load instead of two round trips. That's where ~all of Next.js' complexity comes from, and it should definitely be appreciated for that because it's a hard problem. But if you don't need that, I don't see why you'd use something so brittle, complicated, and experimental.

> That's where ~all of Next.js' complexity comes from

Complexity does arise there, but equally arises from limitations imposed by the Vercel service that Next.js ultimately needs to deal with. A lot of its seemingly dumb design decisions make sense once you consider the constraints Vercel (the service) forces upon it, but they are still poor decisions you have to live with that wouldn't have been necessary if it were intended to run in a "normal" computing environment.

Re: You should know this before choosing Next.js

#113

Post by joshdavham »

owebmaster wrote: post #100
joshdavham wrote: post #54

I feel that open source is truly at its best when it’s done by enthusiasts/hobbyists and not necessarily by corporations. React and Nextjs always smelled a bit suspicious to me whereas Svelte and Vue did not. There’s actually an old PG essay talking about Java where I feel a lot of what he says applies to Nextjs: https://www.paulgraham.com/javacover.html

> whereas Svelte and Vue did not. The svelte guy was hired by Vercel a few years ago and is completely on board. Same strategy used to co-opt React.

I can't speak for Rich Harris, but Svelte and Sveltekit were never created as part of any company. These tools were created organically.

To my knowledge, Rich is just an employee of Vercel where they pay him to work on it full time. Despite that, I believe that Svelte still aims to remain independent. I imagine that Vercel just wanted him in-house so they could keep their eye on the latest developments in the js-framework space.

Re: You should know this before choosing Next.js

#114

Post by martinsnow »

ramesh31 wrote: post #29
diggan wrote: post #24

Earlier quoted context omitted.

> next.js when they switched from the pages router to app router It is react-router all over again. For those who weren't around, react-router appeared early in React's life, and lots of people were using it. But, for every major version they released, they completely changed the way of doing the routes/routing, so if you wanted to use a maintained release, you'd have to constantly refactor, often without any real ga…

>It's kind of weird to me how programmers (especially of libraries like that) aren't more careful about introducing breaking changes, since the work needed to be done afterwards multiplies really quickly. Programmers, generally, always aim to do that. But the JS framework world for whatever reason has this constant obsession with reinvention. I honestly think it stems from a sort of inferiority complex that FE devs h…

No. These terms are not uniquely new.

Re: You should know this before choosing Next.js

#115

Post by amrocha »

tmpz22 wrote: post #42
diggan wrote: post #24

Earlier quoted context omitted.

> next.js when they switched from the pages router to app router It is react-router all over again. For those who weren't around, react-router appeared early in React's life, and lots of people were using it. But, for every major version they released, they completely changed the way of doing the routes/routing, so if you wanted to use a maintained release, you'd have to constantly refactor, often without any real ga…

React-router can still cause weird build issues to this day, particularly with LLM generated code that cannot understand version compatibilities.

If you try to build incompatible code and it doesn’t work, that’s not a bug

Re: You should know this before choosing Next.js

#116

Post by tyleo »

buffalobuffalo wrote: post #84
rco8786 wrote: post #12

I was using next.js when they switched from the pages router to app router. I ended up just abandoning the project, the app router experience was that bad, and haven't really been keen on picking up next.js since then. It's always seemed clear that Vercel has been, at best, OSS- ish . Trying to play both sides of claiming to be open source but also (somewhat sneakily) building a walled garden to lock users into their…

I think the fundamental problem is that next.js is trying to do two things at once. It wants to a) Be fast to load for content that is sensitive to load speeds (SEO content, landing pages, social media sharable content, etc). It also wants to support complex client side logic (single page app, navigation, state store, etc). Doing those two things at the same time is really hard. It is also, in my experience, complete…

This is my approach. My website tyleo.com is just a bunch of CSS/HTML classic webpage stuff. If a page needs a small amount of JS I just bundle it ad-hoc. More complex pages get the full React/SPA treatment but it doesn’t mean the whole website needs to be that way.

As an aside, I reuse code by using React as the template engine for HTML. Each page essentially has a toggle whether to ship it in dynamic mode or static mode which includes the full JS bundles or nothing.

Re: You should know this before choosing Next.js

#117

Post by Noumenon72 »

diggan wrote: post #24
rco8786 wrote: post #12

I was using next.js when they switched from the pages router to app router. I ended up just abandoning the project, the app router experience was that bad, and haven't really been keen on picking up next.js since then. It's always seemed clear that Vercel has been, at best, OSS- ish . Trying to play both sides of claiming to be open source but also (somewhat sneakily) building a walled garden to lock users into their…

> next.js when they switched from the pages router to app router It is react-router all over again. For those who weren't around, react-router appeared early in React's life, and lots of people were using it. But, for every major version they released, they completely changed the way of doing the routes/routing, so if you wanted to use a maintained release, you'd have to constantly refactor, often without any real ga…

I was kind of offended by this with React Router version 6.4 and again when I saw the library/framework split with version 7, but without having time to switch I've found that the things like loaders and fetchers and useMatches and BrowserRouters are just what I should be doing, ergonomic and useful. Adjusting to them is moving my app forward.

Re: You should know this before choosing Next.js

#118

Post by tmpz22 »

amrocha wrote: post #115
tmpz22 wrote: post #42

Earlier quoted context omitted.

React-router can still cause weird build issues to this day, particularly with LLM generated code that cannot understand version compatibilities.

If you try to build incompatible code and it doesn’t work, that’s not a bug

I'd argue there are too many incompatibilities between minor and major version changes between the "core" react libraries (DOM, react-router, etc) and those teams were a bit reckless with the API surfaces and how they fit together.

At the end of the day it's free software and it's not like I've been submitting PRs to improve it. Further react-router is something you can setup at the beginning of a project and largely never touch again. Its not the end of the world, but it does cut a lot of folks who are new to React, Frontend, etc., and contributes meaningful costs to frontend development as a whole.

Re: You should know this before choosing Next.js

#119

Post by joshcsimmons »

I just don’t understand takes like this at all. No tech scales without bottlenecks. Shopify built an empire on Rails, a framework frequently criticized for scalability issues, yet they thrived because they knew how to navigate its limitations. Great engineering teams turn bottlenecks into solved problems, not dealbreakers.

Re: You should know this before choosing Next.js

#120

Post by amrocha »

tmpz22 wrote: post #118
amrocha wrote: post #115

Earlier quoted context omitted.

If you try to build incompatible code and it doesn’t work, that’s not a bug

I'd argue there are too many incompatibilities between minor and major version changes between the "core" react libraries (DOM, react-router, etc) and those teams were a bit reckless with the API surfaces and how they fit together. At the end of the day it's free software and it's not like I've been submitting PRs to improve it. Further react-router is something you can setup at the beginning of a project and largely…

I’d argue you should read the docs and write code that works and you wouldn’t have any problems
Post reply on HN