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

571–580 of 602 posts

Re: Next.js is infuriating

#571

Post by tacker2000 »

conor- wrote: post #511
tacker2000 wrote: post #392

Earlier quoted context omitted.

Again, why would one need such a heavyweight tool? Most frameworks have powerful loggers out of the box, like Monolog in the PHP world.

What specifically is heavyweight about OTEL? At its core it's a standard for producing structured logs along with some standards for exporting/collection. The heaviness is really implementation-specific and can vary stack to stack There's even a handler for monolog in PHP - they are not necessarily mutually exclusive https://github.com/open-telemetry/opentelemetry-php/blob/mai...

Yes but instead of just logging to a text file for example you need OTEL, thats my point.

The fact that Monolog has a handler for this tool isnt relevant, but it shows that there is one more layer of complexity tacked on.

Re: Next.js is infuriating

#572

Post by manchmalscott »

Voultapher wrote: post #356
tankenmate wrote: post #343

Earlier quoted context omitted.

it might be a bit over the top but there is Cogent Core[0]; it supports apps on desktop, mobile apps, and the web. it even supports 2d and 3d. and it's all in go, backend and frontend (using WASM). [0] https://github.com/cogentcore/core

As much as I hate Next.js as the next guy, let's please not push full canvas rendering approaches. They SUCK. Their https://www.cogentcore.org/core/ own site is slow to load, scrolling is visually painful since it render at what I assume is 60Hz and not my native much higher monitor refresh rate. They are expensive in terms of computation, wasting resources on the machine, to display text. Want to select text, better…

Oh my god, I thought you were exaggerating at least a little.

The “static preview” it shows while it loads (for like 10-15 seconds!) is so much smoother and nicer to scroll around than the actual thing. On mobile, every third scroll attempt actually opens the right click context menu. It’s a stuttering mess on my high refresh rate phone. Nobody should ever make websites like this.

Re: Next.js is infuriating

#573

Post by techpression »

chipsrafferty wrote: post #550
elbrian wrote: post #533

Earlier quoted context omitted.

You mean like this? nvm use && npm i && npm run dev

Ok, 50 packages have critical vulnerabilities now

And another 30 didn't use versioning correctly so they installed new dependencies of their own that broke things three levels deep. Yes, based on a true story.

Re: Next.js is infuriating

#575

Post by digianarchist »

tshaddox wrote: post #493
digianarchist wrote: post #455

Earlier quoted context omitted.

They validated this on the thread. They made an architectural decision to run middleware only on edge.

That's unrelated to the complaint I'm responding to, which is simply that you can only provide a single middleware file. This is merely a DX problem. You absolutely can develop your own composeMiddlewares function and import different middleware functions from different modules. It's just on you to do that, and to reimplement some basic functionality for each composable middleware function (like matcher regexes).

From their blog post:

> Previously, Next.js middleware only supported the Edge Runtime, which provided better performance and isolation but had limitations when integrating with Node.js-specific libraries and APIs.

That's not something that can be resolved with a library abstraction. That was an architectural decision.

Re: Next.js is infuriating

#576

Post by randder »

jimbokun wrote: post #567
simpaticoder wrote: post #482

Earlier quoted context omitted.

Java Spring is at root a way to combine large software components (singletons) together in a controlled manner (dependency injection). It doesn't really have an opinion on what you do with it, or even if you use it for webapps. In fairness the Servlet API (which predates Spring) was and always has been really good (which is why it's still the foundation of everything webapp in the Java ecosystem). Oddly enough, loggi…

Spring Boot pulls in countless dependencies without warning. It can generate classes without you asking it to. It will run code just because you added a dependency, even if you don't explicitly call it. A lot of functionality is action-at-a-distance activated through annotations, which could just as easily be simple method calls which are easier to trace and debug. Version updates are aggressive about making breaking…

Spring Boot is not Spring (Framework). (Yes it makes use of it).

Re: Next.js is infuriating

#577

Post by h4ck_th3_pl4n3t »

cookiengineer wrote: post #125
christophilus wrote: post #93

Earlier quoted context omitted.

This has nothing to do with multithreading, though?

Not OP but wasn't the article about lots of async/await context issues? If the handle() method of the middleware API would have provided, say, a context.Context parameter, most of the described debugging issues would have been gone, no?

Yes, that's what I meant

Re: Next.js is infuriating

#578

Post by arnorhs »

conradkay wrote: post #454
mhitza wrote: post #148

Earlier quoted context omitted.

Don't you find it problematic, as a framework that's 8 years old to already have reached version 15.x? Assuming they follow semantic versioning and those are 15 different backwards incompatible upgrades?

I haven't used next.js but it looks like they have mostly automatic/codemod migrations `npx @next/codemod@canary upgrade latest`

Yes, those have been really decent IIRC - don't remember ever having issues upgrading

Re: Next.js is infuriating

#579

Post by tobyhinloopen »

balamatom wrote: post #562
tobyhinloopen wrote: post #513

Earlier quoted context omitted.

Is there a solution? What do you consider the least bad interactive frontend solution?

"Frontend" is literally the integration of Web Platform APIs. So you need (1) the knowledge of what platform APIs exist (2) the ability to reason about existing abstractions (3) the ability to define abstractions. In modern life all three are considered unsafe things. Therefore to prevent people from entering invalid states exists The Framework: useless abstraction layer that does nothing besides be conventional . Th…

I don’t think you actually answered the question but I totally don’t mind because it was a fun read.

Old Vue is nice, we still have some Vue apps and they’re just running without major headaches. I do recall some distinct issues with properties introduced on objects after initiating the component not being reactive, but it has mostly been an acceptable experience

Re: Next.js is infuriating

#580

Post by recroad »

FredPret wrote: post #425
recroad wrote: post #212

I feel a poor tool choice for your use case should not give you the right to blast the tool and it's design decisions. Most of those complaints are resulting from not understanding how NextJS works and the design decisions that it's creators have made. For example, the middlewares. they're to be treated as a hook. If NextJS had a mechanism for having handlers like Express does, you'd have complained about handler exe…

What challenges did you pick up with Elixir?

Elixir/Phoenix is awesome, no complaints overall. A few small things:

- Passing data from LiveComponent's/JS is a bit of a pain (need to use update())

- phx-hook doesn't always pay well with re-rendering state changes

- Directly calling JS functions (e.g, getting Apple Pay to work) isn't clean

- Can't use attr when using LiveComponents (need to wrap them in a functional component)

- Unique ID requirement for LiveComponent is a pain (so is wrapping them in a div)

- No great APIs for updating session data when using sockets

- Can't pass params to LiveView in live_render, have to use session

Post reply on HN