71–80 of 83 posts
Earlier quoted context omitted.
I actually love Nuxt. If you want all the fullstackness of Next, but without having to deal with React, it's perfect.
The "without having to deal with React" bit is crazy important. I also think, even if Nuxt supported React, its overall architecture is just better than Next's. Everything just seems to plug together better.
Earlier quoted context omitted.
Could you expand on this a little? Specifically, how do you think "Embrace, extend, extinguish…" could apply to this situation?
Vercel's playbook with Next so far has been to make convoluted features that exist solely to pad out how much people spend on hosting costs. They also make sure that hosting it anywhere but Vercel comes with footguns, even though theoretically you can host your Next app anywhere you want (and it's gotten better recently solely because of backlash). See https://opennext.js.org/ for example. They've been so successful…
Earlier quoted context omitted.
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 ap…
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".
[0] https://docs.astro.build/en/concepts/islands/#server-islands
Earlier quoted context omitted.
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 framewor…
Earlier quoted context omitted.
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 th…
Earlier quoted context omitted.
Could you expand on this a little? Specifically, how do you think "Embrace, extend, extinguish…" could apply to this situation?
Vercel's playbook with Next so far has been to make convoluted features that exist solely to pad out how much people spend on hosting costs. They also make sure that hosting it anywhere but Vercel comes with footguns, even though theoretically you can host your Next app anywhere you want (and it's gotten better recently solely because of backlash). See https://opennext.js.org/ for example. They've been so successful…
has that happened with Svelte?
> they now have a monopoly over the most popular frontend meta frameworks (Next, Svelte/Kit, Nuxt, Astro)
this would be a surprise to the Astro team!
Earlier quoted context omitted.
Vercel's playbook with Next so far has been to make convoluted features that exist solely to pad out how much people spend on hosting costs. They also make sure that hosting it anywhere but Vercel comes with footguns, even though theoretically you can host your Next app anywhere you want (and it's gotten better recently solely because of backlash). See https://opennext.js.org/ for example. They've been so successful…
> I have no doubts they'll do the same with Nuxt, demanding they implement features that solely exist to pad out hosting costs while providing next to no actual benefits to end users and devs has that happened with Svelte? > they now have a monopoly over the most popular frontend meta frameworks (Next, Svelte/Kit, Nuxt, Astro) this would be a surprise to the Astro team!
Yes. There are features that have been deliberately kept on the platform level to force you to use the platform instead of implementing it on the framework level or guiding you through it with the docs.
Earlier quoted context omitted.
> I have no doubts they'll do the same with Nuxt, demanding they implement features that solely exist to pad out hosting costs while providing next to no actual benefits to end users and devs has that happened with Svelte? > they now have a monopoly over the most popular frontend meta frameworks (Next, Svelte/Kit, Nuxt, Astro) this would be a surprise to the Astro team!
> has that happened with Svelte? Yes. There are features that have been deliberately kept on the platform level to force you to use the platform instead of implementing it on the framework level or guiding you through it with the docs. https://svelte.dev/docs/kit/glossary#ISR
Earlier quoted context omitted.
> has that happened with Svelte? Yes. There are features that have been deliberately kept on the platform level to force you to use the platform instead of implementing it on the framework level or guiding you through it with the docs. https://svelte.dev/docs/kit/glossary#ISR
ISR _can't_ be implemented at a framework level without tying the framework to the platform. The fact that we instead chose to implement it via a platform-agnostic adapter API surely demonstrates the opposite of what you're implying