22 ms·

Next.js is infuriating

• tobyhinloopen 1y ago
  [flagged]
  • deleted 1y ago
    [deleted]
  • globnomulous 1y ago
    Thank you for censoring the word "shit." We try to keep Hacker News clean, for families and children.
    • tobyhinloopen 1y ago
      You’re welcome
  • balamatom 1y ago
    JavaScript was made insufficiently expressive on purpose (see Eich, Sun, Scheme). He still ended up sneaking some metaprogramming capabilities into it, though he stopped short of something recognizable like macros. So when the highest grade vendors started taking front end extra seriously since I'd say 2008-2010, what they built basically bulldozed over the things that made JS per se tolerable. Instead, they built frameworks out of the standard imperative primitives in JS, which take things in more of a C++-inspired direction. The "growth hack" is here, as with vaunted Apple, vertical integration. The only way to couple markup to state management to server/client flow does not amount to a framework; it amounts to no framework since the Web was not invented by VCs. To get a framework out of it, i.e. couple developers' practical knowledge to your ecosystem (turning it from general to domain specific but fuck devs right), you also need to couple things in your stack at the wrong places, as exemplified by the already much-maligned misfeature explored in TFA. I.e. for the onboarding flow of a hosting business to work in 2025, you first need to have been teaching bad architecture for a generation. (It's why Meteor.js didn't take.) On the one hand, pragmatic of Vercel to exist in the long shadow of the React/TS monstrosities. On the other hand, it's just one more company whose mere existence in this world has contributed for my work and life becoming harder for no real reason, even though nobody I'm within a handshake is even their customer. Like many, I only learned of them only when I googled, "who the hell made this horrible thing the frontend team over is now stuck with, it's 0.01xing their velocity and frying their brains besides" and, well, now they're here. I would like to remind them to try and measure their externalities.
    • tobyhinloopen 1y ago
      Is there a solution? What do you consider the least bad interactive frontend solution?
      • balamatom 1y ago
        "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. That's a common enough pattern anywhere population's above Dunbar; whether it's embodied by React or TypeScript or Windows or an entirely different order of lowest-common-denominator monoculture is immaterial. Thankfully, software maintains an objective material component - the code, which they're trying to now turn into another wishy-washy thing you interact with using endless imprecise human language. Purely in terms of that, it remains possible to propose some ways to get a project off the ground more efficiently by virtue of dodging the toxic mainstream: TL;DR conventional: native DOM manipulation; state management with Observable; Vite; TDD. TL;DR forward-thinking: same but in proper static language: write in Rust, compile to WASM. TL;DR exotic: ClojureScript or another Lispy language that compiles to JS or WASM. Ofc, unless totally cowboying it, you also gotta be able to counteract the illusion of social proof. Ideally you want to be actively shaming people for building and normalizing bloatware. Preferably packing 1-2 yesmen worth of social proof of your own, just to get basic parity with the "best practices" in close quarters. As always, depends on what you're building, for what purpose, and, critically, with whom... fuck all that though, the objectively bestest solution is always https://github.com/Matt-Esch/virtual-dom https://github.com/Matt-Esch/virtual-dom /s That repo is a milestone of where history took its next wrong turn. I remember it making some waves when it dropped, and it's certainly the first VDOM implementation I saw. I considered it a good, original idea. IIRC, React came around about that time: to take the simple and sane "VDOM" optimization, apply it judiciously (i.e. where it doesn't), and make it possible to bolt enough shit onto it (redux! teaching you to type the same thing thrice before typescript! SAGA! that one weird DB paper from '74 applied to frontends JS' half-baked half-async "generators", just to demonstrate to people that they should revere the old CS publications, and definitely not anything like read them or reason about them!) Just so that people could hold bloody bootcamps about it, where they'd be able to weed out any junes capable of reading MDN for themselves. ("Bootcamp" is another cosmic joke like "Instagram" and "Trump". That thing where they harass people into obedience then turn them into socially sanctioned murderers? Ok checks out, let's name our programming learning experience! It's nothing if not profoundly mission-driven!) Back in those days or a little later, I remember Vue 1 and 2 being pretty great: it somehow managed to do its thing without first having to introduce three whole new dialects of JavaScript and counting. Overall I'm glad to be out of the frontend space for a good while now and only learning about it from the confused screaming of those still trapped there. (Oh and also Next's "static build" is a Docker container I had to cook up myself, which is a next level of ridiculous; as with VDOM, you first need to have seen the past level in order to recognize it as regress, and I presume a lot of people simply haven't had the opportunity to pursue any form of informed comparison) (For "agentic workflows" idk -- just don't use them ffs the externalities are not remotely priced in; otherwise you'd be the exact same problem as them -- the designed-by-corporate-committee frontend DX of the past decade certainly strike me as something that'd make more sense to a statistical model than to a human mind.)
  • tomhow 1y ago
    Please don't post unsubstantive comments here.
• pjmlp 1y ago
  I don't get these kind of complaints, coming from Java and .NET web frameworks, Next,js is the only sane frontend framework followed by Angular. Saying this as someone doing Web related development since 1998, glory days of Perl and CGIs.
  • Etheryte 1y ago
    I don't think the post is an unreasonable complaint. The fact that you have to even think about how to get logs out of your application is insane, never mind all the hoops you need here. Logging should be a first class citizen in anything that goes to production.
    • pjmlp 1y ago
      Interesting, because that is hardly so in most frameworks, logging requires additional libraries and configuration almost everywhere.
      • Etheryte 1y ago
        In most languages and frameworks logging is as simple as import, initialize, done. Here it's far from it.
        • pjmlp 1y ago
          Really, which ones? Because anything Java, .NET and Python, it certainly requires configuration and related infrastructure.
          • Etheryte 1y ago
            Log4j can be as simple as add the dependency and you're good to go. Of course, you can do fancier setups and bridge your logs wherever where it is more work, but out of the box, it's very straightforward and batteries included. I have a very hard time believing you're seriously arguing the case that some of the most commonly used languages don't have good options for logging.
• selfmodruntime 1y ago
  It really is. I am a staunch react defender, I work with it daily and I found the change from class components to hooks to be a better programming model. But whenever I work with Next, I feel like we lost the plot somewhere. I try a lot of frameworks and I like esoteric programming languages, but somehow Next.js, the frontier JavaScript framework embraced by React is the only experience where half the time, I have no idea what it’s error messages (if I get any to begin with) are trying to tell me. I can’t even count the hours I spent with weird hydration issues.
  • palmfacehn 1y ago
    I'm not a React or Next.js user. Others will disagree, but personally I prefer to minimize my exposure to JS by decorating traditional HTML+CSS documents with vanilla JS as needed. I was somewhat surprised when I noticed simple Next.js landing pages would break in Firefox. Worse yet, the failure mode was to overlay all of the content with a black screen and white text, "An application client side error has occurred". It was surprising in that a simple landing page couldn't render, but when I discovered that the cause was a JS frontend framework, I felt that it was par for the course. Perhaps it makes sense to the advocates, but for those of us not on the bandwagon, it can be sincerely baffling.
    • rimunroe 1y ago
      > Others will disagree, but personally I prefer to minimize my exposure to JS by decorating traditional HTML+CSS documents with vanilla JS as needed. If you don't mind my asking, what sort of applications have you worked on, how many contributors were there, how long was their lifespan, and how long did you work on them for? Personally, I've found the type of "vanilla" JS approach to be prohibitively difficult to scale. I've nearly exclusively worked on highly interactive SaaS apps. Using a substantial amount of JS to stitch together interactions or apply updates from the server has been unavoidable. The engineering organizations at companies I've worked at have ranged in size from three devs to over 20,000. Projects I've worked on have ranged from three devs to maybe 500-1,000 (it's sometimes hard for me to keep track at a giant company). I've worked on projects using "vanilla" JS, Knockout, Backbone, Vue, and React[0]. The order in which I listed those technologies is also roughly how quickly the code became hard to maintain. [0] This is not an exhaustive list of which frontend frameworks/libraries I've used, but it's the ones I have enough experience with to feel comfortable speaking of the long term support of[1]. For example, I used Ember heavily for about a year, but that year was split between two projects I spent six months each on. Similarly, I've used Next.js, but only for prototyping a few times and never deployed with it to anything other than a private server. [1] Except Lightning Web Components, which I've used a lot but hate so much that I don't want to dishonor those other technologies by listing it alongside them.
