Why we ditched Next.js and never looked back(northflank.com)
northflank.com
Why we ditched Next.js and never looked back
https://northflank.com/blog/why-we-ditched-next-js-and-never-looked-back
15 comments
I used Next.js with mui.com at one point, and after each change in dev mode it took 10s to recompile. I don’t touch anything that has to do with Vercel ever since then.
Next.js doesn't play well with barrel packages (large packages that export everything into the main entrypoint file). It's a known issue (but rarely mentioned when you read about working with Next.js):
https://github.com/vercel/next.js/issues/48748
I've never used MUI, but assuming that MUI is a barrel package, and you do the following:
https://github.com/vercel/next.js/issues/48748
I've never used MUI, but assuming that MUI is a barrel package, and you do the following:
import { Component } from "mui";
import { Component } from "mui/path/to/component";I switched to Astro plus tailwind and never looked back. If you are interested though, imports are a pretty big thing in mui https://mui.com/material-ui/guides/minimizing-bundle-size/.
To be honest, if you're making a content site such as a marketing site or blog, it really doesn't matter what you use. You can use Next, Astro, Gastby, HTML/CSS etc. Doesn't matter.
Next.js excels when you have a complex app with interactions, SSR requirements, CSR requirements, backend requirements, etc.
Next.js excels when you have a complex app with interactions, SSR requirements, CSR requirements, backend requirements, etc.
I disagree. I’m building an audio player in Astro.
https://github.com/mayo-dayo/app
https://github.com/mayo-dayo/app
That sounds like a MUI problem, not a next problem. What a clunky UI framework. Next plus tailwind remains lightning fast for me.
The lack of any substance to their claims besides vague hand waving is a tell tale sign that they don’t have solid engineers working on this project. If they had specific GitHub issues documenting this behavior or code samples then it would be much more plausible. I’m sure there are some issues but the performance improvements they’re getting are far too large to be anything besides their own fault.
Additionally being able to replace their implementation in 3 days is a sign of extremely shoddy engineering. If you can replace it in 3 days but you can’t fix it then you’ve had irresponsible maintainers.
I’d recommend Docusaurus for a static docsite over NextJS. It’s got a lot of batteries included.
NextJS is a framework. You can make it extremely slow. No framework can save you from yourself.
Additionally being able to replace their implementation in 3 days is a sign of extremely shoddy engineering. If you can replace it in 3 days but you can’t fix it then you’ve had irresponsible maintainers.
I’d recommend Docusaurus for a static docsite over NextJS. It’s got a lot of batteries included.
NextJS is a framework. You can make it extremely slow. No framework can save you from yourself.
Lol I'm not going to take advice from an agency that pops up a email dialog that gives debug error message on empty entry, plus I can't dismiss the popup to read the rest of the article.
I'd like to know why they ditched NextJS, but if they're so bad at webpages I can't read the article on my device (iphone SE 3) that I can't dismiss the popup, I don't know that they're worth listening to.
I'd like to know why they ditched NextJS, but if they're so bad at webpages I can't read the article on my device (iphone SE 3) that I can't dismiss the popup, I don't know that they're worth listening to.
Sticking to my SSR sites with Go, Fiber, and Go Templates plus a touch of HTMX for interactive islands. Fast AF, simple, reliable. Great dev and user experiences.
I personally like sveltekit + shadcn-svelte , though to each their own.
Go + Go Templates is lovely. 5 years in, no problems ever.
The same company that built its entire identity around Jamstack and static site generation pivoted to serverless, then became the cheerleaders of SSR—the complete opposite of what they originally pushed.
The SSG/Jamstack came later as features.
They didn't pivot from SSG to serverless. These aren't even comparable things. Serverless is just lambda functions. SSG is generating static files from React.
Vercel (formerly Zeit) pivoted from always-on servers to serverless functions. Next.js SSR can function in serverless or always-on server mode.
[0]https://web.archive.org/web/20170511054633/https://zeit.co/o...
Something went wrong: : {"status":422,"statusText":"unprocessable_entity","errors":[{"message":"can't be blank","code":"EMAIL_BLANK"},{"message":"is invalid","code":"EMAIL_INVALID"},{"message":"You cannot refer yourself","code":"BASE_YOU CANNOT REFER YOURSELF"}]}
Hilarious
Hilarious
Just use php. SSR since 1999
I've never seen this. Next.js is very fast for basic pages.
This just seems like code issue and not Next.js. Plenty of sites use Next.js and have billions of views/year.
This might have something to do with the database/server being far away and nothing to do with Next.js.
Could explain the above inefficiency. Usually when you build your own server, it sits as close to your DB as possible.
It's actually really hard to do SSR with React at scale and good client side. One thing Next.js (and other modern frameworks) do very well is that the initial load is SSR, but subsequent loads are client-side.
Truthfully, they should have picked an SSG generator. It's better than using SSR, and certainly better than using a custom SSR solution. It's a marketing site with little to no database content.