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.
Besides that, app folder is slower than pages.
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.
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.
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.
Reminds me of the +page.svelte in SvelteKit.
What do you recommend?
You can render simple HTML/CSS/JS snippets where required, and go all the way up to Svelte/React/etc TSX components without ceremony when you need more complexity.
I am unsure if the things that bothered me are still an issue, but they were...
1. Ridiculously long build/reload times (1~3 seconds for a fairly simple app).
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.
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.
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).
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.
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.
Then recently, for another client, I tried nextjs 13. What a POS. A lot of the patterns I had learned were tossed replaced with something more complicated.
My first client is still happy but I will never use the stack again. Waste of time.
On the plus side, it has many constantly-changing dependencies to support.
Kinda scared what that means for Astro, having Vercel as their primary hosting partner, hope they don't get bribed into poor choices.
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.
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?
Um…
The process is very straightforward and requires little to no extra steps when compared to Vercel.
It's certainly possible you just don't use any of the features they're pushing in that direction, but I mean, they literally dropped basic Request compat just to enable serverless runtimes, and you can't use an img tag without being warned to use their Image Optimization feature, which has no open implementations...
Pretty much, most of the energy being spent on Next.js development is towards serverless deploys which use a build format that has to be reverse engineered by outside parties.
According to a quick google search Vercel has raised at least $313M.
I think we've probably been there for over a decade since we left the PHP/Django/Rails + jQuery paradigm.
I had a route with console.log(request) and some db stuff.
I removed the console.log and it broke my build.
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.
Insane.
Switched to remix which while still completely asinine and similar in many ways has slightly less magic footgunnery.
Next app will be built with something less dumb tbd.
Unfortunately I have not seen anything better than them for javascript. Of course I am a bit hesitant to venture out of React's comfort zone to try something like Astro, that doesn't help
Hope Meta spins off React and hope Vercel stop ruining React, the way it bought up Svelte and made it whatever Vercel likes.
I recently tried Deno Fresh and it has made many different choices that I resonate with:
- "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."
- "For stronger resiliency and user experience, Fresh relies on native browser support for form submissions with the HTML <form> element."
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.
99% of the React ecosystem does not function without reactivity enabled: it's literally in the name.
As a result most applications written in React depend heavily on interactivity. The only category that is an exception is ecommerce where you're normally pulling from a CMS... and Vercel needed to fight Shopify for that space so they went and "helped" the React team turn the framework into something it's not with RSC.
_
Also most of your complaints aren't at all addressed by Deno? It uses an amount of magic closer to current Next.js than pages-era. It actually removes some conventions for separation that Next.js has (all routes potentially being api routes for example). And as far as I can tell both libraries expect you to explicitly handle errors during data fetching (and your users would probably appreciate that too)
_
One of these days I might get annoyed enough to fork Next.js 1.0, sprinkle in a folder router for express and call it a day on a framework that doesn't fight React and just stays out of my way.
"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."
And:
"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."
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.
Yes, correct.
> This is also why there has effectively only been a single breaking change in 8 years of React Router.
https://twitter.com/ryanflorence/status/1715023981340967214
I do agree with it; I've had to do some huge react-router upgrades and the only one that was truly painful was v3 to v4
I don't have a horse in the race. I don't use Next, Remix, or even React.
