Nuxt Vision for 2023

[danielroe]

This past year has been an exciting one. Looking into the new year, there is a lot we have planned as a team and we'd love to share it with you. ✨

• ✨ Full article
• 🐦 Tweet

[maximedaraize]

Concerning the The New Release Cycle mention in the article. Will there be a project inside the Nuxt repo the follow the progress of those releases?

[vanling]

👀 No pressure 😉 but looking forward to the Nuxt vision 2024 👀 Been an amazing year for Nuxt <3

[kaikaibenkai]

2024 is coming ✨ Thanks Nuxt Team, Nuxt 3 is great!

[martinszeltins]

Looking forward to the 2024 vision also 🚀

[jackmahoney]

Please do not release v4. The v2-v3 break was too traumatic for some organisations and many devs I know lost faith in Nuxt or jumped to React because of it. My business depends entirely on Nuxt2 and the project to upgrade to v3 has caused a lot of extra work and cost for no noticeable benefits for end users.

• All our nuxt2 page routing and middleware was suddenly unsupported
• All our nuxt2 UI libraries are abandoned
• Our Vue2/webpack plugins and now worthless

Please be a reliable, dependable choice for small teams and maintain long term v3. You should not be releasing breaking changes every year! The plugin and ecosystem churn is absolutely brutal and will result in more developers abandoning Nuxt. You seem to be favouring new developer experience over your core users that have been here for years and now suffer under your changes that seem to be made on a whim.

For instance:

• Why did you need to change the way dynamic routes are handled in v3? _id -> [id]. Why was it worth creating a breaking change for this?

I can't finish this because it makes me too depressed thinking how much longer we still have to go on v3 migration and knowing that all that time is wasted as it doesn't deliver anything to our customers. And then I learn that v4 will be coming soon... you guys have to be joking.

[martinszeltins]

@jackmahoney Nuxt 4.0 won't have any new features, only small, careful breaking changes with smooth upgrade (from what I heard @danielroe say). I don't think it is fair to never have any breaking changes in a project, that is not realistic or good for the project's future. How will we ever innovate without any breaking changes?

[jackmahoney]

@martinszeltins thanks for your considerate response. You are right that breaking changes are occasionally needed but I believe the rate of change needs to be balanced with the needs of the library consumers. I'm worries about another gruelling upgrade path and wanted to raise that. I believe a strongly defined API that does not change is vital for the success of a framework. Consistency allows a strong ecosystem to grow. Many plugins and libraries were left abandoned after v3 changes. I don't want to see that happen again with v4. See what spring boot has done with their release cadence. Major versions are a very rare occurrence and one never has an issue with dependencies or deprecations.

[manniL]

My response in #26780

[jackmahoney]

Thank you