The article kindly phrases the alternative as “use a framework” and links to a page that has only one actual framework: NextJS.
I don’t support React pushing a wholesale shift to NextJS as a starting point for every project, given it’s mostly directed by a single private company (Vercel) that have positioned themselves as the default deployment platform for NextJS apps, publish the documentation, and do not shy away from claiming it as their own.
It has become extremely difficult to distinguish between NextJS features that are community-driven vs profit-driven e.g. api route functions (putting your backend in your React project, so now you will pay them for compute) and NextJS image optimization (famously expensive, and NextJS literally throws warnings if you don’t use it).
On top of that, NextJS doesn't even support the <Image/> component (and thus all their image optimization) when exporting to static output (unlike Gatsby). So you will be pushed even closer to pay them.
In your very link you can see that you can only add a handle to a third party loader. Their built in image optimization that works in vercel does not if you static export and host elsewhere.
If you do a static export, you don’t have a server to optimize images. It’s just a bunch of static files. The only way to optimize the image is to point to a service through the loader.
Also, the image optimization on the default Next.js server, for example deployed to a $4 VPS, also works without Vercel.
Next should have the same functionality that Gatsby had when doing a static export: pre-optimised images for different breakpoints that are created at build time. That would be a truly portable solution.
that is simply not true, there are static export, 3rd party image optimizers [0] (that re-use <Image />) - just vercel does not care about theirs for static export. Also, look at how gatsby does without cloud/server hosted images.
Vite is the replacement for CRA, I usually create new projects with their preact-ts template. Its very fast and just works. I would personally strongly advise against nextjs, but use whatever you prefer.
I don’t support React pushing a wholesale shift to NextJS as a starting point for every project, given it’s mostly directed by a single private company (Vercel) that have positioned themselves as the default deployment platform for NextJS apps, publish the documentation, and do not shy away from claiming it as their own.
It has become extremely difficult to distinguish between NextJS features that are community-driven vs profit-driven e.g. api route functions (putting your backend in your React project, so now you will pay them for compute) and NextJS image optimization (famously expensive, and NextJS literally throws warnings if you don’t use it).