[freedomben]

This is what has made me hesitant to really invest deeply in Next.js. It's just too familiar where some open source project starts. Later it attempts to monetize. Some feature in open source makes it so new monetization thing (usually cloud functionality) isn't needed, so those feature(s) get downplayed, neglected, and eventually deprecated, often with self-fulfilled prophecy/declaration of "nobody is using those" (because they were engineered that way, but that inconvenient part is never mentioned and rarely acknowledged). It's one thing not to invest in unprofitable features (that's understandable for a for-profit company), but making them difficult or more obscure to use is often a part of this pattern.

I'm not saying Next.js is doing that with static export, but I'm not sure they aren't either. It fits the pattern too well. I'm still suspicious about how the Image implementation (which nearly every website needs) breaks `export` and the only solution is "roll your own image handler." I'm not sure if that fits into the understandable lack off investment or the intentional difficult/obscure.

[leerob]

We've made quite a few improvements to the static export with the new App Router, including support Server Components, Route Handlers, i18n routes, and more. Definitely still being invested in. My comment about documentation debt is that the entire information architecture of the Next.js docs needed some work. It's being fixed and will be stable soon.

You can read more about how to use Image Optimization with a static export in the new docs: https://beta.nextjs.org/docs/configuring/static-export. There's a full example there with Cloudinary, but you could use any service you want.

[freedomben]

Nice, thanks for the link. Those new docs do look great!

I wanted to note that I'm not asking you to build this, I'm more sharing my use-case in case it's helpful feedback.

What would really be amazing for me is a build-time image processing pipeline. Any images I use for the static site are already present in the repo (none are user-supplied or come from object storage, etc). Since all the image info is present at build/export time, it would be amazing if the image processing were done locally during the build and then the next/Image tags would instead of invoking server-side code, generate the static <img> code necessary to reference the different versions (such as srcset, sizes, etc)[1]. There is at least one open source project to do that, but at least when I last tried it, it was essentially dead on the vine. I searched around but couldn't find any solutions, which was pretty disappointing. I did end up shipping the app and just manually pipelined those images and hacked out the <img> tags instead of using the component, but if I had more than a handful in the site that wouldn't scale too well.

Anyway, thanks for what you've done with next.js! it's really an incredible project and you've been an important part of moving the web forward.

[1]: https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...

[tmpz22]

And they've raised at least $313 MILLION! Where have we seen this story before?

[1]: https://www.crunchbase.com/organization/vercel