feat(create-vite): default to metaframeworks

[patak-dev]

Description

create-vite was initially a tool to scaffold barebones templates to try out vite with your preferred framework. We dodn't even have linting in templates. We only added eslint to React after discussing with @gaearon. And we pushed users to use other tools to start a production project, for example, in the Vue ecosystem, create-vue has a CLI with options to add testing and a lot of other features you would expect in a proper scaffolding tool.

Now that several framework options have metaframeworks, and they have reached stable versions using vite, if create-vite is going to be used mainly by people looking to start their next application and not a bug reproduction, then it makes sense to push the metaframeworks up as the first option so they are taken by default by users. This PR implements this idea, proposed by @gaearon here.

Note: the React Router v7 default template needs to be a bit leaner, as right now it includes files for docker and bun that may confuse new users. @markdalgleish said they are working on this, it is just part of the transition from Remix.

[patak-dev]

From Rich:

makes sense. Though it will increase the demand to make SvelteKit more client-only-SPA friendly for the people currently using create-vite specifically to avoid Kit...

[bluwy]

if create-vite is going to be used mainly by people looking to start their next application and not a bug reproduction, then it makes sense to push the metaframeworks up as the first option so they are taken by default by users

I'm not sure about this. Why is create-vite going to be used mainly for building applications and not repros anymore? The templates are also decent SPA setups that can be used to build apps just fine.

For me these external CLI links give options and visibility to users of alternative setups. Once they know of the metaframeworks already, they'd have execute their CLIs directly instead of going a roundabout way to execute it through create-vite.

[patak-dev]

if create-vite is going to be used mainly by people looking to start their next application and not a bug reproduction, then it makes sense to push the metaframeworks up as the first option so they are taken by default by users

I'm not sure about this. Why is create-vite going to be used mainly for building applications and not repros anymore?

This is an important question. Maybe we could do a survey to try to understand the current users split. My assumption is that we have way more passive users than people creating reproductions.

The templates are also decent SPA setups that can be used to build apps just fine.

Yes, and we wouldn't be removing them. But when somebody asks me how to build their next production app with Vite, I recommend them to go for a framework powered by Vite. I think pushing users to use our barebones examples by default isn't doing them a favor. It does though if they are trying to learn Vite though, and we can better document that use case (again, this would depend on who is using create-vite, someone trying to learn vite or someone building their next app).

For me these external CLI links give options and visibility to users of alternative setups. Once they know of the metaframeworks already, they'd have execute their CLIs directly instead of going a roundabout way to execute it through create-vite.

I agree with this, but it still holds no matter if the metaframeworks are in the first spot or in the last one.

[bluwy]

I think it boils down to how we see create-vite. For me, it's a CLI to create projects with Vite itself. The templates are barebones to showcase just that and nothing more. We don't target passive users or repros, or we intend for the template to be "production-ready", it's only a Vite project example setup.

If we move the metaframeworks up, or if we try to target a specific demographic (passive users), then create-vite becomes a gateway to build Vite-powered apps. The barebones template no longer feels like the focus and are more like alternatives. The order definitely has an impact on what we prefer the user to be picking.

The name create-vite implies creating a Vite project and I'd prefer if it's still focused on projects using Vite itself. External links being "you can also use these vite-based metaframeworks". Our CLI is bundler-focused, while metaframework CLIs are UI framework-focused.

But when somebody asks me how to build their next production app with Vite, I recommend them to go for a framework powered by Vite. I think pushing users to use our barebones examples by default isn't doing them a favor.

I don't think there's anything wrong with pushing them to go for a framework powered by Vite. We also don't have to push them to use our barebones examples. They should use whichever framework or CLI that fits their needs.

[patak-dev]

I'm started to think we should modify the docs to be more clear about create-vite scope, and then add another top option (maybe "Ecosystem") that has all the fullstack frameworks in the same way we have Others now, that list them all together. We can also include Astro in that way. And the name is generic enough for letting us even add other tools in the future.