211–220 of 602 posts
Unfortunately incompetence of developers to see beyond has brought the web to the point that every React developer has dealt with Nextjs at some point.
What are the alternatives beyond Vite and Remix?
If you picked NextJS without knowing how it structures its middleware, the vendor lock-in to Vercel, its SSR strategy, its hydration schemes etc. that's on you. I, and many others, have had a lot of success with NextJS increasing delivery speed and ultimately, customer value.
Two years ago I moved off of the React ecosystem to Elixir/Phoenix/LiveView, and it's been great. But that's had its own challenges stemming from the design decisions its creators have made. You're always going to be running into things that you don't like, and I feel NextJS has just become an easy target for people who are looking to vent.
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…
This seems to be built into the culture of companies which have those ridiculous whiteboard leetcode interviews. You find people who can produce very clever complex solutions in their sleeep, and then they do that. Interviews aren't selecting for people whose strength is simplicity and clarity instead. So you get a lot of tight loop optimizers and they tight loop optimize everything... not just the tight loops. But if your product is a library/framework being consumed by mere mortals, you probably want something simple if you want to succeed in the long run. The super car's performance is meaningless to you if you can't drive stick.
Next.js is marketing to get you locked into vercel hosting.
Earlier quoted context omitted.
>Windows doesn't (didn't?) have ENV vars Nope, windows has had perfectly standard environment variables since the DOS days
What's "missing" is the ability to launch things the "Bash" way: `KEY=value ./myApp`. Where the variable is scoped to the single execution. Windows' command prompt requires two separate invocations: set KEY=value ./myApp PowerShell also: $env:KEY='value' ./myApp Or more "verbosely/explicitly": [System.Environment]::SetEnvironmentVariable('KEY', 'value') ./myApp Regardless, all those methods aren't "scoped".
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…
This is the exact problem with the App Router. It makes it extremely difficult to figure out where your code is running. The Pages Router didn't have this issue.
I feel a poor tool choice for your use case should not give you the right to blast the tool and it's design decisions. Most of those complaints are resulting from not understanding how NextJS works and the design decisions that it's creators have made. For example, the middlewares. they're to be treated as a hook. If NextJS had a mechanism for having handlers like Express does, you'd have complained about handler exe…