• Rauchg 1y ago
  Heard and appreciate the feedback. We’re well aware of the DX papercuts in Middleware. With 15.5 we made a big step in supporting Node runtime[1] which addresses a slew of issues people have reported over time. If I went back in time, I would have called it Routing Middleware or Routing Handler. A specific hook to intercept during the routing phase, which can be delivered to the CDN edge for specialized providers. It’s also a somewhat advanced escape hatch. Since OP mentions logging, it’s worth noting that for instrumentation and observability we’ve embraced OpenTelemetry and have an instrumentation.ts convention[2] [1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable https://nextjs.org/blog/next-15-5#nodejs-middleware-stable [2] https://nextjs.org/docs/app/api-reference/file-conventions/instrumentation https://nextjs.org/docs/app/api-reference/file-conventions/i...
  • n2h4 1y ago
    [dead]
  • throwaway150 1y ago
    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? This can't be such a hard problem, can it? Every other language and framework does it!
    • conor- 1y ago
      > 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 overkill, perhaps you're not the target audience of the framework [0] https://opentelemetry.io/docs/languages/js/exporters/#console https://opentelemetry.io/docs/languages/js/exporters/#consol...
• Jnr 1y ago
  I like it. I have been involved in software development for 20+ years - Perl, PHP, Java, Pyhon. And Nextjs and React gave me back the joy to develop web frontend again. There are a lot of gotchas and considerations with Nextjs, but it is a framework and it is not unexpected that unless it is developed by yourself, frameworks require some getting used to. There are some things that could be better, especially in non-Vercel-hosted scenarios, and if the backend for frontend part becomes too complicated, I would switch to Nest.js, but overall I am satisfied with Next.
• usernamed7 1y ago
  as a Rails dev this makes me LOL. I would have expected the rube goldburg machine of JS frameworks to be more robust and ergonomic by now, but it looks more to be hacks built on top of hacks with no real vision or technical leadership.
  • b_e_n_t_o_n 1y ago
    Like said in the article, most other JS frameworks are actually pretty good these days.
    • zwnow 1y ago
      I work with Vue 2 and Vue 3, both options and composition APIs and both are pretty great. I dont know how it's like for very complex UI but it 100% fulfills my needs. Also shout out to Pinia, I love you!
      • sensanaty 1y ago
        I have a monstrosity of a Vue 3 project at work and I far prefer it to any "elegant" React codebase I've ever had the displeasure of working with. Boggles the mind that React still has any mindshare to me, Vue and Svelte are both superior to it in pretty much every way except for availability of component libraries (which isn't so relevant in my line of work), and a slight edge in terms of TypeScript support (mostly a problem with Vue's props).
        • zwnow 1y ago
          Yea I would agree. I do not use component libraries ever as I prefer building my own. But I also know that stuff like shadcn also has Vue variants.
        • sfn42 1y ago
          I think React is fine, the problem is that every single react app I've inherited is ass - people just do everything incorrectly and overcomplicate simple things. Components with like 5 different useEffects, huge global state causing all kinds of bugs, way too much frontend logic in general. The amount of JS code that exists just to mimic things you can do with HTML and CSS is staggering. Everyone complains that react is so slow and horrible, it isn't. It's their code that's slow and horrible, react is snappy as hell when you use it properly.
• b_e_n_t_o_n 1y ago
  Remix (cough react router 7 framework mode cough) is like the polar opposite of this, it's just a Request -> Response handler that you have to build your server around manually. Which I found kind of annoying at first but it does give you the freedom to do what you want.
  • adamddev1 1y ago
    I have been frustrated with Next.js changing it's API so much in the last few years and making things more and more complex and confusing. I am wondering about giving Remix a whirl for an upcoming forum/CMS rewrite with custom auth. Anybody else have experiences with Remix?
    • eknkc 1y ago
      If you don't like changing APIs I'd stay away from the Remix guys. I know it is not like Next but I've used react-router, which had some API churn, later evolved to remix and then back to react-router... Backward incompatible changes are the signature of it. The documentation story is a problem too because of that. Completely different things are named the same and they are now building a new Remix, not even on React as far as I can tell. Stick with a single version and you'd probably be happy though.
      • chrisweekly 1y ago
        While the "Remix" renaming / branding is a little confusing, the React Router team has always done a fantastic job delivering a robust solution that properly leverages the web as the platform. Its framework mode (fka "Remix") is simpler and better than Next.js, and more featureful than vite-ssr. Want to mutate data? Use a form. Fetch data? Uses browser-native fetch under the hood. It's all about the fundamentals: HTML and HTTP. You can decide how much clientside JS to ship, and mostly eliminate it. OR, if you want a traditional SPA, go for it. A quick HN comment thumbed on my phone can't do it justice -- but it's very, very good. And its maintainers have a stellar track record. (No vendor bias like w/ Next.js / Vercel.) FWIW, I've been doing webdev-related work for a living since 1998, and React since 2016.
• thiago_fm 1y ago
  Similar to Meteor.js, they've tried to abstract things that aren't really abstractable (is this even a word?). It handles edge-cases extremely poorly, and when you have those scenarios, you either need to find a workaround (so code becomes ugly and painful to maintain) or give up. I've worked with it for a project, gladly never again. I'll extend my feedback about Node.JS backend. Look how many flavors: deno, bun... It's a mess. Node.js a terrible platform for server-side in comparison to Java/C#(performance/stability) & Ruby/Python(dev speed). The only reason it is successful is that everybody knows JS/TS. But just because everybody knows it is rarely a reason to use it. The event loop is quite nice and easy to reason about, but that's all there's to it. It is single-threaded and comes with gotchas, with at the end being in my opinion a negative aspect of it. Many other langs/platforms offer also an event loop for concurrency, but they aren't often used. In the end no matter how much we hate threads, they serve a great purpose that has been battle-tested for so many decades. Unfortunately companies adopt programming languages based on hype and trends, rather than technical reasons. Until when we will have people hyped up about writing web servers in CSS, even though it doesn't make any sense to? TLDR: It isn't only Next.JS, but the whole NodeJS thing isn't that great.
  • balamatom 1y ago
    >is this even a word Everything can be a word if you know what you're trying to say. Don't let anyone tell you otherwise. If they try, say: фakdelengiчpolis! Even though I'm a fan of looking for underlying motivations to what people do, I'd be wary of pointing out "only" reasons for anything. I know it's a rhetorical exaggeration, but still. For example, I've found Node to do what Python does, only better. For example, Node does dependency resolution without involving the OS package manager. And ultimately, people end up using whatever they become comfortable with. Which is not an exact science and people resist it being made into one. (Maybe if it was, it'd be much easier to sell people on working with the "least worst" tooling that is not actually good for anything.) But the important thing is that on the backend they're all different. The baseline is the CPU, and you get to choose between real tools with real histories of real tradeoffs. Even if the tradeoff is "run JS" or "be written in C++" or smth else. On the frontend, the baseline is JS, and whatever the browsers bolt to JS, and as us few sane keep pointing out, JS land is already such an "OS-within-an-OS" that there is very little point to building entire freaking frameworks between that and the application, just for the sake of having to swim through someone else's moat instead of invoking the APIs directly (which are also better designed for the most part). So, in order to differentiate the market, one would need to build at least 1 "layer of layers" on top of JS, some products in which are gonna more pointless, while others are gonna be less pointless (all of this to all different people of course). That way the user gets to choose between what sucks more vs what sucks less, and one gets to feed on the attention paid to the choice of lesser evil; or -- if insufficient attention is paid -- to entirely direct the choice in whatever direction. It's a win-win.
• ollysb 1y ago
  When they transitioned to the app router it was like they'd given some bootcamp graduates a crack at "improving" on the express apis - which are mature and roughly align with the composable russion doll approach taken in servlets, rack, plug and any other server interface I've ever seen. Aside from the abysmal middleware api you also have the dubious decision to replace having a request parameter with global functions like cookies() and headers(). Perhaps there is some underlying design constraint that I'm missing where all of these decisions make sense but it really does look like they threw out every hard fought lesson and decided to make every mistake again.
  • arend321 1y ago
    I believe the obsession with streaming is a major factor in the new constraints. Together with supporting the lowest common denominator, edge runtimes.
    • n2h4 1y ago
      [dead]
    • Etheryte 1y ago
      And the reason they're all in on streaming to begin with is because they're sending massive amounts of data back and forth all the time. Like Sean Goedecke said in his API design writeup [0], a technically poor product can make it nearly impossible to build an elegant API. I believe we're seeing the same thing with Next.js, all of these wonky interfaces derive from the underlying architectural issues. [0] https://www.seangoedecke.com/good-api-design/ https://www.seangoedecke.com/good-api-design/
      • deleted 1y ago
        [deleted]
      • conradkay 1y ago
        Maybe it's a good design from the perspective of making more money from your hosting business
• solatic 1y ago
  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 issues * You're willing to pay Vercel a high premium for them to host * You have no need for background task processing (Vercel directs you to marketplace/partner services), so your architecture never pushes you to host on another provider. Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR.
  • vendiddy 1y ago
    And even if you fall under the first category, I find it hard to believe that the performance bottleneck is solved by using Vercel and SSR. With all the other crazy shit people are doing (multi-megabyte bundle sizes, slow API calls with dozens of round-trips to the DB, etc) doing the basics of profiling, optimizing, simplifying seems like it'd get you much further than changing to a more complex architecture.
  • b_e_n_t_o_n 1y ago
    Yeah this is basically it. Vercel is trying to solve for optimised performance by using a combination of React Server Components, Partial Pre-rendering, Edge servers, streaming, etc. A lot of their seemingly weird design and API decisions basically come down to that. If you need it, it's good that it exists. But you can also go pretty far with doing some ssr in an edge function too.
    • cluckindan 1y ago
      I would be more inclined to believe it’s an end product of years of simultaneous resume and job security driven development.
      • boppo1 1y ago
        LIRPslop, as Brad Troemel would put it.
• divingedm 1y ago
  Looks like we're all joining the anti next.js train especially as more and more vibe coded apps seem to be building on next.js!
  • balamatom 1y ago
    It's the designed-for-vibe-coding framework, same as its creators are the designed-to-be-replaced-by-AI cohort.
• Vinnl 1y ago
  The direction React and Next.js have been moving is to give you very granular control over where your code runs, and when. The previous model was that you simply have code that runs on a server when a request comes in, sends a response to the client, and then the code in that response is run on the client. Instead, now we have a situation where some bits run on the server, some of them on the client, which call out to some bits on the server again, and all of this can happen either before or after the server started sending the response. And then on e.g. Vercel, you also have edge functions as an additional permutation. Which is kinda neat, but also massively complicates the mental model.
• eknkc 1y ago
  I have a tendency to use different stuff on new projects for the sake of it. I've built apps with express + react on client, angular, vue, next, nuxt.. Used go, .net, node, php etc on the server. I always find good and bad parts and appreciate different aspects of different solutions. Not Next though. We built a pretty large app on Next and it was painful from start to finish. Every part of it was either weird, slow, cumbersome or completely insane. We still maintain the app and it is the only "thing" I hate with a passion at this point. I understand that the ecosystem is pretty good and people seem to be happy with the results given that it is extremely popular. But my own experience has been negative beyond redemption. It's weird.
• DanielHB 1y ago
  When I first saw Next.js I was immediatelly reminded of Meteor.js. I did invest a bit in learning into it and did some personal projects. But quickly realized it was both over-abstracted and inflexible which made it really hard to get it past prototypes. But these solutions keep coming up because they bring one thing: Self-contained / "batteries included". Just the other day there was a thread in hackernews about Laravel vs Symphony and it was the same thing: shit breaks once complexity comes in. If you compare those solutions with the old model that made NodeJS / React SPA get so popular, so fast: Buffet-style tooling/libraries. You basically build your own swiss army knife out of spare parts. Since all the spare parts are self-contained they have to target really low abstraction levels (like React as a component library, HTTP+Express as a backend router, Postgres as DB). This approach has many disadvantages but it really keeps things flexible and avoids tower-of-babel style over-engineering. As in a lot of layers stacked on top of each other. Not that the complexity goes away, but instead you have a lot of layers sibling to each other and it is more doable to replace one layer with another if things aren't working well. It is understandable why "batteries included" is so popular, it is really annoying to stitch together a bunch of tools and libraries that are slightly incompatible with each other. It definitely needs people with more experience to set up everything.
  • bapak 1y ago
    > it is really annoying to stitch together a bunch of tools and libraries that are slightly incompatible with each other This is my job. We're a small team and my job is to keep things up to date. Insanely time consuming. Packages with hard dependencies and packages that stopped being supported 5 years ago.
    • DanielHB 1y ago
      Yep, been there. It is a lot better these days for React SPAs but it is still a pain. Fact is the only way around this in the frontend without a monolitic "batteries-included" all-encompassing all-knowing all-mighty framework is through standardization which can only be pushed by the browsers. Like if browsers themselves decided how bundlers should work and not have them be extensible. And this tooling-hell is not only a browser frontend problem only either, it is also quite common in game development. Where you also have these monstrosities like Unreal Engine that "includes batteries" but makes it really hard to troubleshoot problems because it is so massively big and complex. A game engine is basically a bundler too that combines assets and code into a runnable system to be run on top of a platform.
• UK-Al05 1y ago
  Next.js is marketing to get you locked into vercel hosting.
  • poisonborz 1y ago
    Using nextjs for years without paying a cent to Vercel. If you want React SSR, why would you create a DIY solution if there is a framework with huge community and support?
• lmm 1y ago
  They're trying to do something that's fundamentally very hard. Unifying server-side and client-side code was always going to cause confusion when the difference becomes relevant. Personally I'd rather go in the direction of having code that's explicitly server-side, explicitly client-side, or explicitly shared utilities. But you'd need more of a type-safe mentality to take that approach, and you'd probably scare off the majority who prefer runtime errors over build-time errors.
  • palmfacehn 1y ago
    Your observations apply generally. Debugging "magic" frameworks is often more complex than starting with simple basics and a coherent design. As a bonus there are less dependencies, less build issues and lighter pages or binaries.
    • jama211 1y ago
      Well said.
  • lysecret 1y ago
    Fully agree really enjoying TRPc for this.
• tiku 1y ago
  Through a customer I've come into contact with InertiaJS. React with Laravel made my work so much simpler. Routing through Laravel was easier for me. The data sharing from Laravel to the frontend is painless. I also like the server side, PHP works better for me than a Javascript server. I've had some weird bugs with nodemon, pm2 and other server tools.
  • jeppester 1y ago
    I also recommend inertia. It really doesn't do much, which is very refreshing coming from Nextjs. It's simple tooling for backend for frontend-style APIs, taking care of basic routing, fetching of data, and submitting forms. While inertia was invented for Laravel, I'd argue that it works even better with Adonisjs. Because Adonisjs is TypeScript you can infer the types coming from the backend.
    • 0xblinq 1y ago
      +1 for this stack. Adonis + Inertia works wonderfully well. It's the best of both worlds. And the simplicity of this architecture is something to admire. It's very easy to know what's going on at every point: It's just requests, responses, middlewares and routes/views. Simple and easy, while still super powerful.
• BoredPositron 1y ago
  Can't wait for the opinionated fork that gets abandoned in 3 weeks.
• anonzzzies 1y ago
  As much as I don't like most things about nextjs (I could write a vastly larger blogpost about it but won't as I like to keep my heartrate down), it feels like claude was trained specifically for it. In our experience, claude code is better at nextjs than other frameworks.
  • latentsea 1y ago
    That seems like the most unfortunate of reasons to choose it as a framework for new projects, though. I hope that doesn't become the deciding factor in the future.
    • anonzzzies 1y ago
      Yes, we try not to do that. But I know very many people do.
  • jjani 1y ago
    Significantly better than just React and a Node backend? I doubt it, what's the comparison here?
• markusstrasser 1y ago
  the interesting web problems (collaborative tools, creative software, scientific computing) have to fight against a framework ecosystem designed for the blandest landing pages. Nextjs and most web frameworks assume you're building an e-commerce site that has to only differentiate on loading speeds.
• chvid 1y ago
  React server components and server side rendering should never have been in react but instead should have lived its life as a separate project.
  • brazukadev 1y ago
    Absolutely! But that is not the first time React changes its core. For me, it is dead now.
• csomar 1y ago
  Anyone who is running back-end code in Next.js has no idea what they are doing. It could be acceptable if it is a toy project and you want to get something quickly but even for a small operation or MVP, the whole thing is not coherent. I've wrote previously about nextjs: https://omarabid.com/nextjs-vercel https://omarabid.com/nextjs-vercel My opinion remains the same: Most of the issues in Nextjs are not a bug but a feature. A feature that only functions and locks you in Vercel platform. Since their routing/SEO/content features are also now less functional, there is really very little reason to use Nextjs especially with React Server Components.
• 999900000999 1y ago
  Modern development in a nutshell. You want to use something full of abstractions to the point you have no idea how it actually worked. You did this to save time. Then when issues occur it's someone else's fault. That said, let me pass in a flag to get my dev logs in prod. That's ultimately what the author wants.
  • willvarfar 1y ago
    reminds me of this talk https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4 :)
