Remix clone Hacker News

This is very cool.

Do you have any ideal the cost difference of running this VS NextJS for any particular workload?

I use NextJS on Vercel for so many projects but mostly smaller things since I know it can get very expensive after scaling up.

▲

greyskull 5 days ago | parent [-]

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).

[0] https://nextjs.org/docs/app/api-reference/components/image#s...

▲

dbbk 4 days ago | parent | next [-]

There's pretty much no reason to use Vercel's image optimization, just spend 30 minutes setting up Cloudflare Images and call it a day

	▲	greyskull 3 days ago \| parent [-]
		I agree.

▲

syndicatedjelly 5 days ago | parent | prev [-]

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?

	▲	jonplackett 4 days ago \| parent \| next [-]
		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.
	▲	greyskull 5 days ago \| parent \| prev [-]
		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.