[aosaigh]

Honestly, this is terrible news. A number of the core team of Nuxt.js are joining Vercel and NuxtLabs itself is acquired by Vercel.

I choose Nuxt.js and Nuxt UI Pro specifically because they aren't Vercel products. I built two SAAS MVPs over the last year based on this, now I'll have to wait and see what Vercel (their competitor) wants to do with it.

[kelthuzad]

You've expressed my thoughts to a tee. I will start exploring Astro and see what the migration process is like. Many devs questioned my usage of Nuxt over Astro to begin with, so this is a good opportunity to learn.

[jt_b]

Astro is nice, but its a different model than Nuxt, more suited to static sites.

[kelthuzad]

I'm just reading the docs and it seems more capable than that: https://docs.astro.build/en/concepts/islands/#server-islands

I have also just discovered a dedicated section for the migration from Nuxt to Astro:

>Key Similarities between Nuxt and Astro

Nuxt and Astro share some similarities that will help you migrate your project:

- Astro projects can also be SSG or SSR with page level prerendering.

- Astro uses file-based routing, and allows specially named pages to create dynamic routes.

- Astro is component-based, and your markup structure will be similar before and after your migration.

- Astro has an official integration for using Vue components.

- Astro has support for installing NPM packages, including Vue libraries. You may be able to keep some or all of your existing Vue components and dependencies.

https://docs.astro.build/en/guides/migrate-to-astro/from-nux...

[etchalon]

It's only "more capable" in the sense that yes, ultimately, it's JavaScript and you can do a lot with JavaScript.

But Astro's model is "generate markup once, serve statically".

Nuxt's model is "Server-Side JavaScript"

[kelthuzad]

From a cursory reading of Astro's docs their model/philosophy seems to be more like "fast by default."

So their philosophy is to start with zero client-side javascript, even when one is using components from javascript-heavy frameworks like React or Vue. Interactivity is apparently something one has to explicitly opt-in to by adding a client:* directive, rather than it being the default.

The migration guide states, "Astro projects can also be SSG or SSR with page level prerendering," which puts it on par with Nuxt in that regard.

A difference I've noticed regarding server-side features is that Astro allows one to "define and call backend functions with type-safety."[0] which even Nuxt doesnt offer in such a convenient and type-safe manner. I'm pretty happy with what i'm seeing in Astro's docs so far.

[0] https://docs.astro.build/en/guides/actions/

[etchalon]

I think you're fundamentally missing the difference between these two frameworks.

[kcrwfrd_]

Even if you use the Astro view transitions API to make a SPA, its client side router falls short of other frameworks that are more truly SPA oriented.

[impulser_]

Vercel isn't a competitor to Nuxt. Vercel benefits from allowing any frontend framework to be deployed on their service.

All you have to look at is Svelte, which Vercel hired all the developer of, and that turned out to be a great thing. Svelte and SvelteKit are better than ever and nothing they have done since has shown to be forced by Vercel.

[codybontecou]

Vercel benefits from moving as much of the logic to the server (their paid services) as possible.

[etchalon]

Vercel benefits from not letting other, better, cheaper architectures like Cloudflare Workers get better treatment than them from popular framework authors.

[9dev]

That holds true now. Tomorrow, when they can steer the direction of all frameworks, they—and their investors by extension—might notice that Next projects generate the most revenue on average. Now they have an incentive to favor Next; not even by outright harming the other frameworks, but maybe by strategic neglect. Maybe a new web platform feature is first supported here, while integrations stall elsewhere; maybe the backlog is sorted differently; it doesn’t matter.

The point is that you’re just seeing business strategy aligned with our interest, but that can, and will, change.

[etchalon]

No, I agree in principle. Letting Vercel functionally own the roadmaps for the "best" frameworks in the ecosystem is dangerous bordering on stupid.