• parham 1y ago
  I didn’t fully read the post, but pretty sure they have a good point. I inherited next.js on a project it is the absolute worst framework. I don’t need/want to elaborate.
• sarreph 1y ago
  I convinced myself to hate App Router before even trying it because of all the negative sentiment on HN. After using it in three production-scale projects now, I think it's a great isomorphic JS / TS framework. It's as close to a "batteries included" (such as Rails or Phoenix) system that the JS ecosystem has. And yet, people generally like to shit on Next.js I sense because they haven't taken the small amount of time investment required to actually just understand it: which I fear is especially true if they came from Pages Router. This kind of fallacy appears to hold true in the OP -- bemoaning that you "can't have multiple middlewares or chain them either"... yes, you can? Sure, it's different from the Express way of doing things, but you absolutely can get it to do what you want. Was Express ever _that_ easy before you actually understood it and knew what you were doing?
  • dizlexic 1y ago
    > Was Express ever _that_ easy before you actually understood it and knew what you were doing? yes also sails.js was the bomb.
• coxmi 1y ago
  Deno Fresh seems like it has the right approach. It’s not complicated, the docs are refreshingly simple, and it handles both server and client logic without getting confused. It’s just a shame it’s Deno-only (although I completely understand why)
  • nobleach 1y ago
    I had a project slated to use this framework. The pilot went fairly well. Fresh has the right ideas on static vs dynamic islands. In the end, we deployed with Astro - which also has similar ideas. In the end, I just wasn't able to get full buy-in on Deno.
    • coxmi 1y ago
      That’s a shame, I’ve also been through much the same process. Astro is pretty good too, though. I’m not 100% sure on some of the decisions it’s made, and personally don’t enjoy the need for new file formats and domain specific languages, but it does a half decent job of being framework-agnostic despite a few pain points.
  • robertjpayne 1y ago
    I feel like Fresh being Deno only isn't the primary issue. It's based on Preact which is really just a non-starter for so many because it isolates away too much of the react ecosystem instantly.
    • coxmi 1y ago
      I don’t disagree on that front, the React ecosystem is huge, and rebuilding a load of complex components is often beyond the budgets of many greenfield projects. I also don’t believe a React monoculture is good, so a growing Preact or Solid ecosystem would be really positive, alongside growing web/DOM standards to ultimately make these frameworks more of a light wrapper around some trivial updates. React and Next.js, to me, have done the typical architecture astronaut thing, and it feels like they’ve both increased the barrier to entry and just made everything a little more complicated than it really needs to be for much of the web.
• epolanski 1y ago
  I had it uninstalled when they messed with the fetch prototype which resulted in our team wasting days to find the actual reason file uploads above 100kbs failed. Imho next attempts to do too much, moves too fast, every few months the wheel gets reinvented and never perfected.
• pzmarzly 1y ago
  > SvelteKit is a Vercel product While Vercel acqui-hired many developers behind SvelteKit and Nuxt.js, I was under the impression that they weren't interested in running these projects hands-on, or even making them similar to each other. Can anyone correct me here or explain what their long-term game seems to be?
  • Sammi 1y ago
    Rich Harris answered this question on Reddit a year ago: https://www.reddit.com/r/sveltejs/comments/19ac6lp/concern_about_the_future_of_svelte/ https://www.reddit.com/r/sveltejs/comments/19ac6lp/concern_a... Seems Svelte is still mostly managed as an independent open source project.
    • throw-the-towel 1y ago
      Given that Svelte's marketing and docs now treat Svelte itself as a minor implementation detail of SvelteKit, this doesn't exactly inspire confidence.
      • Sammi 1y ago
        That seems to be a strongly held position of Rich himself. He really really wants people to default to ssr with hydration, which they can only deliver with Sveltekit. The new direction they have with a new simpler rpc-like way of loading data that replaces the existing load functions, does seem like they are working in the direction of making Sveltekit simpler to work with. They don't seem like they are trending in a direction of deeper integration with one hosting vendor. Also they've always had one single abstraction for integrating with hosting options, which gives all hosting options a level playing field.
    • xrd 1y ago
      I came here exactly for this. Vercel has long since passed the investment threshold where they are driven by building cool things. Now they are surely driven by project managers managing PKIs. I love Svelte and I'm sure Rich Harris has been in meetings where someone said to him "Sure, I know that's important, but this feature I'm talking about will bump my numbers next quarter..." And, that's the slippery slope.
• kumarvvr 1y ago
  Recently started developing a client side web app using Angular v 20. The app is quite complex, with about 40 components many of them nested, about 7 to 8 "pages", data dashboards, multiple forms, continuously updating data from server, etc. There substantial amount of data flow in the application. So far, the experience has been absolutely wonderful, particularly, given the context of myself as a developer in the whole process, which is, 1. I am a seasoned developer, mainly doing python stuff, back-end servers, desktop applications, data applications, etc. Very little exposure to front-end tech. 2. I keep myself updated with the concepts, patterns & architecture of front-end systems, because I am extremely into design and good UI. 3. I am at a stage where I can do basic web apps with Vue, React, Angular & vanilla HTML and JS. With Angular Signals and concept of Stores, Services and Dependency Injection, I am able to handle data flow very easily, am able to add features to the app in a consistent manner, able to debug and trace errors with relative ease. I have earlier read NextJS docs, Remix Docs and read tutorials about developing react apps using Vite. It has always been a confusing maze of stuff. Perhaps I am getting old (about to touch 40), but I have been programming for about 25 years now and I was able to carve out the architecture I want in an Angular app with ease. Also, this app is going to be a production app, and is critical for my work, so its an impactful decision, which, thankfully, I have been happy and pleasantly surprised with. It could be that I could have chosen React, and end up with the same thing, but, somehow, in the extensive tech stack selection process that I took up before committing to Angular (which involved testing out core mechanisms of the application in React, Vue & Angular), I felt very much at home with Angular way of things.
  • EMM_386 1y ago
    I've worked on many very large Angular applications I've always loved working with it. I have worked with plenty of React but I avoid Next.js like the plague after reading through documentation / examples / blog posts. I was in the trenches pre-ES6 with JavaScript and JS/CSS since the year they came out, so of course I do love KISS-style bare-bones websites when that is the proper tool for the job. But certainly not for anything at scale. Angular, being a framework and not a library, is perfect for those purposes. I prefer that it IS opinionated (no "what router does this project use?"), and I also would not develop anything these days without TypeScript (even small sites). To each their own.
