> NextJS

There is well-hidden vendor-lock when using NextJS, at least.

that’s a bold claim, could you give an example?

Probably the most known example https://github.com/vercel/next.js/discussions/19065

It is not an issue if you host in Vercel.

Implementing the requested feature would make the framework much better and easier to use when self-hosted elsewhere. But there is neglection to resolve the issue. This is just one case.

FWIW, we host on Cloudflare and use their API to resize images on the fly and we're fine. Not so much a "lock-in" if other vendors can fill-in, is it?

You likely needed to do more extra work than needed, when compared to some other options.

The lock-in here is the added developer time and complexity vs. just paying premium.

I disagree with your threshold for what makes something a lock-in but I admire your ideology of less friction in portability

What API do you use to resize images? Cloudflare? I know Vercel and NextJS have an <Image> resizing/optimization component that gets pricy.

Yes, Cloudflare through the `loader` prop in `Image` component.

See CF docs for what the url should be https://developers.cloudflare.com/images/transform-images/tr... Next.js docs should tell you how to write the loader

If you need to change it when switching vendors and only they offer it/it's proprietary, it's vendor lock-in.

There is no vendor lockin with nextjs

There is no explicit vendor lock-in, but features of the framework are designed heavily towards Vercel-specific features.

The SST team actually has an open-next project[1] that does a ton of work to shim most of the Vercel-specific features into an AWS deployment. I don't think it has full parity and it's a third party adapter from a competing host. The fact that it's needed at all is a sign of now closely tied Next and Vercel are.

[1] https://github.com/sst/open-next

Simply put - if you want get the best out of the framework, you need to host it in Vercel. Otherwise, there are better options for frameworks. No need to ”fight it”.

You will find many issues from GitHub which are not considered because they would make the framework ”better” or easier to use on other clouds.

Making things worse in a free offering by a company to profit from premium offerings by the same company its the pinacle of capitalism, reminds me of a recurrent joke I have with a friend while playing Call Of Duty, that they will get greedier and soon will sell not only character's skins but also shaders/textures for the maps, oh so you want to see something better than placeholder textures? We have the DLC just for you!

More likely outcome: ads on static textures and between lobbies, oh but you can pay to turn them into _theme of the week_.

Don't give them ideas...

Environment destruction gameplay but there's always another ad under the ads, except when it's a lootbox.

I can imagine worse, too! They haven't even really started turning that knob yet.

The Video game metaphor stretches pretty far.

Madden has a monopoly license for NFL content. For a decade the biggest complaint was how they gate kept rosters behind the yearly re-release. Eventually they allowed roster sharing but they put it behind the most god awful inept UI you could possibly imagine such that practically casual gamers wouldn't bother with it.

Then Madden came out with Madden Ultimate Team (like trading cards MTX) and have been neglecting non-MUT modes ever since. They don't explicitly regress the rest of their game, they just commit resources to that effect.

Its like malicious compliance. They don't embrace, extend, extinguish, but they get a similar effect just with resourcing, layoffs, whatever.

>there are better options

Do you mind naming some NextJS alternatives without potential vendor lock in? Mulling a change in my fe.

For example, Remix has got a lot of traction recently. It is also backed by Shopify where the business model does not conflict.

https://remix.run/

I’m sure they are influenced by the likes of Reddit and Twitter rewriting their stack. I mean, that’s what has to be done, right? /s

Is there a trend there of moving from Next to FastAPI? I would be surprised.

Perhaps they are doing some AI thing and want to have python everywhere.

My guess, when I read it, was this would permit them to independently scale the backend on some commodity capacity provider, and then their Nextjs frontend becomes just another React app. OP didn’t mention what their product was, but if it’s AI-adjacent then a python backend doesn’t sound like a terrible idea.

Or if you really want to rewrite your back end, why not just use Express? It would be wildly quicker to rewrite than switching languages. That along with the article makes me question the competency of the company. They got customers, sure, but in the long run these decisions will pile up.