Next.js static export not supporting `next/image` is *wild*.
“Since Next.js supports this static export, it can be deployed and hosted on any web server that can serve HTML/CSS/JS static assets.”
But not images!!
This is a prime example of customers losing from an unhealthy relationship between framework and hosting provider.
Zach Leatherman 2727 replies 2525 likes88 reposts Original on Mastodon27 replies
Notably, Vercel has a financial incentive to *not* implement support for a bunch of features in static export in Next.js.
Either static export is a viable feature for portable Next.js projects or Next.js is not a portable framework.
@zachleat I think that's a common problem with vendor-driven open source projects. I sympathize with them because they've created a bunch of value and, understandably, they want to capture it.
What would you recommend as an alternative?
For me, it’s hard not to see the larger problem (and not limited to Vercel).
Hosting providers are prioritizing dynamic features because dynamic things make more money!
@jlengstorf said it first: https://www.youtube.com/shorts/tf2erRqdwqc on #TheFutureOfJamstack
@zachleat @jlengstorf This guy gets it. 😅
@zachleat @jlengstorf Vercel just sent me a notice of pricing changes. Edge functions are now a lot more expensive if I understand it properly.
@ahoyboyhoy @jlengstorf SaaS pricing at this point is so complex that it’s almost impossible to predict what anything will cost
@zachleat React officially recommends using frameworks, and it feels like a problem when considering that NextJS is mentioned first. If it says on the first page of the documentation, "Do you want to use the most popular framework? ① Pay $20 a month to Vercel...," will everyone use React?
@otowa0 That is a very awkward relationship, yes! Especially as Vercel hired some of the React core team from Meta iirc?
-
@iamdtms image processing through Vercel AI only 😭
@zachleat If only there was some kind of free, open source library that could be used to provide such a feature. 😜
@lovell legendary reply 🏆🏆🏆
@zachleat this is insane! Working on an API doc site ATM and I'm doing the lord's work and using 11ty.
@martycoote appreciate you Marty!
@zachleat It doesn’t support exporting optimized/minified images but it does have an image component that will export your images.
A silly limitation, and your point on incentives is obviously still valid, but it is much less silly than fully not supporting images.
@alannorbauer by “export” do you mean that it will swap to use a static image url as-is without changing your <Image> app code or paths to the image?
@zachleat Yeah. I have a layer of indirection on my site, but this markdown: https://github.com/altano/alan.norbauer.com/blob/b252e36306ca39747583b73952943508c45526a0/src/content/articles/disable-source-maps/index.mdx?plain=1#L30
Goes into this Image component: https://github.com/altano/alan.norbauer.com/blob/b252e36306ca39747583b73952943508c45526a0/mdx-components.tsx#L61
Which produces:
```html
<img alt="…" … srcSet="/_next/image?…" src="/_next/image?…"/>
```And I can turn export on/off without changing the Image component usage. The only thing that has to be toggled on/off to export is image optimization.
@alannorbauer not sure I understand what you mean. When you static export your site, whether or not you use `<Image>` or `<img>` in your markdown—it produces `<img src="/_next/image?…">`?
@zachleat Sorry, the markdown muddied the waters. I have it configured so that markdown images go through the next Image component, whether I use an <img/> tag or a markdown image, but that isn’t necessary.
If you take the Markdown out of the equation, I’m just saying you can use the Image component and it will work, whether you export or serve dynamically. And the only change you need to make to your app code is turning off image optimization.
@alannorbauer ah, I’m getting closer! So when image optimization is turned off (in this example)—what markup is produced?
@zachleat You can view source on this guy: https://alan.norbauer.com/articles/disable-source-maps to see
(Sorry, on my phone atm)
@alannorbauer ah this is why I’m confused! In this example it’s still running the static image through the next image service, is it not?
e.g.: <img alt="Screenshot of the Firefox debugger with source maps off" src="/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fsource-map-example-tooltip-off.0d067dde.png&w=3840&q=75"/>
@zachleat Well, I believe I was mistaken. When I export I can see the exported image file but it isn’t used. The Image component points at an image service. A test with `npx http-server out` shows my images don’t load. I don’t know what I was thinking suggesting that _anything_ in Next worked.
@zachleat This is actually why I was worried when Astro started supporting dynamic sites. I thought they were going to lose focus on the SSG side of things, but so far that hasn’t happened. (I’m one PR away from happily switching to Astro - https://github.com/withastro/astro/compare/main...altano:astro:image-middleware)
@zachleat I'm still not sure what Vercel is trying to solve except lock customers in to a ecosystem they will just keep deprecating
Honestly an Astro, 11ty, or even Express + template library - inside a docker container - is a much better solution.
@tanepiper lock-in is definitely part of the strategy.