• Byamarro 1y ago
  What I've found is that NuxtJS is miles ahead in DX. In NextJs it feels like their architecture stands in your way while in NuxtJS everything just works.
  • strickjb9 1y ago
    Completely agree. Nuxt is intuitive - convention-over-configuration and auto-imports remove a ton of boilerplate. The key is treating it as an app framework, not a backend solution - within that scope, it handles modern SSR/SPA complexity.
• w3news 1y ago
  Next.js is indeed not very open for feedback. Next.js is also opinionated. So if you are using Next.js, you can use what they have and do it their way. If there is something, just wait... For me, it isn't a framework I want to use in any production environment. Your system is too much depending on something you have no influence on. Like in your own code, it is good to decouple, don't make things depend too much on something, not in your own code, but also on external code like frameworks and libraries. That is why I prefer to build things like I can (kind of) easy drop my dependencies, for what reason, and use something else, or build it in my own codebase. If some framework doesn't allow it, and you have to work it their way, and is the base of everything, that should be a big red flag.
• platelminto 1y ago
  I was about to start a new project with Next.js... is anyone willing to give me some advice? I'm about to start building an e-commerce site (30-50k poster print designs, i.e. no inventory), and was leaning towards a Django backend (because I know it) and... some sort of SSR frontend. I'm not really a frontend guy, but taking this as an opportunity to learn it. This article obviously does not inspire confidence in me choosing Next.js - would someone have any suggestions/pros and cons of what to use? I currently see the options for doing SSR as: - Next.js: well-represented in AI training data (though recent versions had breaking changes? I'm not sure), but annoying to actually use (according to this article/general sentiment I've found online), and pushes you into Vercel? (I barely know what that means) - SvelteKit: best DX and nice to use, but might be less present in AI training data? - Django templates + HTMX: possibly limiting? Less maintainable once you get to a certain size? I'm not sure. - Other options?
  • palmfacehn 1y ago
    Use what you know. Build the backend first. You probably won't know what the frontend requires before this. Once you know what is actually going to be on your site, you can style the output with CSS and add the necessary interactivity with JS. Browser APIs have mostly standardized as compared to the bad old days. Using them directly instead of libraries or frameworks will keep your site lean and fast. All of your CSS, HTML and browser API knowledge will continue to serve you for the years to come. In a few years, people will be arguing about a new magic framework.
  • komali2 1y ago
    In my opinion (9 years FE exp) you should build your ecommerce site in shopify or wordpress + woocommerce or some other off the shelf tool. It will be up before the evening's out and you won't be spending that much extra than you would have anyway, and everything will Just Work (tm) and look pretty good (chuck out 50$ for a nice wordpress theme and you're golden). If you insist on rolling your own, Django + templates should be plenty. Lots of existing code for integrating Stripe or whatever. AI will be fine at it. You could potentially investigate medusajs or prestashop. Here's a list that could be fun to investigate: https://github.com/awesome-selfhosted/awesome-selfhosted?tab=readme-ov-file#e-commerce https://github.com/awesome-selfhosted/awesome-selfhosted?tab... but keyword is fun. You should build it in wordpress because that is a bombproof solution running like half the internet and will save you endless amount of time. If you're doing this as an exercise to learn a new tool, leave the AI to the side as you're robbing yourself an opportunity to delve into docs and gain more domain knowledge. And absolutely do not touch nextjs with a 10 foot pole, it's an absurdly overwrought tool. The only people that should learn nextjs are people working at dev houses that churn out a shitload of full stack apps for clients that have the budget to shell out for vercel's hosting costs. And even then imo they should just be using django + react + vite + tanstack MAYBE. HTMX is cool but I'm not sure the point, again if for fun why not, but I would ask yourself: you get your site up and running and you spend the next year scrambling around putting things in boxes and printing shipping labels, and then in 2026 Thanksgiving right before the holiday rush something breaks in your app and you want to fix it but HTMX/nextjs/whatever have gone through 2 breaking change upgrades and so have 4 different libraries they rely on and actually the most up to date version of two libraries you rely on are not interoperable right now because they depend on different node versions or some other bullshit, and now what do you do? Just use wordpress.
• ddanieltan 1y ago
  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?
  • OtherShrezzing 1y ago
    Each paragraph/element has a unique ID, starting at 0, incrementing by 1. You originally land at the page https://blog.meca.sh/3lxoty3shjc2z 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 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 paragraph, start from the 25th character. - End the highlight on the 65th element. Inside of that element, end at the 174th character. - Scroll the user to element #64 on page load. They've then got some code on the page to add a highlighted span starting and ending at those points. If the site maintainer is here: For me, the links are currently broken, as they should link to https://blog.meca.sh/3lxoty3shjc2z/l-quote/64_25-65_174#64 https://blog.meca.sh/3lxoty3shjc2z/l-quote/64_25-65_174#64, but currently link to https://blog.meca.sh/3lxoty3shjc2z/l-quote/64_25-65_174#64_25 https://blog.meca.sh/3lxoty3shjc2z/l-quote/64_25-65_174#64_2..., and `64_25` isn't a valid id on page-load.
    • dminik 1y ago
      The blog itself is build on leaflet.pub. I'll take a look and file an issue.
    • dminik 1y ago
      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 https://github.com/hyperlink-academy/leaflet/issues/196
• divan 1y ago
  For the past 5 years, my main stack is Flutter+gRPC+Go, and I read articles like this in horror and satisfaction simultaneously. For many years I'm advocating the community to be very open about the history of web stack (and JS in particular) and be honest about it's suitability for the modern software development. The level of accidental complexity in this stack is insane and people seem to embrace it add more and more layers of it. Personally, I try to avoid using it as much as possible. And it works beautifully. Of course, tradeoffs are everywhere, and the sheer scale of the web development community has its own benefits. For example I miss the wide choice of alternative design systems in Flutter (compared to web), but hey, flutter now decoupling it's core from design systems in 2026. But the net effect of not using fundamentally flawed tools for your products is huge.
  • kumarvvr 1y ago
    > my main stack is Flutter+gRPC+Go For web apps? How is the performance? How is the developer experience?
    • divan 1y ago
      Yes, web build comes as a nice bonus, and I've been using it from the early days of Flutter web renderer support. Now I'm using it for client-side web apps exclusively. Developer experience is... well, I usually develop app while running it locally as a MacOS desktop app build. Just much easier to use with hot-reload and Flutter dev tools. Often using DevicePreview [1] wrapper to check against different sizes, dark/light mode, font scaling etc. Unless I'm working on something platform-dependent (like push notifications or a QR code scanner that uses camera/ML frameworks from OS), I don't even test it on mobile devices or web - I know that it will look pixel-perfect. There are optimization caveats like "emojis are not included in the web build by default to decrease the size", but otherwise web build looks the same way pixel-to-pixel as MacOS or mobile view. Test I run with maestro in iOS simulator. Centering widgets ("<divs>") is never a problem, haha. Having a properly designed layout system is a no-brainer and thousands of times better experience than that pile of hacks on top of hacks called CSS. Still, my main issue with the current Flutter design is the tight coupling of two main design systems (Material Design and Cupertino) and the core, and the lack of a wide choice of alternative design systems. Just to make it clear - it's extremely easy to create your own widgets/themes/look-and-feel in Flutter app. But having a well-thought-out design system is a different beast. Luckily, decoupling is on the way [2] and I hope it will lead to a boom of nice design systems implementations. Also, because Flutter originally was targeting mobile development, and expanded to desktop/web almost accidentally, the majority of the widgets are optimized for mobile UI. For example, if you want a date input field that feels native to a desktop user, with masking and yet a calendar picker – good luck finding one. And as I create desktop/mobile apps 50/50, I settled for now with forui [3] design system, heavily inspired by shadcn. Performance has been the last of my concerns with Flutter, because the engine was originally heavily optimized to hit <15ms frame rendering and modern web renderer is using Wasm and shader precomilation and some dark magic I don't even want to know about. And to be honest, my own experience with "web apps" is so bad, that I don't think any non-native-to-browser rendering pipeline can make it worse. Like, having UI glitches and unresponsive components, bad state management, need to refresh the page (which is essentially a "restart an app" in web), mess with forms/fields it's just such a normal experience in web. I don't have any of that with Flutter web apps. They might feel a little bit "non-native" to HTML-based web apps, but I never heard real users caring about that. [1] https://pub.dev/packages/device_preview https://pub.dev/packages/device_preview [2] https://docs.google.com/document/d/189AbzVGpxhQczTcdfJd13o_EL36t-M5jOEt1hgBIh7w/edit?pli=1&tab=t.0 https://docs.google.com/document/d/189AbzVGpxhQczTcdfJd13o_E... [3] https://forui.dev https://forui.dev
• YuukiRey 1y ago
  I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else. In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts. Next.js is easily the worst technology I've ever used.
  • christophilus 1y ago
    Second worst for me. I’ve used Sharepoint.
    • mcny 1y ago
      Third worst if you have used Lotus Notes mail. I still don't understand how an email and calendar client can slow down a computer like that (going by memory, the last time I used it was at work in 2013 so pre-SSD days).
      • marcosdumay 1y ago
        Well... I don't know exactly what the OP meant by "technology", but Notes at least wasn't supposed to be a development platform. It surely was a development platform, but wasn't supposed to be one.
        • YuukiRey 1y ago
          I should have been more specific here indeed. I meant more library or framework, not technology in the broader sense. My apologies.
      • codegeek 1y ago
        You just reminded me of the nightmare Lotus Notes was.
      • nailer 1y ago
        Everyone at IBM when I worked where used Fetchnotes (internal tool that leaked onto the internet that wraps Lotus notes .so file and allows you to use normal email / contact / calendaring programs and formats).
• punkbit 1y ago
  A lot of companies have Nextjs as a requirement, you can see it in the job posts. It's almost like React = Nextjs, where they don't even mention React. There are developers out there who are highly invested in Vercel's business. Ultimately, the dev teams are responsible for making these decisions. I've encountered issues based on Nextjs in a few projects where the best approach was to eliminate it. The outcome was nicer and higher development satisfaction. If you dare to say that you had to get rid of Nextjs from a particular project, during a job interview, you're done!
  • christophilus 1y ago
    It would be a point in your favor if I was interviewing you. In fact, telling that anecdote may be a good way to weed out koolaid-drinking companies.
  • abustamam 1y ago
    I think it's actually a good conversation starter. "I had to get rid of [popular framework/tool]." Possible follow up questions: - what led your team to want to remove it? - what was involved in removing it? - what did you replace it with? - what makes the new thing better than the old thing? - how did you evaluate that spending X days/weeks/months to remove it was worth the time that could have been spent on developing features? I think all frameworks and tools have their time and place, and knowing when and how to use them is important. If a company can't understand this then I wouldn't want to work for them.
  • adamddev1 1y ago
    I talked to a computer science student who told me that React is old, no one is using that anymore. He said now NextJS is the thing to use. No matter how hard I tried to explain to him that NextJS is a framework that uses React, he would not listen or understand. Scary times ahead.
    • avisser 1y ago
      NextJS is web-scale.
• ozozozd 1y ago
  Similar experience here. Next.js is 8 years old and still under-documented, and you will still get lost if you veer off the beaten path - of which sometimes there is none. Frankly, I was mad at myself for not recognizing the hubris and their ignorance of web dev history when I noticed that they brought back directory based path convention from the 90s. That should’ve been the red flag that stopped me but I fell for Vercel’s fonts and web design. Investing in an implicit and inflexible routing pattern such directory based routing that was used when we didn’t have nice things is like being a rich hippie. Oh it doesn’t stop there. Isn’t it cool that you get to (jk, you HAVE TO) name your files like ‘[path-that-takes-arg].tsx’? You may think that I used brackets as a placeholder signifier, but I didn’t! Brackets are part of the filename and they indicate that this route takes params. Look, we all tried and maybe had a little too much fun inventing and sometimes reinventing clever patterns we shouldn’t have, but few of us doubled down and just ran with it for so long. Luckily, you can get around the pattern above pretty easily by just using the one route as a router file and adding your own indirection. Obviously you miss out a bit on tree-shaking and probably some other optimizations they designed to rely on their implicit conventions but your codebase remains greppable.
• ramon156 1y ago
  Next js is magic just like laravel, it's nice when you expect magic and not nice when you like to understand what's going on.
  • dominicrose 1y ago
    Laravel is easy to learn and use and get started with. No compiler. No javascript on the back-end. Eloquent is a good ORM. There's not much magic, no async/await. Or course you should not use Livewire. It's really terrible!
    • 0xblinq 1y ago
      You must be building extremely simple/minimal frontends with near to zero interactivity requirements. Otherwise "no javascript" and "no livewire" just doesn't work.
• quadhome 1y ago
  AsyncLocalStorage.enterWith is the wrong method; .enterWith changes the logger for across the *synchronous* execution. This doesn't matter if there's only one request happening at time-- like when you're testing locally. But that's why it didn't work on the actual project. Use .run. return LoggerStorage.run(requestLogger(), () => { logger()?.debug({ url: request.url }, "Started processing request!"); return NextResponse.next(); });
  • dminik 1y ago
    Nope, this doesn't work either.
  • deleted 1y ago
    [deleted]
  • huksley 1y ago
    I have enterWith working perfectly with async/sync flow - all operations between request and response are logged with request id transparently. I am using custom server for both standalone build & dev server, nextjs 14, node 22.
• komali2 1y ago
  I feel like I'm being gaslit every time nextjs is discussed. I picked it up and learned it for a couple different projects because clients heard about it and wanted it. I kept finding shit like this in the OP post, making issues, asking around about it, and being told by nextjs experts that I was Doing Everything Wrong. Fine, I'll deploy on vercel, but wait this client wants to try cloudflare edge because he knows the ceo and wants to pitch for his investment firm having better access or whatever tf, so I need to get it running on that, so now I can't use some xyz version of some library, and I have to use some bleeding edge version of nextjs and... etc. Every day that went by I wondered if I was going insane for thinking we should just go back to building apps in straight vanilla javascript. Or like, just react SPAs pointing at fastapi apps deployed on s3, which has never failed me.
• rvz 1y ago
  There you go. We are now past the honeymoon period of yet another web framework. This one has been the most over-hyped, vendor locked-in and completely vulnerability ridden web framework I have ever seen.
• xkcd1963 1y ago
  The slow response time on hithub is most likely due to layoffs
• wg0 1y ago
  Genuine question - What are the alternatives? React Router + Express? Or something else?
  • cluckindan 1y ago
    React Router v7 is actually awesome and can do SSR if you need it.
  • nobleach 1y ago
    We do React Router 7 (previously Remix) with Fastify for a couple of our apps. Both external and internal. I'm really happy with the dev experience. We also have plenty of NextJS floating around here too. Most teams use it as a "better Create React App". There's little use of any of its features. I'm the only one that's used any server-side stuff. For my team, React Router 7 just gets out of the way. If you use it in framework mode (SSR) you will have loaders and actions, which are things that run on your server. I find it SO much less convoluted. The logger example from the article above is childs play in React Router. Either import your logger and run it in your loader. (You may want to add .server.ts to make it explicitly ONLY server) or inject the logger via context.
  • chrisweekly 1y ago
    React Router is great. Express is ok for its server (hono or fastify have advantages).
  • gitaarik 1y ago
    Sveltekit
• yasserf 1y ago
  I agree it’s pretty frustrating, but I do really like the SSR capabilities I’m divide my frontend and backend via pikku, that way I can continue using normal server side functions but optionally spin up a seperate api service if needed. Haven’t really tested it on vercel as much, but it ignores middleware on the nextJS side unless it’s for frontend code. https://pikku.dev/docs/runtimes/nextjs-app https://pikku.dev/docs/runtimes/nextjs-app Disclaimer: I’m the pikku core developer
• vincirufus 1y ago
  may the title of this should say Next.js middleware /logging is infuriating
• nesarkvechnep 1y ago
  JS devs having Stockholm syndrome is no news.
• francisduvivier 1y ago
  I recently migrated 2 projects away from Next.js to Vite. It was a lot of work, Next.JS handles quite a lot of stuff: translations, authentication, bundling, css stuff, caching... But it was very much worth it for lowering my daily infuration. I don't think I'll be using NextJS again if I don't have to.
  • haltcase 1y ago
    In what way does Next.js handle translations or authentication? It doesn't prescribe or even do much to simplify either of those things.
    • francisduvivier 1y ago
      Well you have next-i18next and NextAuth.js, those integrations with Next.js help for getting something running quickly.
• cpcallen 1y ago
  You know what else is infuriating? Pages that won't load (at all—just show a blank page, or in this case a too many redirects error—if you do not have cookies and local storage enabled.
  • jpereira 1y ago
    Agh, sorry about this! I'm one of the people building leaflet.pub, which this blog is running on. Just pushed a fix for this (ironically on nextjs/vercel). The redirect loop is to handle sharing auth between our "main" domain, and people's various custom subdomains. Auth, via the ATProtocol, is used for things like subscribing and commenting!
• 8cvor6j844qw_d6 1y ago
  I'm involved in starting up a project with Next.js. Can experienced devs let me know your opinion or any potential pitfalls? Long story short it's a proof of concept demo/exploratory project. Currently, using Next.js app router, multi-root routes for stuff like (marketing), (app), (login), etc. Db is Neon for the branching, will probably include Vercel AI SDK for AI stuff since its likely I'll be asked to include some AI functionality. The only worry is I'm unsure with how this serverless layer/backend? interact with user authentication / authorization when used with the BetterAuth. Currently hosting on Vercel, I feel like Next.js is married with Vercel for hosting. Although maybe because I'm unfamiliar with it, since Next.js made it quite simple and straightforward to do host quick proof-of-concepts on Vercel.
  • masto 1y ago
    I don’t know if this counts as experienced, but I’ve spent about a year exploring Next.js, the last 6 months of which transitioning from exploring to building a serious project. I understand the author’s frustrations. I have had similar ones when it comes to middleware and other parts of Next.js. I’ve also had those kinds of frustrations with every piece of software and framework I’ve ever used. A lot of times they stem from trying to shove a square peg into a round hole, and it only gets better when I finally develop the right mental model for how the thing works. As a web developer going back to CGI scripts in the 90s, all this server and client side rendering, edge runtimes, etc., is quite foreign. But when I find myself screaming “why won’t it let me do this?”, the answer is often “because it doesn’t make sense to do that”. Auth is one of the places where that happened, and going through the process of “but why can’t I look the user up in my database from middleware” was a big part of wrapping my head around the parts of Next.js that I had been ignoring. As far as being married to Vercel for hosting, not at all, if you don’t choose to use all their stuff. The sample Docker build they have works just fine to deploy anywhere, in my experience. Maybe I’m speaking mostly out of ignorance of not having tried dozens of other modern TS web frameworks (I was on a big tech island for a decade and not in touch with what the cool kids were up to), but I rather like Next.js. I may feel differently when I want to start adding native mobile apps and realize I was lulled into omitting a clean API layer, but for now, adding features has been pretty smooth.
• paradite 1y ago
  I've came to the pain conclusion on Next.js: It's a bad framework for building full stack apps, but it's better than anything else. https://x.com/paradite_/status/1941016421934551477 https://x.com/paradite_/status/1941016421934551477
• fatchan 1y ago
  I always use a custom server (even express will work) with next.js, because I found the middleware and edge stuff a load of overcomplicated BS. Client side works like regular react app, SSR for any pages where the initial props are just populated from the server site is easily controlled, and the whole system is simple to reason about. There are other frameworks out there to do this now, but I'm comfortable with this and it just works, so no reason to change.
• lagrange77 1y ago
  I can only recommend vike.dev .
  • nickdichev 1y ago
    I wish more people knew about and were talking about vike, really powerful tool
• matt-p 1y ago
  Do you know what, it uses to be OK in the early days with pages and not too much magic/abstraction. These days vite is far far nicer.
• graphememes 1y ago
  I think Edge infra and SSR irks me the most out of everything.
• gg2222 1y ago
  For people wanting to try something else, I recommend SolidJS and SolidStart. Personally I never tried Next.js exactly because it feels like too many decisions are being made for me without having any choice. And I don't trust frameworks like that. Depending on the project, just write an SPA with an API server, or if it is a static website just prerender it and serve on Cloudflare. I don't get the appeal of all the complexity. If you need SSR for SEO, then SolidStart is a nice and simple solution.
• fkarg 1y ago
  we started a purely-frontend project with nextjs but moved to react-router pretty soon. Sure, it can be convenient (when it works), but you can't really see or understand how or how to control it, and black magic breaking is the least of what you want. Much happier now.
• rossant 1y ago
  There are so many frameworks in this fast-moving space that I need mnemonics to keep track of which ones are well-regarded and which aren’t. Looks like this one is easy. Next.js? Next.
• dzonga 1y ago
  remember a while back when they was "rails is a ghetto" piece. now that rather seems sane compared to next.js stuff n other javascript things. if you gotta use typescript while not use java and at least benefit from the ecosystem of the jvm ? for me I will stick with Rails - that's what I know
• celicoo 1y ago
  Reading through all these comments gives me hope. Finally people are speaking up about what we have all been experiencing in isolation — the gradual enshittification of Vercel/Next.js in service of Vercel's business model. The middleware issues the OP describes are not bugs, they are symptoms. When you can't get basic logging to work, when you can't use WebSockets, when you are forced to deploy on edge runtimes that don't support Node.js APIs — these are all deliberate choices to push you toward Vercel's platform. Guillermo and his team have prioritized their cap table over the open web. This is why I started https://github.com/openuiai/next.js https://github.com/openuiai/next.js last month. The web is humanity's greatest collaborative achievement. We are building toward a global, decentralized network that should enable unrestricted computation and storage for everyone. And for that to actually happen, we need frameworks with the power and flexibility that Next.js used to have. But instead we are all watching Vercel carve it up to lock developers into their platform Next.js used to be great. Now it's a trojan horse for vendor lock-in. The fact that so many developers are comparing it to SharePoint and Lotus Notes should be a wake-up call. To everyone frustrated: you are not wrong. The framework is ACTIVELY working against you unless you are on Vercel. I'm working on OpenNext.js every single day — still climbing the learning curve of the massive spaghetti codebase, but fully committed. We are already running OpenUI on a fork with full Node.js middleware support and native WebSockets. These will merge into OpenNext.js once I have properly cleaned out the cruft (their CI/CD alone has cost me $400 just figuring out how to untangle it). But I'm taking the time to do this right. Guillermo: Vercel/Next.js shouldn't dictate where we can deploy. It should respect the open nature of the web. You know this, but you chose the money instead.
  • ale 1y ago
    To be fair Next.js is just following the natural progression of what their product always has been: holding devs' hands in all things deployment at the expense of vendor lock-in. Being aware of Vercel's limitations is not about the open web, it just means you should be setting up servers yourself at this point.
    • dizlexic 1y ago
      This I was talking to a fellow dev at the company I work at and he was extolling the virtues of one-click nextjs deployments. As the conversation progressed it turned out he'd never actually had to set up or manage his own servers and felt that it was a waste of time for him to learn. It hurt my soul. I am considering linking this article, but i feel it may come across as aggressive.
• Lucasoato 1y ago
  > 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 https://nextjs.org/docs/app/guides/open-telemetry [2]: https://grafana.com/ https://grafana.com/
  • hu3 1y ago
    OT might be too heavy of a hammer depending on what OP needs.
  • keeganpoppen 1y ago
    this is a fantastic, state of the art way of “now we have two problems”, i can say unequivocally from my own experience.
• 867567838694 1y ago
  Next.js is a cancer. I wish more people would see it sooner before Vercel completely destroys ReactJS.
  • timcobb 1y ago
    I thought NodeJS itself was the cancer*. Hard to keep up with all the cancers I guess ;) * https://news.ycombinator.com/item?id=3062271 https://news.ycombinator.com/item?id=3062271
    • moritzwarhier 1y ago
      It's not listed under N https://web.archive.org/web/20190612110518/http://kill-or-cure.herokuapp.com/a-z/n https://web.archive.org/web/20190612110518/http://kill-or-cu...
