- layout cannot access pathname of the current URL: https://github.com/vercel/next.js/issues/43704#issuecomment-...
- App Router cannot pass data to layout: https://github.com/vercel/next.js/discussions/44506
- router.push does not revalidate server cache: https://github.com/vercel/next.js/discussions/54075#discussi...
- stylesheet order is not guaranteed and persist accross environments: https://github.com/vercel/next.js/issues/16630
- script tag with strategy=beforeInteractive does not work in root layout: https://github.com/vercel/next.js/issues/51242
Some other thoughts:
One thing Next.js likes to do is provide a lengthy and well-formatted post explaining their philosophy and reasons why a particular issue cannot be resolved. It appears convincing at first glance, but if you take a closer look, you'll find that they are just elaborations using their own terms and logic. In other words, they explain the efforts they make to justify their decisions, which stem from poor design choices they made. They like doing things look correct but not necessarily useful, similar to the feelings I have when dealing with accountants.
- Pass data to layout answer: https://github.com/vercel/next.js/discussions/44506#discussi...
- For router.push one, I believe you're looking for this: https://nextjs.org/docs/app/api-reference/next-config-js/sta...
- Stylesheet ordering: https://github.com/vercel/next.js/pull/63157
- Script tag: https://github.com/vercel/next.js/issues/51242#issuecomment-...
Other frameworks manage completely fine to expose location data without implying dynamic rendering.
I also hate how the moment I use headers and cookies to get something like I might get from the request object I am forced to render dynamically this kills SsG for me.
I honestly thought I was the problem. Glad to here someone else is struggling
Started on Next.js 12. The DX was overall "janky" and we ran into many issues with integrating third party components. Next.js 13 didn't make things better.
We switched to Astro.js and generally happy with it.
Internal discussion is that we'd give Nuxt.js (Vue SSR meta-framework) a try at some point for future projects as well. But no Next.js.
It's interesting to note that both Walmart.com and Target.com (as well as numerous other large e-commerce properties are Next.js). I think that should be telling who the audience for Next.js and, by proxy, who isn't.
- Fighting hydration mismatch errors has been extremely annoying
- (related to hydration errors) react server component is a misnomer - "use client" still does a server side render
- Compile time is around 10s+ for dev mode because if you happen to import from modules that have tons of exports, it will compile the entire thing even if you're not using them
- next-auth has nonsensical APIs (eg the jwt and session callbacks); if you want to do federated sign out, it's also a hacked solution you have to come up with on your own
- app router middleware is difficult to extend. want to have multiple pieces of middleware like express? you'll have to hack your own solution since they only support a single piece of middleware
- caching problems. next 14 cached nearly everything, and 15 now disables some of it by default to help with the issues around stale data being rendered
- no way to specify that next.js runs in node.js mode and not edge mode. have to use annoying comparisons to run node.js specific code
developing a modern JS app shouldn't be this difficult and annoying that I totally regret using it
Of course! Duh! The concepts of “server side rendering” and “dynamic imports” are very naturally, obviously and intrinsically linked.
Using “use client” is obviously totally stupid when you want to render on the client!
Thank you, Next
Fast forward to today, frameworks are built on top of a massive amount of abstractions and philosophies, some of which don't really make sense together. There is so much stuff to learn at the top layer that, in the long run, you'd be more efficient just learning the fundamentals and working from first principles.
Even though I started coding in 2004, I started with Flash/ActionScript on Windows and I was wondering why anyone would need to use the console/terminal in this day and age... What happens is; over time, you will repeatedly get into situations which will force you to peak under the bonnet and the more you do that, the more you realize that actually a lot of these abstractions are unnecessary... Then you inevitably end up becoming a Linux nut who uses bash for everything.
I think the clearest illustration of how needlessly complicated a lot of frameworks/abstractions are, from back in 2004, was the Windows API in C++... Back then, you needed to write like 100+ lines of code just to create an empty Window! At the time, I felt so clever for memorizing over a hundred lines. I now realize how ridiculous that was. It invented a lot of abstractions, but those abstractions didn't make things simpler nor more flexible. Incorrect abstractions like this are everywhere nowadays though they moved away from the Desktop and to the web instead.
I wouldn't go this far. More realistically, Vercel's early fit was with devs just starting in their journey and Vercel has since moved beyond.
However, they haven't told anyone that they are no longer prioritizing the beginner devs and that's the problem.
I liked NextJS up to version 12. Sometime after that I fully checked out. I currently feel a general vibe of instability from Next/React which pushes me to other things.
Also, I have no idea if I'm even in Vercel's ICP anymore. I figure that folks with feelings similar to Pilcrow or myself here are no longer ideal Next users and that's ok!
It could even be for the best. Seems that Vercel's biggest customers are happier than ever which is what really matters.
Edit: there's an adamdotdev youtube video which I strongly identified with on a similar wavelength[1].
> I have no idea if I'm even in Vercel's ICP anymore
You never were.Walmart and Target's dotcoms are on Next.js. Are you building an application that needs SSR to optimize for SEO? Do you have deep React expertise? Dedicated teams for tooling and devops (CI/CD/test automation)?
It works for Walmart and Target because it precisely addresses their needs and they have enough resources to support manage the complexity.
The Copenhagen Book: general guideline on implementing auth in web applications (199 points, 52 comments) https://news.ycombinator.com/item?id=41801883
To the authors credit, the community is way too excited about RSC and the documentation on NextJS suggests you should really be using it but it’s absolutely half baked. Use the Pages router for now.
RSC is a new paradigm that you would probably be better off to ignore until its a few years old. Just like many things in frontend and tech in general. Don’t use the shiny new thing unless you wanna be cut on the bleeding edge.
RSC isn't a problem it is next implementation of it that is.
Understanding SSR,SSG,CSR etc is obvs where people get unstuck and that's fine but the api (use client, use server) and the arbitrary limitations on whatcan and cant be done serverside make this framework he'll to deal with
I think next.js is in danger of not existing. Openai moved to remix. I am moving to Astro many people I know are considering moving
It's possible this post influenced us making the docs better last year.
There, someone said it. I’ve never seen a single project that uses React just as a library, it’s always at the core of the project and the code is built around its life cycle and abstractions.
I’ve seen Vue used as a library at times (to make just a part of a larger site dynamic) but in like 95% of cases it’s also used as a framework, even if you end up with other libraries that integrate with it (e.g. Vue Router, something for i18n and Pinia for stores) to make it seem as one unified whole.
Maybe the whole separation into libraries and frameworks in unhelpful on some level.
it seems as if a company enthralled by AI fever at the very top of leadership, preferring hacking into some new dubious tangential product offerings than circling the wagons and fortifying their core proposition.
It is already very complicated to build app with many dependencies, and to manually manage the dependencies included in the build is nearly impossible.
For example, if you want to update the production db after you deployed the app, including the prisma ORM cli not very straightforward.
It went from a solid react framework for generating websites to one that clearly had use cases in mind and was always pushing you in a particular direction. Whether that would be with Next Image and the inability to statically optimize images at build time to an obsession with react server components.
And with Next Image for example, there was a clear motive to kneecap it and make it so it only really worked inside Vercel (until OpenNext came along). Gatsby could optimize images at build time and there's even an excellent plugin for NextJS that does just that. The devs had almple time to implement this feature however even today it's not available.
I've since switched all my "website" development to Astro and haven't been happier.
Some guardrails/constraints are good and should remain, but sometimes you want to do away with certain constraints as the project grows and requirements change. 'Everything frameworks' tend to fall short in the long run.
Personally, I didn't get into Next.js because I didn't see the value in server-side rendering (SSR). IMO, if you want good SEO, you should make a plain HTML landing page (avoid single page JS app)... Single page apps are good for applications like dashboards and control panels; but note that these applications are usually private and require log in... So you don't want those to be indexed by search engines anyway.
It seems like Next.js serves a relatively narrow set of use cases. I've come across many cases of people wanting to use Next.js for their next project because they want to get on the hype bandwagon and they have a vague sense that it will help their career prospects... But in almost all cases, the benefit of Next.js boils down to SSR and after some questioning "Why do we need SSR for this?" it turns out that we don't.
I have come across several projects which used Next.js but didn't use SSR and in one case, the founder openly stated that they didn't like using this aspect of it... The attempt by Next.js to blur the boundary between client and server is often ill-informed and a potential source of security vulnerabilities. So really, the only thing which Next.js brought to the table in that case was the file/folder structure... Not sure that's a good reason to add such a substantial dependency.
I think the TLDR is that you can't mutate cookies in server components so that they can fully support HTML streaming. The workaround is doing a second request from the client to update the cookie. Kind of fuel for the conspiracy theories around app router being about driving vercel revenue.
FWIW I'd gladly opt-out of streaming to eliminate the cost and complexity of making a second request.
If you're wondering "why streaming?": https://vercel.com/blog/how-streaming-helps-build-faster-web...
I'm glad to see this stated so clearly. It's important for frameworks to be upfront about the use cases being served and the trade-offs that are being made. I think a lot of the negativity that I see on the web is because Next.js was the right choice [for them] in the past, but once it moved towards streaming as the primary paradigm, those same people probably are feeling left in the dust. I think it would be good for the Next.js team to reiterate this and/or make it more clear in the docs so that new devs can make informed decisions when evaluating Next.js for their next project.
i hear you on not having to build for everyone and it's good to take a stance and not be for everyone / every use case. dhh talked about this at railsworld recently [0].
i think i've got it working ok with the second request to update the session (as suggested here [1]).
[0]: https://www.youtube.com/watch?v=zPBbHu-BKpQ [1]: https://github.com/nextauthjs/next-auth/discussions/9715
A lot of the answers to these questions are plain as day to see as an outsider:
VC dollars demand VC returns.
NextJS will continue to shepard react in a direction that benefits Vercel and pay big bucks to tech influencers like the mustache dude.
Walk away, there are better ways to build web apps today.