That's said, I totally agree with the author.<p>The fact is that Next.js is becoming complicated. It's not simple anymore. Now you have to use a app folder with "page.js" to make it as a route. It's not file system routing anymore. It's folder router.<p>Besides that, app folder is slower than pages.<p>The amount of complexity to build a simple react app is overwhelming. You need to know the conventions created by a so called convention free framework.<p>I've been building nextjs apps for 1+ years, but for the next one I will be looking for an alternative, maybe Remix, Redwood, I don't know.<p>Vercel became Apple. They really like to make great presentations, and events, to their releases, but, instead of increasing the developer experience, they are decreasing it. The only good thing about vercel, as said by the author, is the Next.js deploy, that is really easy to do.
I tried Next.js 13 (with app directory) for ~3 months building out an MVP for a product idea I had.<p>I am unsure if the things that bothered me are still an issue, but they were...<p>1. Ridiculously long build/reload times (1~3 seconds for a fairly simple app).<p>2. Lots of memory/cpu usage while developing (2+ GB of memory, cpu spikes). I got tired of listening to my laptop rev its engine every time I saved a file and it built/reloaded.<p>3. Complicated logic for simple things like authentication. Really? I need to make a request to get the user/auth state on every page load? Potentially cache it and try to manage/pass it down everywhere? Maybe I'm old school and like the simplicity of the server doing all of that for me, but it felt so janky... especially dealing with styles/components while a refresh is occurring before it knows if it's authenticated or not. Yes-- you can sorta do it on the server with Next, but you can't mix server components and client components in one file, so it became a mess of both in different files with complex props/passing.<p>4. Although Next is open source and doesn't require Vercel, I kept getting the sinking feeling I was being locked into something (edge functions, etc).<p>5. Large (20-30ms) latency between the app server and the database. Maybe this is me being old school again and the benefit of running my app server on the same box as my database, but I like having 0-1ms latency from the app server and the database. I always strive for 50-150ms round-trip latency for my requests and that's hard when the database is adding 30ms.<p>Needless to say, I tossed it and re-wrote the entire thing. I don't consider it a waste of time.. I gave Next and the SPA gang a fair try.
"Next.js is eating React" and "Independence" are definitely two sections where I massively agree. I don't like Vercel, they seem... subtlely villainous. Hearing how much of a pain it was to maintain Next support for Netlify, and personal experience trying to work with Next on Cloudflare is kinda shitty, yet it works perfectly on <i>Vercel</i>.<p>Kinda scared what that means for Astro, having Vercel as their primary hosting partner, hope they don't get bribed into poor choices.
We’re slowly getting back to the “I don’t know who’s right” phase of web framework “innovation”.<p>I can at least tell that Next.js is winning on growth. More new startups are building with it according to the job boards I’m seeing, esp. compared to Remix and even the other contenders (Vue, Svelte)—-at least in the States.<p>Kent’s point about Vercel platform lock-in is pretty eye-opening, though. Not able to easily deploy Next.js outside of Vercel? And, it’s a platform ran by a startup? It’s also not profitable?<p>Um…
I tried nextjs.<p>I had a route with console.log(request) and some db stuff.<p>I removed the console.log and it broke my build.<p>Because their magic compiler thinks if you don’t reference the request param then the code should execute at build time. So it tried to query the database from CI.<p>Insane.<p>Switched to remix which while still completely asinine and similar in many ways has slightly less magic footgunnery.<p>Next app will be built with something less dumb tbd.
The key info here to me is that Vercel hijacked React project to some extent, hired many of Meta's react developers, and forcefully turning React to whatever Vercel favors that has nothing to do with KISS, what a pity.<p>Hope Meta spins off React and hope Vercel stop ruining React, the way it bought up Svelte and made it whatever Vercel likes.
My advice? Focus on solutions, not tools. For the past forty years I've watched people search again and again for the perfect development tool. Always looking. Not saying it's not a good idea to look at different tools from time-to-time (like every 3-5 years take a look what's available now), but the way you get to the point of doing this work for forty years is delivering solutions.
I haven't tried Remix but I can relate to Next.js being too much magic. I've had errors in `getServerSideProps` that happen on the server and then <i>again</i> in the client, causing a client side error instead of simply rendering the 500 page. I've accidentally bundled server code in the client because there's no clear separation. The automagical client side navigation with <Link> has caused scroll position to be forgotten when navigating back.<p>I recently tried Deno Fresh and it has made many different choices that I resonate with:<p>- "When you create a route, all of the components used are rendered on the server. No javascript is sent to the client, unless you specifically include something from the /islands/ folder."<p>- "For stronger resiliency and user experience, Fresh relies on native browser support for form submissions with the HTML <form> element."<p>For example a route that renders a form and accepts a `POST` with that form is trivial, which amazingly can not be said for many server side React frameworks.
I wasted much time trying to make Next.js work, both the new and old version. Way too much complexity and issues, not to mention build/reload took > 10 secs. Switched to Vite with vite-plugin-react-pages and things are back to simple. refresh/reload is a sec or less like it should be.
The author argues multiple times that Next uses the React canary release channel and that's unstable. I think the name for this release channel might be misleading:<p>"We’re introducing an officially supported Canary release channel for React. Since it’s officially supported, if any regressions land, we’ll treat them with a similar urgency to bugs in stable releases."<p>And:<p>"Unlike the Experimental channel, React Canaries only include features that we reasonably believe to be ready for adoption. We encourage frameworks to consider bundling pinned Canary React releases."<p>While I think that Next.js 13's release was bumpy and about a year too early (let's blame it on the VCs), the App Router is in nice shape today and ready for production. It has a steep learning curve though and your brain needs to painfully unlearn some well-established patterns.<p>Source: <a href="https://react.dev/blog/2023/05/03/react-canaries" rel="nofollow noreferrer">https://react.dev/blog/2023/05/03/react-canaries</a>
I use next and it's been fine for me but I only use pre rendered builds and I do not use any of the server side logic. I assume all these complaints are related to using SSR with next? I have noticed next getting more in my way though I assume it's the noxious presence of investor money. Investment money would f up a cup of coffee if it could
React Router changed heavily every major version and I had a bad experience using it. Maybe Remix will be stable than that considering it's backed by Shopify.