It offers packaging for deploying to a serverless environment (e.g. Lambda) analogous to how Vercel does it.
The last question is salient, and it's possible for OpenNext to break and have to catch up to changes in Next.js, though I believe there's some more direct collaboration. I'd say that's the biggest downside - it's not guaranteed compatibility.
I did a migration recently (comments elsewhere in this post), and I don't recall the specific issue, but I _do_ recall running into at least one scenario where OpenNext had made a decision that impacted - in a way that was visible to me and undesirable - how Next.js functioned. That's not a criticism, there's tradeoffs.
OpenNext does model [0] incremental static regeneration, but beyond that I actually don't know, or at least don't recall. OpenNext doesn't do per-route lambdas like vercel does, so it's not like you get any behavior differences there.
I _think_ you can get scale to zero on Lambda by deploying a docker container, too.
OpenNext is just for packaging the Next.js build artifacts. The infrastructure is defined by projects that deploy those artifacts, examples here: https://opennext.js.org/aws/get_started
Some of them are, for example, Terraform projects that list the specific infra. I have experience with the SST deployment, whose website unfortunately doesn't do a great job of listing the infra architecture.
The biggest cost for us on Vercel (several hundred dollars a month) was Image Optimization, and that was because the app was being majorly inefficient with images, in part due to some default behavior in Next.js that we found unfriendly [0], and in part due to negligence. That being said, it wasn't "cheap" by any means outside of that, still hundreds a month for something that I would not consider a high traffic application (I wish I could remember more specific numbers).
Migrating to OpenNext using SST, I think we got the bills for compute and asset serving down to like $15/day or something (granted, we spent expensive engineer time on the migration).
That’s insanely expensive for a low traffic web app. Why should anyone use Next.js, given a choice? Are the handful of milliseconds shaved off for the end user worth the cost?
People (me at least) us NextJS for the developer experience. It really is quite good. If you mean why use Vercel, again - great developer experience. Just expensive.
1) I don't think it's related to Next, per se, but there may be behavior I didn't build the expertise to comment on. I also know that there were major inefficiencies in the application, so, for example, our P90 latency was (imo) terrible.
2) We'd have to define what constitutes low traffic vs any other arbitrary measure, so it's moot to discuss like this; all I said it wasn't high traffic. You could run it for cheaper, but there wasn't much expertise for self-hosting, for example.
3) For all I remember it may have been half that in daily cost. In any case, miniscule compared to engineer time. What was worse was the prior decision to use serverless aurora rds, that dwarfed everything else in AWS cost - I know this is tangentially related, just saying optimizing that a bit more was not the highest priority, we could do it for cheaper.
In the company I just left, I actually went through the process two or so months ago of migrating their Vercel deployment to AWS. I evaluated several options that are listed on the website and on GitHub, and we landed on using OpenNext via SST, it was a low-pain effort, especially given the CTO's desire to also migrate off of Next.js.
As other commenters have touched on - my understanding is the purpose of OpenNext is to package the output artifacts of a Next build in a way that can be deployed to a serverless environment, analogous to how Vercel does it. The supporting projects like SST and the other links in the repo are to take those OpenNext artifacts and deploy them to infrastructure generally in an opinionated way - additionally supporting some of the "extra" features described in the repository.
The last project I was working on was to then migrate from SST to Fargate, as a persistent process (serverful?) deployment was preferable for various reasons. In that scenario, we would just be running the built in server using the Next.js standalone deployment mode (effectively a `node index.js`). We didn't need the extra functionality covered by OpenNext.
bad stack in what way? Why is vercel shady? I can understand that the business model is questionable to lock-in people with developing a framework that runs best on their own cloud, but shady would mean fot me, that they do something illegal
I think remix is a lot better. But the problem is that the team behind it (same as react router) have spent the last 10 years changing their mind every Tuesday and rewriting everything and breaking every API, it’s a cat and mouse game of chasing their latest idea all the time.
Btw, remix itself is deprecated. There you go.
What would I use? For sure I’d go with a MUCH saner and stable approach: inertia.js as the glue between React and a real full stack batteries included framework such as Adonis, Laravel or Rails.
I see that the book is incomplete. I didn't know that early access for books was a thing, very neat. It might be pertinent to note in your post that it's still being written, with an estimated release window of Spring 2025.
I'm very much a "consume it when it's ready" person, so I'll keep this on my watch list.
It's a still-unresolved issue as far as I know; the linked ticket was only closed last year because Gitlab has no control over it as long as they want to continue using Cloudflare. The companies which do have control over it have not fixed it so far.
Off-topic, but what's with the strange font in the image at the top of the article? I see it's based off of the "csa" logo. I can't explain why but it's almost uncomfortable to read it with those connected glyphs.
> I would appreciate "automated rumble strips" that warns me gently if I veer out of my lane.
Our Bronco Sport has this (steering wheel vibration) in addition to lane assist. I don't like the latter, so I appreciate that I can enable/disable the two modes independently.
> Our Bronco Sport has this (steering wheel vibration) in addition to lane assist. I don't like the latter, so I appreciate that I can enable/disable the two modes independently.
I know it's way more stuff for them to test, but being able to enable/disable individual features is so huge. My blind-spot warning on my Mazda is super sensitive (plus I drive mostly in traffic so any time I put my turn signal on there is a car next to me). I want to be able to turn it off, but since it uses the same sensors as my RCTA, they can only be enabled/disable together. I love the RCTA, so I just have learned to ignore the beeping that invariably happens every time I signal...
This applies more to VPN as a tunneling technology rather than an anonymity provider. But I don't want to share my personal IP address with everyone I interact with online. I don't currently care if, say, Hacker News or Reddit knows it, or really any big web platform where I'm not that interesting to them. But everyone and everything else? It could invite attacks, DOS, expose geographical information, social engineering targets, etc. A VPN at least gives you a layer of protection, and ideally one that you can throw away if anyone targets you. Once someone knows your main IP address, it probably can't be changed quickly, may be difficult to change it at all, and may even be impossible in some cases. It's a piece of knowledge you can't take back, so sharing it by default is bad, IMO.
So I guess that's just a security/privacy concern, but the key point is that you should be secure/private before you think you need it.
The last question is salient, and it's possible for OpenNext to break and have to catch up to changes in Next.js, though I believe there's some more direct collaboration. I'd say that's the biggest downside - it's not guaranteed compatibility.
I did a migration recently (comments elsewhere in this post), and I don't recall the specific issue, but I _do_ recall running into at least one scenario where OpenNext had made a decision that impacted - in a way that was visible to me and undesirable - how Next.js functioned. That's not a criticism, there's tradeoffs.