Hacker News new | ask | show | jobs
by Kevcmk 1159 days ago
Vercel is deceitful.

The Image/img fiasco really pulled the covers off for vercel for me. I have migrated all my work off of the platform.

NextJS’ lint strategically dissuades you from using the img tag in favor of the NextJS Image component. If you make the mistake of heeding this advice and migrating to it, you can’t use static site generation—which means you are stuck using their hosting.

Here’s one of the most PR-shameful threads I’ve ever read in OSS:

https://github.com/vercel/next.js/discussions/19065

7 comments

Lol, silently* replacing the original request with the company response instead of documenting it in the docs is certainly a move. Nice to have all the thumbs-up and heart reactions on the "sorry we don't do it", for sure. Love the "We'd love to hear your feedback" and then locking the discussion too. Not having the feature is one thing, but why not properly document that and the (by now existing) workarounds?

* yes, not 100% silent, there is a small gray indicator from Github that it has been edited, but one would not expect a full-on replace with that.

Ugh.. that is sneaky
The edit history / indicator doesn't show up on mobile, but I confirmed it shows up on Desktop; leerob hijacked the question and replaced it with PR.

Deceit is indeed the right word to describe Vercel's behavior.

You are talking about exporting app more precisely, which outputs a bunch of HTML files (vs using SSG for only some pages). You can keep the Image tag around very easily, there is an option to treat it as normal img tag, so no it doesn't block exporting, and I've tested it to confirm. Use an environment variable to enable or disable exporting. Edit to add reference: https://nextjs.org/docs/api-reference/next/image#unoptimized
The last comment by @leerob which comes 2 years after the issue was opened, saying "we hear you" and "up-voting the issue is the best way for us to track that" just shows how empty their statements are, devoid of any intention do something about it. Very unprofessional behavior.
Can’t you adjust your config to serve the images using your own cdn with the Image component? By default maybe it’s vercel-friendly, but I recall it being trivial to adjust to use any other path instead.

Has this changed?

You could also modify the linting rules to exclude the Image rule.

Not saying vercel is awesome. I no longer use their products. I just didn’t find this particular matter to be problematic.

Yeah the "next/image" has always bothered me, I suspect it's a huge revenue stream for them

My advice is to just turn off the linting errors by adding this rule to ".eslintrc.json", like this:

    {
      "rules": {
        // Other rules
        "@next/next/no-img-element": "off"
      }
    }
I haven't used the Image component but I've hosted a Next.js project. leerob's comment said "To clarify again, you do not need to use Vercel for optimizing images. It works using next start or any loader of your choice.". This implies that it would still work in SSR using any hosting method, it doesn't mean you're forced to use Vercel's hosting services.

There should be a warning that it won't work with SSG and is only for SSR, but there are also many features on next.js that are SSR only.

You don't have to use their hosting. I use their NextJS Docker container on Hetzner and it works just fine.
Does the <Image> tag work with the docker container? GP's issue is with how vercel was pushing the <Image> tag a lot yet it doesn't work when in static site generation mode which is used by a lot of people.
It doesn't work in SSG, no, but it works in SSR just as if you hosted on Vercel itself. That's what I do, SSR instead of SSG, because for my app the distinction is unnecessary if I'm hosting it myself.
You can disable it to make it behave like an Image tag https://nextjs.org/docs/api-reference/next/image#unoptimized It works, it's just not optimized, that's not the same thing.
It's 2023 what kind of plebeian is using raw image tags? NextJS's OSS design is exactly what it should be, I want the image tag. I don't want Vercel boxing me into a choice:

  1. Serving images over Node.
  2. Using Vercel.
I also don't want to eject code that is sitting right there in the repo. And I don't want to maintain a fork of a homebrew reimplementation of it.
I didn’t know they have a Next.js Docker image. Why do we specifically need theirs? I roll my own based on node:lts-alpine via GitHub Actions and push it to my Docker registry on GitHub.
You don't but it makes productionizing easy, I just have to pull their latest image for every build and it should work, since it's their official image.