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

431–440 of 602 posts

Re: Next.js is infuriating

#431

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…

Ok, I think I can reproduce it by starting the selection from the end of the previous line.

I've reported the issue here: https://github.com/hyperlink-academy/leaflet/issues/196

Re: Next.js is infuriating

#432

Post by specialp »

conor- wrote: post #364
throwaway150 wrote: post #31

Earlier quoted context omitted.

Appreciate the response. But ... > Since OP mentions logging, it’s worth noting that for instrumentation and observability we’ve embraced OpenTelemetry and have an instrumentation.ts convention That makes it sound as though the answer to a clumsy logging facility is simply to add another heavy layer of complexity. Surely not every application needs OpenTelemetry. Why can’t logger().info() just work in a sensible way?…

> Why can’t logger().info() just work in a sensible way? I think OTEL is pretty sensible for a vendor-free and if you want to have a console logger you can use the console exporter[0] for debug mode during local development. Also if Next is designed as a framework to make it easy to build production-grade apps, having a standardized way to implement o11y with OTEL is a worthwhile tradeoff? If you view that as being o…

Because making it easy to run and monitor NextJS is never in their interest. The difficulty of that is what pushes people that make it to production with Next onto their platform. The goal is to provide more impressive preoptimizations that complicate the stack more and make it more difficult to run NextJS yourself and actually use any of them.

Re: Next.js is infuriating

#433

Post by robertoandred »

rco8786 wrote: post #219
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…

> a relative misunderstanding of exactly where the code is running. This is the exact problem with the App Router. It makes it extremely difficult to figure out where your code is running. The Pages Router didn't have this issue.

Does it? Just look for "use client" at the top of the file.

Re: Next.js is infuriating

#434

Post by nonethewiser »

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.

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

Im kind of confused by what you mean here. You can use PHP, Java, Ruby, etc. for the backend with Next.js. You can even use if for the SSR server if you want.

I guess you are actually talking about simply not doing server side rendering at all? Im just clarifying because I think that still constitutes using "React for the frontend." I mean, how could React be used for anything BUT the frontend?

The server side rendering is actually one of the objective goods Next.js offers (not necessarily that it handles the complexity of it well). I mean, if you dont need that, sure... that's one more reason to just use Vite. But the backend choice is irrelevant.

Re: Next.js is infuriating

#436

Post by hu3 »

Lucasoato wrote: post #158

> we of course have no idea what actually happened since the default logging is only enabled during development Wait, if you have issues with logging, why don’t you set up opentelemetry? It’s really easy to add into a project [1], and if you don’t want to manage it, you can easily find some cost efficient solutions like Grafana Labs [2]. [1]: https://nextjs.org/docs/app/guides/open-telemetry [2]: https://grafana.com/

OT might be too heavy of a hammer depending on what OP needs.

Re: Next.js is infuriating

#437

Post by WD-42 »

motorest wrote: post #197
zero_shift wrote: post #134

Earlier quoted context omitted.

My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting

> My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting That is my opinion as well. Things like SSR are forced onto users with a very smooth onboarding, but I'm concerned that in practical terms this perceived smoothness can only persist if the likes of us pay the likes of Vercel for hosting our work. In some degree I f…

It’s already been captured. Check out the docs for creating a new React app on react.dev:

https://react.dev/learn/creating-a-react-app

It throws you straight at Next.js

Re: Next.js is infuriating

#438

Post by robertoandred »

jcuenod wrote: post #374

Posts like this really mean "this doesn't work like I expect it to based on my background with some other technology". But in this case, I tried in earnest to use nextjs for a project with auth & stripe, etc. this past week, and I can't believe how frustrating it is to get stupid things like modal dialogs to work properly in the client. I have tons of experience with React SPAs. But the client/server divide in Next r…

Huh? Modals work the same way they do anywhere else.

Re: Next.js is infuriating

#439

Post by mrsmrtss »

porridgeraisin wrote: post #393
AstroBen wrote: post #355

Earlier quoted context omitted.

It's weird how C# can elicit such an eugh response, and TypeScript gets so much love. They're.. made.. by.. the.. same.. people I agree people really need to update their mental model of where dotnet is at. I worked with it on Linux and it's a great experience

Probably because the standard way of writing C# is too OOP-ish (for lack of a better term). Typescript lets you write just usual functions handling mostly typed objects, which is about as much abstraction as most people want (except for 1-2 classes for stuff like `BTree`), and as much typing as most people want.

It's more likely they never tried C#, but have a very strong negative bias towards it nevertheless. C# can also be written very functional if you want, it's a multi-paradigm language like Typescript itself.

Re: Next.js is infuriating

#440

Post by Etheryte »

pjmlp wrote: post #418
Etheryte wrote: post #398

Earlier quoted context omitted.

Spring Boot for example, which is arguably one of the most common ways to do Java anything these days. If you're trying to make a point, it would be considerably easier if you just said what you mean, because so far you're not making one. You could've easily looked up any of these questions.

Wrong again. Spring Boot doesn't provide a serious production quality deployment without configuration. Bare bones logging into standard out, yes. That isn't production quality . Production quality is telemetry logging, log rotation and zipping, forwarding logs to Kibana or Datadog dashboard.

This is a silly no true scotsman argument. First you don't say what you mean and then stick up your nose when no one has any idea what you're on about. Anyone is capable of making up an arbitrary set of requirements that no language nor framework fulfills. This doesn't change the fact that for most languages and frameworks, logging is a boring, solved problem. That Next.js doesn't bring that to the table is more than telling.
Post reply on HN