• QuadrupleA 1y ago
  Every time I hear about modern JS/TS frameworks, I'm amazed at the unnecessary complexity. In python / bottle.py this would just be a print statement to stderr in before_request() or before_response(). One additional LOC.
• Havoc 1y ago
  Honestly I feel like this about the entire node/js ecosystem. Seems pretty cursed from top to bottom to me. And each attempt to un-curse it just adds more frameworks and layers and abstraction and new paradigms
• _pdp_ 1y ago
  The app router is certainly challenging. This is why we stick to the page router and it works really well. There are some cases where the app router comes handy though. Honestly, nextjs is not that bad and I would go as far as saying that it is perhaps the best web framework I have ever experienced but it does come with its own problems which might be overwhelming for beginners.
• maelito 1y ago
  I have no major problem with Next running on Dokploy. I don't use lots of its functionnalities, just some SPA routes and dôme RSC routes. That's fine. It works fine.
• Ambix 1y ago
  Hehe, great post. Just use Hono or Hono X. It's so easier to reason about what's going on for me, mostly backend guy.
• kremi 1y ago
  I think “middleware” is a bit of a misnomer in Next.js. It’s really an edge function that runs before your request hits the app -- quick header checks, routing, and other lightweight guards. It runs on the edge runtime, not on the app server. The post's author seems to conflate the edge runtime with the server runtime. They’re separate environments with different constraints and trade-offs. I struggled with Next.js at first for the same reason: you have to know what runs where (edge, server, client). Because it’s all JavaScript, the boundaries can blur. So having a clear mental model matters. But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer.
  • kremi 1y ago
    To people who downvote my comment (and there are many): please elaborate. I like to learn and improve. A lot of comments here are just baseless negative comments. Please let’s have a real discussion.
  • fabian2k 1y ago
    I wouldn't consider this a misnomer, but a really big misuse of the term. Middleware has a long established definition in web applications, so they really should not use the term if they mean something entirely different.
  • yladiz 1y ago
    > But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer. The biggest issue is that the complexity is self-inflicted. The term middleware has a pretty well understood meaning if you've worked with basically any other framework in any language: it's a function or list of functions that are called at runtime before the request handler, and it is assumed those functions run in the same process. The fact that Next.js puts it on the edge and only allows one is breaking that assumption, and further, most applications do not need the additional complexity. To go back to your toolbox analogy, more tools mean more complexity (and money), so you wouldn't get a new tool simply because you might need it, you get it because you do need it, and the same applies to edge functionality. If Next.js wants to allow you to run code on the edge before your app is called, that's fine, but it should be opt-in, so you don't need to worry about it when you don't need it, and it shouldn't be called "middleware".
