We just turned back from Nextjs after a 4 month trial for a new application.<p>Some issues we ran into:<p>- The dev environment is too finicky. Full page reloads instead of HMR and random errors after x reloads.<p>- Cache is a black hole and works differently between dev and production. They’re changing things up now with v15, but this lack of stability is not fun to rely on.<p>- The file based router has its limitations. For instance: having the language in the URL means your entire tree remounts when the language is changed.<p>- No clear way to bootstrap specific stuff outside of React<p>- Portals don’t seem to work on the server.<p>- very easy to mess up auth stuff. At some point Supabase even put out a YT video [0] where their implementation caused auth to be accidentally cached. There are 3 levels of checks you need to do just to be safe, but this is all very opaque.<p>For me it also wasn’t clear how to combine client and server state. These patterns haven’t been defined yet and I kept running into hydration issues with no clear solution.<p>A year after the app router the eco system still feels very much in limbo and brittle.<p>I also worked with Next as a replacement for Gatsby’s SSR, but quickly discovered that there’s no easy way for Next to just pre generate all responsive image sizes it needs for a static output like Gatsby has. You need to implement a custom loader and rely on something like cloudinary. This is ridiculous for a completely static site.<p>[0] <a href="https://youtu.be/v6UvgfSIjQ0" rel="nofollow">https://youtu.be/v6UvgfSIjQ0</a>
When I first discovered Next.js, it was like finding a gold-mine. I no longer had to use an express server and couple that with React and manage all the crazy configs. Next.js was so simple, everything just worked!<p>The docs were absolutely amazing, dev server was super fast, the build times were fast, I could easily create server side and static sites, host them on Vercel easily, good times all around.<p>Then came the Vercel + React partnership and it took things in a different direction. Now React almost became a child of Vercel. All of a sudden, the focus instantly shifted to server side from what was earlier client side & server side both. Breaking changes, added complexity and the strange co-existence of 2 routers, out of which the old one (which works perfectly fine btw) is certainly set to become obsolete in the near future leaving us with no choice but to move to this 'new' router.<p>Next.js app router is extremely slow. You don't even need to do anything special, just compare the dev server compile times of Next.js v12 vs v14, the performance has decreased. The dev server sometimes occupies gigabytes of memory, why?<p>Can I also mention the 'new' but worse file-based routing system that forces every page to be named page.tsx? Who thought that was a good idea? They simply copied Sveltekit. This even forced the VSCode team to introduce a way to edit the tab names because every page being called page.tsx is undoubtedly worse DX!<p>All good things come to an end, and I certainly feel this way now with Next.js. I was a proponent, I recommended it to everybody who was looking to build apps with React but now? I'm not so sure anymore, considering how confused they are about their own decisions (refer to the v14's caching controversy).<p>I'll be jumping ship to a better product as soon as I find one (and I'm sure there will be in the future). For now, I'm just sticking because of the years of familiarity with React.js and Next.js. They have served me well but Next.js has simply become Outdated.js as far as the future is concerned.
Software tools backed by businesses that target enterprises have very strong pressures towards obscurity, complexity, and generally optimizing for institutional goals and away from development experience and effectiveness. As tools that get developer adoption move up market they get worse and worse for the folks building with them.
It feels like the entire JavaScript world seems overly influenced by e-commerce, pushing all kinds of optimization, even including RSC and SSR. As a former SaaS builder, I deeply resonate with the author's point:<p>"I care way more about the speed at which I ship features, and all that complexity becomes a burden on my dev team."<p>This is exactly why I started building ZenStack(<a href="https://zenstack.dev" rel="nofollow">https://zenstack.dev</a>) toolkit. The goal is to brings simplicity back to building SaaS applications, using whatever framework you like.
I've done an enormous amount of web performance analysis work, and as soon as I see the nextjs bundle come down in the network tools I know there will be issues.<p>It just seems exceptionally slow to another stack I've seen. Whether this is poor docs or bad implementations, I'm not entirely sure, but it seems there is a major issue with it - I do not see in my analysis any other stack having anywhere the amount of issues that nextjs does.<p>The main problems I find are exceptionally poor TTFB on their server side rendering. This then pushes people to do aggressive caching of various types (without often fully understanding the ramifications of cache management) - which improves things, until a user is eg logged in then you're back to square one a lot of the time.<p>The second problem is slow hydration times, regardless of SSR/caching. This causes major waterfall problems for interactivity as the nextjs bundle still needs to hydrate before most (any?) interactivity is possible.<p>While all SPA-esque frameworks suffer with this kind of stuff, nextjs just seems to take it to the next level and it often does not seem trivial to fix when I report the issues.
Useless anecdote: I don't have direct experience with Next.js[1] (but React, Angular, Vue, Solid), but I did help a co-worker out with something in their Next.js app, and as soon as I saw the madness that was file-based routing I wrote off the whole thing.<p>[1]: mostly because I have never been interested in the modern form of SSR due to my controversial belief that that is a truly _insane_ solution to SEO, TTFB and page load performance. You don't really solve a problem by piling more problems on top, however many billion man-hours a whole industry spends on that endeavor.
Genuine question: what's wrong with a client-side SPA and a server-side backend for 90% of small-to-midsized SaaS apps?<p>I see why Vercel would want everyone using SSR and their opaque server-side caching, but why do generic non-FAANG-scale web apps want it on day one?<p>When Next became a Vercel sales tool, I switched to React + Vite + backend, and everything just got so much easier.
I used Next.JS awhile ago and it was great. Then I switched to Remix and it was great. Then I went back to Next.JS and I couldn't understand where things went wrong. From the routing model to the deployment model, it all felt so broken that I couldn't convince myself to continue using it.
I started a project with next about 2.5 years ago. That version is pretty good, easy to reason about.<p>A year or so back I spun up a new next project only to be greeted with very unintuitive errors regarding trying to use client libraries in server pages? Something like that. I wondered if I was going crazy or if this was actually going in a terrible direction.
All this negative sentiment around the App Router like in this post made me really scared to adopt it.<p>I've just been working with it for the past 2 months and absolutely love it. The biggest reason being the ability call functions directly from server- or client-side code! You basically only need to write API endpoints now for externally-facing services. Saves so much time and boilerplate...<p>Yes it is more complex than Pages Router. And while I'm a staunch advocate for simplicity where possible, I do think the tradeoff is worth it for new projects. It just takes a bit getting used to. The negativity feels a bit like hooks all over again tbh...
Do people use Next.js as an API server too? In all the projects I've joined, we've only used Next.js as a static frontend framework and dev tool built on top of React. We never touched the SSR feature, just used it as a static site generator, and didn't bother implementing any APIs in Next.js. I can't imagine someone can implement a robust code base while mixing frontend and backend code in that messy folder structure.
As someone who got started with web dev by sending HTML over HTTP I marvel about the ways modern web devs contort themselves to be able to send json instead.
I am not a frontend dev, but I've been using NextJS for the last 6 months to build a website and I've been using the App Router because I wanted to have SSR and because NextJS suggests to go with that.<p>I'm feeling good with it at the moment, even though I'm trying to keep things as simple as possible so you might argue that I'm not really pushing it to the limits.<p>The major "issue" I'm having is mixing server and client components as I inevitably tend to overcomplicate stuff: if I need any kind of client interaction then I have to mark is with `use client`, but then everything you place in that component also becomes a client component. If you want to keep server components in a client component you have to pass it through the use of {children} prop which sometimes is not ideal.
next js is one of those projects that unintentionally makes things complicated on purpose. Everything is going very well up to a certain point. but at some point you find yourself in a server <-> props hell.
My observation as a [mostly] backend dev is that the JS world in general is fascinated with building complexity and then using more complexity to address the previous complexity. Transpilers, converters, tree-shakers, oh my. It's 2024 - building a web app should not be rocket science or require such obscene tool chains.<p>Unrelated, but I've been trying to finish a project of mine, and after long breaks I would discover that my front-end code was out of date. There was already a better framework, or a new version, making your old code obsolete. I gave up after Vue 3 introduced composition API - all I did was learn "the new ways" without actually building anything.<p>Then I switched to HTMX and ditched all that bullshit.
As a person who got back into web dev and tried Next for the first time, I was pretty upset once I learned that I was using this half baked App router rather than the more straightforward page router.<p>Their FAQ literally asks if their are <i>any</i> open source applications built on app router:
<a href="https://nextjs.org/docs/app#are-there-any-comprehensive-open-source-applications-built-on-the-app-router" rel="nofollow">https://nextjs.org/docs/app#are-there-any-comprehensive-open...</a>
I think it makes a lot of sense for Vercel to push RSC and all the complexity of new Next.<p>- They sell compute / bandwidth. You can not make a lot of money if people are building SPAs that load from a CDN and execute on client.<p>- SSR kind of gives them some server compute but as soon as the initial page is loaded, we are back to point 1.<p>- Here comes RSC then. And they pushed hard. Made it look like the best thing ever. Oh the initial load time is the most important metric. You gotta make sure you hit this score on whatever benchmark thing…<p>- They also kind of acquired React. It is basically Vercel’s now so they can dictate the development direction.<p>- All this with almost no benefit to developers (compared to something like pre app dir next) but likely helps them a lot in terms of revenue.<p>I mean this might read like “vercel evil” post but it is what corps do and they seem to do it well.<p>I used next on a project recently and will not touch it again because the hype did not materialize as any type of gains during our own development.
I'll never get over how convoluted it felt to make a modal appear on the screen, using the "blessed" Next.js way. You need parallel routes, slots, intercepting routes, file names that look like the blast radius of a shell script gone wrong with names containing (..)s, [slugs], and @slots, and special-purpose file names like page.ts, index.ts, default.ts, some stuff auto-magically passed in as props.<p>It's like they're trying to take ideas from something like Rails without having ever even used Rails, and then pervert those ideas.<p>I know I sound overly critical perhaps, and maybe I'm being too harsh, but it just feels like there's this bizarre appreciation or worship of arcane complexity by Next devs. And any simplicity and straightforward-ness is shunned and frowned upon. Like simplicity is somehow beneath them, and simplicity is only for stupid plebs like myself.<p>I haven't used Remix, but their docs suggest it's simpler.
I am building an alternative to nextjs that consists of just 3 files and has no external dependencies.<p><a href="https://github.com/spirobel/mininext">https://github.com/spirobel/mininext</a><p>(my goal with mininext is to provide index.php like productivity but with all of npm and typescript at your fingertips)
I avoid all SSR with node.js these days, not that they're bad, but:<p><pre><code> 1. it's a mature field with many solutions already, no need reinvent the wheel for me.
2. the frontend is complex enough</code></pre>
I'm still using the pages router due to complexity of the app router. At this point, I think that I'll move to another framework instead of moving to the app router. They completely botched the transition from pages to app router and even now, literally years later, there are still simple things you can't do with the app router. It's also just hugely confusing defaulting to server components. It's a shame because in the beginning, Next.js was a breath of fresh air.
Inertia.js is the way forward for me (and my company).<p>Just the way to use react or vue the way it was intended to be used, paired (in a beautiful way) with a real backend framework such as Laravel, Rails, Django or Adonis.<p>I’m so done with every weeks new “full stack framework” that doesn’t do anything but routing and has an uncertain future.
The hardest think now is forgetting all the patterns we used on client side only say.<p>On successful form submet change the ui based on this error state.<p>Now because of server actions you would just redirect to a success page..<p>It’s actually way simpler. It harks back to full SSR like Django/Rails/Wordpress
I would like to see a fullstack framework like next for Webcomponents. And one thing is missing for all fullstack frameworks: A CMS. Astro and next is very good but I can not offer markdown or jsx for a client
I think Vercel has a good product and clearly very talented engineers working there, but their takeover of the React ecosystem has been alarming. A well executed embrace-extend-extinguish playbook to get people using the Vercel platform.
I think that the industry is very slow into abandoning the React ecosystem (that's a huge statement to React's impact) for saner choices like Vue/Nuxt that have none of the problems of the react ecosystem.<p>At the end of the day, React's weakness will always be it's model of render functions, while nice to reason on, it's close to impossible to pre compilate. That will always make React slower than template, and directives based alternatives, so people need to go into madness to get good performing react applications, and none of this is gonna come out of the box.