I reported a bug months ago where app router hydration errors were occurring while copy and pasting example code directly from their official docs. Still hasn’t been fixed.
I will never recommend a project use Next for as long as I’m a software engineer. Maybe a bit dramatic, but a dumpster fire is brewing over at Next.
Completely agree with the point of middleware only supporting the Edge runtime. This borders vendor lock-in and continues to be an ongoing debate: https://github.com/vercel/next.js/discussions/46722. Hope they add the ability to switch to Node.js runtime.
I've had the encountered same problem when trying to just get the request path in order to highlight the current active page link in a navigation. It's simply not possible with Server Components only.
I ended up having to wrap each nav link in a client-side component, meaning the active state is lost in no-JS land (but will still render the nav on the server). The provider just wraps the link to provide a class, which can then be used to identify, with CSS, which link is active.
I really don't understand how cookies and headers can be provided, but not even just the requested path.
I started a project that is using Next.js 13 w/ Page Router (App Router was still in beta when I started it.) I haven’t looked much at App router yet, but what are the technical pros/cons of continuing to avoid it?
A pretty sad state of affairs. I really liked Next.js pre App Router but feel this new direction is not for me. Sure we can still use the legacy routing but they clearly steer towards App Router/RSC.
half-baked APIs seem to be par for the course with Next. Vercel feels like the Microsoft of React, trying to force everyone in the ecosystem to go through them. Gives me a cold prickly feeling!
That's a tough spot to be in. I would probably use Next 13 with page routing. If say Remix gets more traction, switching shouldn't be too difficult. Same for Qwik which has a similar tsx/jsx syntax.
It's going to be interesting to see how this pans out. It looks like more people are getting annoyed with the direction Next.js is going.
Deno supports importing node modules now so you can import whatever dependency you desire. I even used browser imports on the server, it's so flexible.
Island based hydration is a great idea and it's a super productive framework to use. Fresh uses Preact, I spent the last few months using it and I never caught myself fighting with the framework, unlike nextjs where it's a constant struggle
Feels even better than the “pages” router from next, it’s a hell lot more stable and simple, and you get a real backend framework such as Laravel which is great.
Readit News
I will never recommend a project use Next for as long as I’m a software engineer. Maybe a bit dramatic, but a dumpster fire is brewing over at Next.
Deleted Comment
I ended up having to wrap each nav link in a client-side component, meaning the active state is lost in no-JS land (but will still render the nav on the server). The provider just wraps the link to provide a class, which can then be used to identify, with CSS, which link is active.
I really don't understand how cookies and headers can be provided, but not even just the requested path.
I tried Next 12 and loved it. Sad to see bad direction.
Deno supports importing node modules now so you can import whatever dependency you desire. I even used browser imports on the server, it's so flexible.
Island based hydration is a great idea and it's a super productive framework to use. Fresh uses Preact, I spent the last few months using it and I never caught myself fighting with the framework, unlike nextjs where it's a constant struggle
Feels even better than the “pages” router from next, it’s a hell lot more stable and simple, and you get a real backend framework such as Laravel which is great.