• thecopy 1y ago
  The two best days of a NextJs developer life if the day he starts his project and the day he migrates it to React Router.
• dakiol 1y ago
  My conclusion is to use nextjs only for very simple projects. Problem is that simple projects grow and become important ones. So, just dont use nextjs at all.
• rco8786 1y ago
  the App router move really killed it. The Pages router made so much sense, and was so intuitive. I have no idea why the team thought it was a good idea to completely abandon the fundamental innovation that made Next good in the first place.
• tjpnz 1y ago
  Anything related to observability with Next.js is guaranteed to be a fucking nightmare. At work we'll typically implement a metrics endpoint for Prometheus - really trivial for just about every API or fullstack framework under the sun, except Next.js. I think I gave up at the point where the suggested method was using a custom server (negating some of Next.js's supposed benefits), or adopting Vercel's proprietary metrics service which wouldn't have helped us anyway. Terrible, terrible stuff - would never touch again.
• kundi 1y ago
  I’ve always felt that Vercel’s way has had fundamental flaws at its core “philosophy” and their approach to creating shiny objects from outside that stink from inside. Unfortunately incompetence of developers to see beyond has brought the web to the point that every React developer has dealt with Nextjs at some point. What are the alternatives beyond Vite and Remix?
  • keysdev 1y ago
    Solid and sveltekit
  • blitz_skull 1y ago
    Rails and Laravel are still big players in the space that have only gotten better with time.
  • fourside 1y ago
    > What are the alternatives beyond Vite and Remix? On more than one occasion I’ve seen someone refer to Vite as an alternative to Next.js. Isn’t Vite a bundler and Next and Remix frameworks? How is Vite an alternative to these?
• recroad 1y ago
  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 execution order or something. If you picked NextJS without knowing how it structures its middleware, the vendor lock-in to Vercel, its SSR strategy, its hydration schemes etc. that's on you. I, and many others, have had a lot of success with NextJS increasing delivery speed and ultimately, customer value. Two years ago I moved off of the React ecosystem to Elixir/Phoenix/LiveView, and it's been great. But that's had its own challenges stemming from the design decisions its creators have made. You're always going to be running into things that you don't like, and I feel NextJS has just become an easy target for people who are looking to vent.
  • fabian2k 1y ago
    NextJS has been pushed aggressively by many people and often recommended as a kind of default for React applications. Which I consider a bad idea, in a large part because NextJS contains a lot of complexity that most applications don't need.
    • agos 1y ago
      the React documentation is infamously responsible of recommending Next as a "default". After a lot of backlash it got somewhat toned down, but it's still the first thing they suggest[1] for creating a new app [1] https://react.dev/learn/creating-a-react-app https://react.dev/learn/creating-a-react-app
  • dminik 1y ago
    I'm sorry, but please do read the post. The middleware section is a setup. The real trouble starts when ejecting from Next and using a custom server still doesn't allow you to do anything because Next is a black box. I would have been happy with installing fastify and just using it's middleware, but even that doesn't work.
  • 1y ago
• always_imposter 1y ago
  [dead]
• justinator 1y ago
  The only thing worse than Next.js is trying to be a subcontractor for a startup that’s building their MVP in Next.js. I will be taking no further questions.
• pavel_lishin 1y ago
  > Let's not skip over the fact that you can't have multiple middlewares or chain them either. Surely this can't be right? https://nextjs.org/docs/messages/nested-middleware https://nextjs.org/docs/messages/nested-middleware > If you have more than one Middleware, you should combine them into a single file and model their execution depending on the incoming request. By Talos, this can't be happening.
  • zelphirkalt 1y ago
    Am I reading this correctly? They are advocating giving up on structuring code in separate files? Is that a scoping problem that NextJS has, which makes it difficult to use multiple files? Seems like a rather ridiculous statement of a framework to make.
    • wetoastfood 1y ago
      It's the single file that is used to define the middleware function that runs. You can import whatever you want into it and decide how "you should combine [your middleware] into a single file."
      • hn_acc_2 1y ago
        I prefer this to having app.use / router.use scattered anywhere throughout the app init (i.e. Express)
      • qbane 1y ago
        As a JavaScript developer, combining/consolidating middlewares manually just defeats the design of middleware. I would rather call it a callback function.
  • digianarchist 1y ago
    I can’t help but feel some of these decisions are made because it’s what is best for Vercel and not what’s best for the framework.
• huflungdung 1y ago
  I use svelte and it is alright.
• neya 1y ago
  As an experienced dev who has explored almost all possible JS options - including but not limited to - React, Angular, etc. and settled for Phoenix/Elixir, I can tell you nothing comes close to the peace of mind you get from just opening up a text editor, naming a module whatever the fuck you like, writing functions, piping the results, validating with `with..do..else` and the best part - catching errors at compile time. Everything just works - even after 5 years. Whereas, with JS, something keeps getting burned down every 6 months or less even if you didn't touch the code at all. Seriously, give Elixir a shot.
