Hacker News Reader

Comment by aosaigh | Hacker News Reader

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.

View on HN

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.

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

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...

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"

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/

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

I think that you should substantiate your claims instead of making low effort comments with zero elaboration. I've cited relevant passages from Astro's docs and I realized that it offers me the features I'm looking for, so I'm not sure what you're on about. Here are the "Key differences between Nuxt and Astro"[0] according to the docs:

- Nuxt is a Vue-based SPA (single-page application). Astro sites are multi-page apps built using .astro components, but can also support React, Preact, Vue.js, Svelte, SolidJS, AlpineJS, and raw HTML templating.

- Page Routing: Nuxt uses vue-router for SPA routing, and vue-meta for managing <head>. In Astro, you will create separate HTML page routes and control your page <head> directly, or in a layout component.

- content-driven: Astro was designed to showcase your content and to allow you to opt-in to interactivity only as needed. An existing Nuxt app may be built for high client-side interactivity. Astro has built-in capabilities for working with your content, such as page generation, but may require advanced Astro techniques to include items that are more challenging to replicate using .astro components, such as dashboards.

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

https://nuxt.com/docs/getting-started/server

Nuxt is a server-side JavaScript framework with a complete HTTP application stack, built on top of Nitro (which includes an even larger suite of capabilities) and H3.

https://nitro.build https://v1.h3.dev

Astro is markup generation.

They are only comparable in that "both can print markup".

The idea that Astro and Nuxt are only alike because they "print markup" is factually incorrect. Astro is designed to give you the same flexibility as Nuxt when it comes to building dynamic, server-rendered sites. One can even use React or Vue within Astro. You can create API endpoints, use SSR, and even define backend functions with type-safety. The migration guide from Nuxt to Astro makes it clear that both frameworks support similar workflows, from file-based routing to dynamic data fetching. Astro’s islands architecture[0] just means you get more control over how and when interactivity is delivered, but under the hood, it’s every bit as much a server-side javascript framework as Nuxt.

[0] https://docs.astro.build/en/concepts/islands/#server-islands

If Astro is "designed to give me the same flexibility" it fails to do so in hilarious ways.

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.

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.

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

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

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.

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

Reply on news.ycombinator.com