[andrewingram]

I don't buy the vendor lock-in argument here. The vast majority of your code will have nothing Next-related in it, this is a sharp contrast to a lot of the other options out there. Your page entry points will have getInitialProps, but that's actually a pretty decent pattern I'd probably choose to keep even if I moved away from Next.

The reason we actually went with Next is because it's relatively easy to drop if our needs diverge.

[midway]

Of course there is a lock-in. Every lib you use locks you in. You don't know how many libs don't play well together. The more code and libs you add to your app the more complexity.

It's not hard to write code, it's hard to keep code complexity low and maintainable and IDK if Next.js helps here.

[andrewingram]

Yes, all libs give you vendor lock-in, which means unless Next is a particularly egregious example, there's not much point calling it out as a particular wart. My argument is that it's closer to the opposite, because as far as web frameworks go, Next does this better than most -- very little of the code you write is different just because you're using Next, your code is just normal React code. This is a huge contrast to something like Gatsby, where the lock-in is much stronger.

[midway]

Sorry but I disagree. Just take any of your a bit bigger React projects and transform them to Next or the way around. In. One. Hour. And production-ready please. Good luck, man (this is vendor lock-in).

[andrewingram]

If your threshold for vendor lock-in is one hour, there's no point discussing this. But I could probably do it in a day or two, which is good enough in my mind.

[ricardobeat]

I actually just did this a couple days ago (from Razzle to Next), took around two hours mostly fiddling with updated dependencies. Will take longer for a complex app but the lock-in is way weaker than traditional frameworks.