[egeozcan]

> Everyone else should be preparing their plan b for what happens if they impode and Next.js, Turborepo etc development fractures or grinds to a halt.

Isn't next.js too big to fail? Currently we are trying to define a modern stack for our front-end, and I always thought next.js/react to be the next java -> Perhaps Solid.js is much better (IMHO it surely is) but I probably won't get fired for choosing next.

If not, what would be the alternative? I really don't want to restart with the hassle of configuring a js project from scratch. Done it already a thousand times, and that's a thousand times too many :)

[KiranRao0]

> I really don't want to restart with the hassle of configuring a js project from scratch. Done it already a thousand times, and that's a thousand times too many :)

This is the key. For small apps, it's far more effective to pay the premium to not deal with any DevOps. Once an app gets bigger, it'll make sense to spend more time optimizing cost.

I feel like Vercel is the new Heroku circa 2015. I'm hoping it won't follow Heroku's trajectory, but who knows.

[brundolf]

It might be. It was eg a first-class part of React's Server Components design/rollout strategy

The question is exactly what would happen if it lost its backing, even if it wouldn't outright fail:

- Meta forks it and/or takes over from there?

- Multiple community forks that fracture adoption?

- Stagnation and slow decline as it stops shipping big upgrades and goes into community-maintenance mode?

[chrisco255]

Next.js is open source, forkable, and self deployable.

[satvikpendem]

Those are necessary but not sufficient conditions to having a healthy community which actually continues developing such forks, likely for free if the main company backing the original product goes away. I don't know why people think OSS is a panacea to community development, lots of things are OSS and have few to no contributors.

[chrisco255]

Honestly even the previous stable edition of Next.js before server components would be fine to peg to.

But history has shown that when a framework or backend was sufficiently popular that people did indeed step in to support it. It happened with Node.js itself (which Next is built on) a while back with what was then called io.js, before io.js eventually re-merged with Node.js after the organizational kinks were worked out.

[the_mitsuhiko]

Next.js promotes serverless deployments and in that scenario it’s not sufficiently Open Source. Vercel (or amplify) adds proprietary stuff that’s missing in next itself. There is an Open Source serverless implementation for aws lambda (open next), but it’s not official.

[re-thc]

> Isn't next.js too big to fail? Currently we are trying to define a modern stack for our front-end, and I always thought next.js/react to be the next java -> Perhaps Solid.js is much better (IMHO it surely is) but I probably won't get fired for choosing next.

There is a huge amount of difference.

Java is currently backed by Oracle, which has a huge history of staying around (setting the reputation aside for a moment).

Vercel is currently not profitable, raised too much money and is stuck trying to generate enough profit to match that valuation.

Also NextJs is relatively small in the world you compare to.

Javascript <-> Java React <-> NextJs <->

i.e. it sits another 2 layers below.

[user3113]

there is alternative for vercel though they don't have storage service they are pretty decent and they don't rely on VC money. https://www.stormkit.io/

[PKop]

Phoenix LiveView and Elixir and just run it on a server, like Fly.io

[manmal]

Is better tooling support for Elixir on the horizon? I’ve found eg VSCode code completion leaving something to be desired. With TS, I feel like IDEs have my back, but with Elixir I (as a newbie) keep getting stuck. There’s also a lack of readymade idiomatic solutions to common problems out there, requiring me to browse the Elixir forum a lot.