I agree. I was a little disappointed to see resources going towards this. It feels like they're seeking ways to create vendor lock-in, which my team fairly aggressively avoids. Next has generally been great about this, and part of the initial appeal. It's just React components inside of an easy-to-understand framework.
This, though - my instinct is to stay away from it, personally. It doesn't seem to be their wheelhouse and it doesn't necessarily make Next.js better.
I had this same reaction to next/image. I see where they're going with it though. They're obviously prioritizing e-commerce publishers because they tend to have high traffic, semi-static content, and a clear business use case for fast websites. They are also the most likely to pay Vercel to host their sites.
As long as features like next/image and "live" remain opt-in and don't otherwise affect build/dev times, I have no problem with Vercel targeting a lucrative market. Anyone who relies on Next should want Vercel to be a long-lasting company.
Besides, this is the first release of "live" – I can see this workflow becoming appealing to marketing and design teams. It's good practice to separate your marketing website from your application, so why not use "live" to enable non-devs to edit it? That's what Jamstack is all about – empowering the marketing/copywriting/product teams to edit content in real time. Maybe "live" is simply the next logical step of Jamstack – teams of non-devs editing the code and design of websites as easily as they can edit their content.
Developers should be all for that, even if they aren't the target audience of the live features. Reducing friction between dev and non-dev is a win for everybody. Marketers are happy because they can edit content without waiting on devs/deploys, and devs are happy because they talked the non-devs out of using WordPress, and got to build a new site with a hot technology.
I wonder if Vercel considers Automattic a competitor. The "percent of the web" stat is a juicy KPI to compete for.
I personally can’t see any benefit of allowing non-devs near code. Personally, any time I’ve seen clients / non-devs near code (or non-content / admin / HTML / CSS type things) that’s when things go bad and I have have to fix things.
I’d be interested to see how this would work in practice but I’m skeptical at the moment.
Vercel being a profitable entity is what encourages them to continue supporting Next.js. It's a fine line. The product has to be built in a way for free users to easily pick it up without any immediate, tightly-coupled unavoidable lock-in. Safe to say, if you're depending on Next, you do want Vercel to win.
Great point, and you’re right – I do want to see them succeed. I suppose I just hope success doesn’t end up impeding the framework. As it is we happily pay for staging on their infrastructure, so we don’t have any issues with supporting their efforts monetarily. Hopefully that clarifies my concern better.
I haven't tried deploying it to a serverless platform personally, but surely it's no harder than anything else to spin up on a normal Node server on eg Heroku?
This, though - my instinct is to stay away from it, personally. It doesn't seem to be their wheelhouse and it doesn't necessarily make Next.js better.