Still no option to export a static site when using next/image without relying on 3rd party services, right?
The only option that comes to my mind is using Vercel to host the site but then every image is transformed on demand which results in horrendous loading times.
Is this really how „everyone“ uses Next when exporting static sites?
Also disappointed by this. Vercel has increasingly been putting out more features that are tucked behind a vendor-lock.
- `next export` when using `next/image` doesn't have a sane default
- Running a custom server means no deploying to Vercel. I understand that one the most, since Vercel has decided to lean on serverless
- Next.js Live can only run on Vercel
I still reach for Next.js + React first when starting a new web project, but have since replaced Vercel with Render because more times than not, I need to run something that just doesn't work on serverless. Been a user and fan since v1.0.0, and have only just started noticing some features that go against the "sane defaults, config available" ethos that seems to be core to the team.
>Running a custom server means no deploying to Vercel. I understand that one the most, since Vercel has decided to lean on serverless
For those who want simple serverless deployment, but don't want to vendor lock in with Vercel, checkout serverless-next.js, it makes deploying to aws lambda@edge directly a breeze, it's awesome![1].
This is not entirely accurate. First, we are working on build-time image optimization, it just wasn't our first priority (https://twitter.com/rauchg/status/1402613436081528836). Second, the vast majority of Next.js applications do not need a custom server.
Finally, Next.js Live is two parts – the soon open-source dev engine, and the collaboration features. The first will be open-source, always. The second can be any platform (like Vercel) with the ability to sync and store your code edits.
This is all fair and good. I was just pointing out the beginnings of a trend.
To me, build-time image optimization would’ve been a prerequisite for next/image even launching in the past. Something in the tune of “…and Vercel does all of this for you, automatically, by default when deployed to Vercel”. Instead, we get a build-time error on export.
I agree that the vast majority don’t need a custom server. If I could go without one, I would. Unfortunately I can’t, and this one’s not a criticism. It was clear to me once “Develop. Preview. Ship.” became the tagline that things like Docker support would go away. Fair.
Glad to hear Next.js Live will be open source, and I’m assuming it’ll be easy to deploy given the quality of Vercel’s work. I personally don’t understand the use-case but can see how it adds to Vercel’s value add.
Appreciate the reply! I just wish Vercel looked into immutable database provisioning, continued Docker support, alongside the stellar React work.
This works well for us too. It doesn't have all the conveniences of next/image, but it lets you get closer to more reliable and better performance in our experience. Yes you need to understand what you're doing a little better, but it isn't rocket science.
Not sure if this would fit into your use case, but in my use case, I have custom js code which runs at the build time and downloads/compresses/resizes all the required images into node.js file system. Then, next/image serves them as it would from local static image source. The drawback is I have really long build/export times.
The lack of official solution eventually made me ditch in favor of Gatsby. Granted it was a large change but I found that the way Gatsby handled images was just better than how Next.js handled them.
The only option that comes to my mind is using Vercel to host the site but then every image is transformed on demand which results in horrendous loading times.
Is this really how „everyone“ uses Next when exporting static sites?