• deleted 1y ago
  [deleted]
• blitz_skull 1y ago
  As someone who went from MEAN -> Java (Spring) -> MERN - > Rails I cannot comprehend how many times the JS community has reinvented the wheel. These days I do my best to stay in Rails land, far away from Next.js. It just looks like a cluster.
• mkl95 1y ago
  Most of the modern frontend ecosystem is infuriating. The early React + Typescript era was mildly upsetting but bearable, and it hinted at a relatively nice future if abstractions improved. Then Vercel et al threw that slow progress into an overpriced garbage can.
• dev_l1x_be 1y ago
  > In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. This true to most software projects that are used more than one set of people. Joe Armstrong proposed a solution that we should opensource functions only and people could assemble everything else using these opensource functions. I start to think that he might be right and instead using "frameworks" we should use these set of functions instead.
  • detectivestory 1y ago
    I did find it quite funny that he makes this claim, but then writes an entire blog piece about how nextjs is no good because of one particular thing it doesn't do to his liking!
  • snisarenko 1y ago
    Spot on. This is the core problem. The ammount of functionality is not the problem. The problem is that the functionality is not a set of composable functions and classes. It's an inversion of control "framworky" blackbox, where behavior is hard to reason about.
  • datadrivenangel 1y ago
    The Unix philosophy?
    • DonHopkins 1y ago
      Every DOM element is a file. And you can use ioctl from JavaScript for anything that doesn't fit neatly into a one dimensional stream of bytes.
  • platevoltage 1y ago
    How I feel any time I see a simple static website or someone's developer portfolio with a vercel URL. Like, did you really need this?
• dizlexic 1y ago
  I think I’m just paranoid, but nextjs has always felt like a trap for the boot camp participant.
• dncornholio 1y ago
  Just run production with the right flags so it'll log? Or put the app into local and try to replicate? The tone of voice is also completely off. It seems Middleware in Next.js is not what Middleware is in framework X. This whole thread looks like a complete collection of misunderstandings of Next.js.
• wateralien 1y ago
  I've just convinced a large, but not global, client to move from their antiquated system to Next.js. They definitely wouldn't want to run on Vercel in prod since they're obsessed with costs.... and now I'm really concerned since this and some other "next.js in production nightmares" posts have dropped. I've only ever run smaller stuff on Vercel. Super concerned.
  • Kye 1y ago
    Any sufficiently advanced development ecosystem will be full of issues and people ready to tell you about them. Whatever the flaws, it's probably still an improvement over what it replaced in your situation.
    • wateralien 1y ago
      Fair enough I guess.
  • abxyz 1y ago
    What’s the rationale behind NextJS for this client? If you’re not using Vercel, NextJS doesn’t make much sense. Something like Astro is likely to be a much better fit.
• Evanmo666 1y ago
  100% agree.
• Kuyawa 1y ago
  Node/express/postgresql will never disappoint you
• codazoda 1y ago
  I think Next.js has its place in enterprise software. For the rest of us I think it's time to simplify. I like to do that to the point of absurdity. Why I'm writing pure HTML and CSS in 2025: https://joeldare.com/why-im-writing-pure-html-and-css-in-2025 https://joeldare.com/why-im-writing-pure-html-and-css-in-202...
• chasd00 1y ago
  Reading the comments here is pretty funny, this time last year NextJS was the greatest thing ever.
  • rubenvanwyk 1y ago
    Reality is catching up.
• butlike 1y ago
  > Scientists discover a new super massive black hole at https://github.com/vercel/next.js/issues https://github.com/vercel/next.js/issues got me good
  • nurettin 1y ago
    I loved it!
• skeptrune 1y ago
  I felt seen after reading this post. NextJS was really good somewhere around v11 when it was first becoming stable and create-react-app was unusable. It's been rapidly enshittified since then.
• deleted 1y ago
  [deleted]
• brandly 1y ago
  He made a whole new blog to complain about Next.js and built the blog with Next.js
  • stronglikedan 1y ago
    Sounds like he writes from experience.
• tyteen4a03 1y ago
  Does anybody have Vercel's mailing address? I would like to send them a "Have a good day at school!" card for this issue, which will be old enough to attend elementary school next year: https://github.com/vercel/next.js/issues/10084 https://github.com/vercel/next.js/issues/10084
  • pas 1y ago
    Main address (if a company registered address): 440 N Barranca Ave #4133, Covina, CA 91723 from https://vercel.com/legal/dpa https://vercel.com/legal/dpa
