251–260 of 602 posts
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.
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.
My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting
I'm sure commercial incentives would lead issues that affect paying (hosted) customers to have better resolutions than those self-hosting, but that's not enough to explain this level of pain, especially not in issues that would affect paying customers just as much.
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.
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.
My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting
I heard this excuse for Next.js and thought I’d get around it by using Vercel, which was fine for my project. It didn’t seem to make a difference.
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.
My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting
After a week of futzing with it I just threw up my hands and said 'no can do'. I couldn't untangle the spaghetti JS and piles of libraries. 'Compiling' would complete and if you looked at the output it was clearly missing tons of bits but never threw an error. Just tons of weirdness from the toolchain to the deployment platform.
> 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…
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.
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…
> Half these issues stem from a relative misunderstanding of exactly where the code is running. I used to think Javascript everywhere was an advantage, and this is exactly why I now think it's a bad idea. My company uses Inertia.js + Vue and it a significantly better experience. I still get all the power of modern frontend rendering but the overall architecture is so much simpler. The routing is 100% serverside and t…
After looking through the 20 different popular front end frameworks and getting confused by SSR, CSR, etc. I decided to use Nuxt. I thought oh this is great, Vue makes a lot of sense to me and this seems like it makes it easer to make Vue apps. I could not have been more wrong. I integrated it with Supabase + Vercel and I had so many random issues I almost scrapped the entire thing to just build it with squarespace.
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 Lar…
Nah, Laravel is proof that over engineered abstraction can sometimes be done right. Laravel works beautifully in production and I have never regretted using it.
Earlier quoted context omitted.
what do you mean? Shopify is the largest eCommerce platform and runs rails.
I think they mean that Shopify doesn't decide what happens or doesn't happen to Rails; Vercel decides what happens or doesn't happen to NextJS.