• notyouraibot 1y ago
  NextJS as a framework is pretty good, it has gone downhill since the whole RSC shift sure but its still pretty good for most use cases. The problem however is Vercel and how closely its tied to Vercel. I recently developed a small internal application in NextJS and we are using Azure PostgreSQL, we are on the Pro Plan from Vercel (honestly even that's an overkill, our use case would be satisfied easily on the free plan; which is very very generous) but one problem I faced is a NextJS App hosted on Vercel, it will never have a static fixed IP, so we couldn't directly access our database unless ofc we opened it to the entire world, which is never an option. This is so dumb honestly, the audacity to call it a full stack framework is stunning.
• andix 1y ago
  Next.js turned out to be worse than PHP.
  • throw_m239339 1y ago
    Next.js turned out to be worse than JEE, which is ironic to say the least. People moved to Node.js at first place because the Java ecosystem was "too bloated". Fast forward 15 years later, the Node.js community has adopted its own flavor of JEE. And rince and repeat, new developers will deem Next.js too bloated therefore they are going to go with another platform that doesn't have that stigma...
• Demiurge 1y ago
  Maybe this is a good place to ask... but I was actually considering Next.js as a replacement for Gatsby.js project that is a few years old, but is growing at a steady pace. Given all the negative sentiments, what are better alternatives? I don't even use any SSR, or GraphQL capabilities. The main thing I liked about gatsby vs previous "bring your oown library(router)" are: very little configuring, nice dev server, easy to use plugins. It just solved many of the boilerplate tasks for me, and let me get on with react.js components, hooks, etc. I use Django backend for API, and static hosting for the frontend. Potential alternatives I've found: * astro * remix * back to react-router... and there were multiple back when I used it! :( Update: after some research, I really Tanstack router approach: https://tanstack.com/start/latest https://tanstack.com/start/latest
  • mpeg 1y ago
    FYI remix doesn't really exist anymore, it was folded into react-router a while back. Astro I've found to be pretty solid for prototyping, I like that it gives you control over the rendering of client side code islands and that it works with multiple rendering libraries. I don't love some of the direction they've taken lately though, and I worry that it will become bloated with things like astro db
  • hungryhobbit 1y ago
    Say anything negative you could possibly say about Next ... and it will apply a thousandfold to Gatsby. Likewise React Router is ... the example I use when I want to tell someone about a terribly engineered library. As you said, there are multiple React Routers, because the developer is completely incompetent, and has no idea what he is doing. As a result, he changes the entire library in massive, backwards-incompatible ways ... EVERY. NEW. VERSION. Astro and Remix are viable options, but there's a reason why Next (despite it's flaws) remains dominant over them.
    • jakubmazanec 1y ago
      React Router v4 was released in was released in March 2017 (more than 8 years ago!). v5 was released in May 2019 with no API changes. v6 was released in November 2021 with a new API based on React hooks (this API was much better than the previous). v7 was released in November 2024 with the "Remix" APIs (most importantly the "framework mode"). So, the gaps are 4 years and 3 years - that's doesn't seem that crazy. I personally updated Remix v2 project to React Router v7 and because I used various flags to prepare for the upgrade, it was done without any issue and fairly quickly. > entire library in massive, backwards-incompatible ways ... EVERY. NEW. VERSION So a new major version has some breaking changes? Why is that surprising?
• jhaile 1y ago
  Given all of the NextJS hate on here, I feel like I'll get downvoted for saying this...but we run Next.JS, don't host on Vercel - and really don't have many problems at all. That being said, our app is largely built like a standard React app, we aren't using much server-side-rendering, and we use TanStack Query for loading most data. So, the main value of Next.JS is mostly just the routing and project organization.
  • abustamam 1y ago
    Out of curiosity, have you tried out Tanstack Start? It appears to be a framework similar to next and remix/react router. I've loved all the Tanstack libraries so I'm looking for an excuse to use Start lol.
• samiv 1y ago
  I've lost count how many times I've had to struggle to enable a simple logging. Just to make single "log("hello") appear anywhere, in a file, in a console, as smoke puffs in the sky. Infuriating, frustrating, agitating AF. Turning off logging in a production system is brain damaged move because inevitably production is when you need it the most.
• joshcsimmons 1y ago
  Seems like this is the natural evolution of web fullstack frameworks. I felt the same way about Rails when using it. You either die the hero or live long enough to become the villain! Still love Next but it's because I drank the Kool aid early on. Would be intimidated to learn it anew in current state
• jakubmazanec 1y ago
  As others have noted, if you need a React framework, React Router v7 (in framework mode) is much better than Next.js. I would argue it's a great framework. No over-abstractions, just React on top of standard web technologies. Don't be scared by the complaints about previous breaking changes (which BTW are inevitable when we still haven't figured out the best approaches to the server/client app architecture) - React Router's current strategy using various flags [1] allows you to prepare for breaking changes well in advance. [1] https://reactrouter.com/community/api-development-strategy https://reactrouter.com/community/api-development-strategy
• mfrye0 1y ago
  Adding on to the other comments here about Next.js vs Remix.js. We had to choose a framework for our new app last year and were researching the current state of things. Next.js was / is by far the most popular, but also had some of the worst feedback and caution to stay away. Remix isn't perfect, but I appreciate less abstractions and working with simple request / response structures. Also, a warning for those hiring for frontend / fullstack roles: Over the years when hiring for roles for X frontend framework, we would constantly find "experts" in framework X that would really impress us. Whether it was React, Angular, Vue, Remix, etc. Then after moving forward, we found they didn't know core JS fundamentals and were basically useless beyond the framework.
• throwmeaway222 1y ago
  just log your rest services only, not your view. nextjs is a view. it's a half on the server, half not on the server thingy. it would never be consistent anyway. makes more sense to go full CRA though. it's just a view
• deleted 1y ago
  [deleted]
• skeezyboy 1y ago
  a lot of this BS is avoided when you code native you know.... was the sole benefit to web (not having to distribute new binaries) really worth it?
• asa400 1y ago
  Folks will deal with all of this crazy stuff just to avoid using Ruby on Rails, Phoenix, Django, etc. Why? Is Next.js that much better for the user? I doubt it.
  • gitaarik 1y ago
    You only need to know one language, and that makes it easier to hire people that can work on both back and frontend
• jcuenod 1y ago
  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 remains quite inscrutable to me to the extent that I'm just going to start again with Django (where I nearly started it in the first place). So yes, it doesn't work like I expect it to either...
  • robertoandred 1y ago
    Huh? Modals work the same way they do anywhere else.
• lacoolj 1y ago
  lol when i try to explain this to fellow devs in discords they adamantly fight me on it and i dont even bother getting further into it. When I see Next.js on a job posting as a "requirement" or even as a "something we use" I immediately discard it
• zallarak 1y ago
  Agreed. I've run into so many issues with documentation and sane defaults, and the Vercel team response is to always gaslight you into thinking you've done something wrong. The truth is, its just poorly designed software. Where it shines is batteries included for getting started. They realized if you have low activation energy requirements, you will win a critical mass of people who put up with your crap. A good metaphor for devtools overall.
• rustystump 1y ago
  The feeling in the article is one i share. Frustration. It stems due to the rush job that is endemic to nextjs when it comes pushing out half baked features. It started with the app router. Case and point “Use server” “Use client” Intuitively, one runs on server and one on client. But you would be wrong. It is far more complicated. Now multiply this by 100 features. What you get is an obtuse hard to penetrate framework that seems to behave unpredictably unless you carefully read the thousands of pages of docs. Now ai doesnt help as the api changes so frequently that it often spits out version 13 and not 14.5 let alone 15 or whatever is most recent. This likely happens due to the need to rush features out for the next nextjs conf much like many other saas providers rush for their respective conf.
• deleted 1y ago
  [deleted]
• catlover76 1y ago
  [dead]
• eawgewag 1y ago
  yeah, nextjs middleware is garbage imo, if docs never give a clear example of what something is for, that's a pretty good sign that this was just tacked on without considering any particular use case. i've come to realize that nextjs probably intends for us to use RSCs for most middleware-like behaviors
• rglover 1y ago
  Shameless self-promotion, but I think people who agree here would enjoy my full-stack framework [1]. Just launched a new update that's much faster and has a lot more features. It was built for SaaS first, but works just as well for a traditional website. The ethos is "no rug pulls; it just works." Not the usual time waste of JS frameworks. [1] https://cheatcode.co/joystick https://cheatcode.co/joystick
• fatata123 1y ago
  [dead]
• kadhirvelm 1y ago
  Well the thing that’s infuriating for me is feeling like there isn’t a good, well supported alternative for writing an enterprise grade React app that will be continue to be around. I used to rely on create-react-app, but now that that’s deprecated, I often find myself asking what else can I actually rely on? I don’t want to spend eng cycles dealing with webpack and stuff, this seems to be what the React team is endorsing so I guess I’m stuck? Another thing I don’t know how to think about is the target market for nextjs seems to overlap with Ruby on Rails, a lot of e-commerce, media, etc. And most of these B2B apps I write are certainly not that…
  • worldsayshi 1y ago
    What about vite.js? One of my latest experiments was using vite.js and then using a go backend where I embedded the vite app using embed.FS. I haven't tried it in a live environment yet but it seemed like a potentially nice way of doing it.
• rob 1y ago
  I think too many newer "developers" are relying on AI tools trained on popular frameworks like Next.js to create things, and Vercel's loving this because they're the "go-to" in the end when you need to deploy something based on this stack. There's no real alternative for these developers because they weren't brought up to understand server/networking fundamentals, how to operate a VPS, etc. Vercel manages to make this even more confusing for them by blurring the line between server and client, "edge" functions, etc, while all behind variable pricing.
• resters 1y ago
  Middleware abstractions are challenging because third party libraries tend to abuse it and that can cause performance issues. Also, Vercel has optimized the middleware for its cloud business which includes various optimizations. I don't see this as a major problem, since there are so many ways to work around it if you really don't like the tradeoffs.
• philipallstar 1y ago
  > You think I'm joking? There are hundreds of issues with as many emojis with no official response for years. And when you finally get a response, it's to tell you that what you're doing is wrong and a solution to your real problems is on the way. Then they proceed to keep the "solution" in canary for years on end. It's so much easier to hire people to do prioritisation (or deprioritisation) or code of conduct enforcement or whatever than to just do good work.
• dennisy 1y ago
  Do people feel this way about Nuxt too? They have recently joined Vercel…
• theogravity 1y ago
  I also had similar issues and wrote a guide on how to use LogLayer + pino to get server-side logs working properly. https://loglayer.dev/example-integrations/nextjs.html https://loglayer.dev/example-integrations/nextjs.html Overall, the logging experience in Next.js is terrible, and not being able to chain middleware, even more so.
• coronapl 1y ago
  That’s the paradox of Next.js: it can feel extremely simple and extremely complex at the same time. For a small hobby project hosted on Vercel, I’d recommend it. For building a full SaaS product, I often regret it. I’ve run into this myself. I tried middleware, AsyncLocalStorage, even wrapping layouts and pages in HOCs. After plenty of research, it still feels over-engineered for such a trivial task. Ironically, my understanding is that Next.js on Vercel already provides a requestId by default. Another recurring issue is the documentation. The moment you hit anything even slightly advanced, it becomes too simplified to be useful, and the only guidance you find is a handful of open GitHub issues.
• vivzkestrel 1y ago
  nuxt.js is also infuriating and we need another article on it
  • danielroe 1y ago
    oh no
• andretti1977 1y ago
  My 2cents: Nextjs with page router was a very nice (and simple to learn but powerful) framework. I have always developed backend apis in nodejs with express and used Nextjs for frontend only and just when I needed SSR. Developing projects this way had always been a joy. App router did change everything and destroyed the good reputation of Nextjs: it is hard to learn, to manage and does offer few concrete advantages
• jdthedisciple 1y ago
  If you are trying to share context between middleware (backend) and rendering (frontend) literally rather than logically (via request-id only) then that seems to stem from a fundamental misconception of the distinction between backend and frontend to me ... I suspect all these "all-in-one" JS frameworks out there unfortunately made people think that web apps are made of "one big happy javascript application, yay!" while it's really two (or even three) entirely decoupled runtimes (backend & frontend) instead.
• yuriy-yarosh 1y ago
  There's tanstack router and tanstack start... And you don't have to choose frameworks. I find it infuriating how people don't utilise any TSC based compiler plugin codegen, to automate two way sync for database entities... Millions lines of code, for nothing.
• diebillionaires 1y ago
  We moved away from nextjs for similar reasons. The architecture is not flexible enough at this time to satisfy most “advanced” teams needs.
• halis 1y ago
  I’ve never used Next.js. To be honest, Express has always gotten the job done without too much hassle. In theory, what are the benefits of using Next.js over Express?
• qgin 1y ago
  Am I taking crazy pills? I love Next.js. What React partial SSR solution is better?
• terminatornet 1y ago
  It rocks how Vercel has spent so much time and money on marketing Next.js that my product manager tried to tell me last year that I had to use it. In his mind we wouldn't be able to build our app correctly (an SPA that barely a couple hundred people use) or find developers since everyone uses and knows Next.js. truly hate how hard these guys have made my job by making react popular.
• WuxiFingerHold 1y ago
  The most infuriating thing is that people still believe that you need isomorphic rendering (Next, Sveltekit, Nuxt) to have a fast, interactive and SEO friendly apps.
• hinkley 1y ago
  > This is what real engineering looks like. SvelteKit is a Vercel product. How is the flagship offering worse than what is essentially a side project. What the hell? "Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has." Margaret Mead A big project becomes design by committee. If the initial kernel was sound, it can go on for quite some time. If it wasn't, it takes herculean effort to turn such a boat. And you will likely never be thanked for it. Starting a new project to show people how it's done works as well or better than any amount of cajoling or badgering. But you still may not be thanked for it.
• jemiluv8 1y ago
  I've found that as long as I don't try to use Next.js for fullstack applications I was ok. It is remarkably good at frontend only role. Since most of my applications were built with spa's in mind, I just use Nextjs primarily to consume the api. So yes, I don't experience a lot of this angst.
• HugoDz 1y ago
  [dead]
• dumbledoren 1y ago
  The real question is how the hell some circles were able to push such complexity onto mainstream tech and what will it take to prevent it from happening again.
• Loxicon 1y ago
  The answer: PHP, no framework. I have customers, but no tech problems.
• 0xblinq 1y ago
  For all of you struggling with these modern frameworks (Next, Nuxt, Remix, TS start, etc, etc, etc)... Don't waste your time. They're all almost the same (crap), but the real issue is the instability of all of them. They change every week, they're constantly pushed sideways by the VCs or other interests behind them (or the constant mind change of their devs, i.e. React Router.. I mean Remix... I mean framework mode... I mean now we nap and then invent our own frontend framework but keep the old name, just to add a bit more to the confusion and keep everyone entertained). They're overengineered, complex, and promote the little shiny "look how fast this counter updates in a type safe way" while they totally break down when you have to do real world serious stuff like authentication (ehh...go and use this SaaS..), authorization (ehh..what's that? just put an "if"), translations (who speaks other than english?..no need for that), background jobs or anything else a real world application needs. They're focused on the shiny "typesafe call server function" and everything else is just let on you to figure out, and good luck with the library you pick, because next week it's going to be a different one and you'll be out of fashion! Many years ago I started using Inertia [1]. I'm confident to say it's the right, simple, most effective way to use React/Vue/Svelte. It's a super simple "protocol" with very thin adapters implementations that glue together your favorite frontend lib (react, vue, etc) with your favorite full stack backend framework (laravel, rails, django, adonis). I've used it for client projects with both, Rails, Laravel and Adonis. I have no complaints about it. It works super well, follows a simple to understand model and you literally get the best of both worlds: a powerful frontend, and a powerful backend. It keeps things simple and stable using rock solid battle proven production ready building blocks with great documentation and community support. I'm just done with all these other "meta frameworks". They're all marketing and hype and everyone is swallowing it and then ending up cornered with a terrible solution and a lots of problems they didn't account for and have no official or recommended solution to get out of it. That won't happen if you use plain React/Vue. That won't happen if you use plain Laravel/Rails/Django/Adonis. Inertia just glues plain X + plain Y. No lock in. No possibility of being "stuck" in a situation where "I can't do X because...."... you can.. and you can in a very nice and clean framework-supported way. It's a fantastic undervalued idea, and we're not paying enough attention to it (yet). Don't fall for the marketing and the hype. Look for the simple and pragmatic solutions, they're there. They work. They're just not as hyped, so I'm hyping it up a bit for you in this post. Apparently that's what everything needs: Marketing. [1] https://inertiajs.com/ https://inertiajs.com/