[EvanYou]

Vue team lead here.

There is a lot of FUD in this thread so we need to clarify a bit:

- This API is purely additive to 2.x and doesn't break anything.

- 3.0 will have a standard build which adds this API on top of 2.x API, and an opt-in "lean build" which drops a number of 2.x APIs for a smaller and faster runtime.

- This is an open RFC, which means it's not set in stone. The whole point of having an RFC is so that users can voice their opinions. It's not like we are shipping this tomorrow.

For more details, we added a Q&A section at the top of the RFC to avoid further confusions: https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs...

[karaokeyoga]

I just wanted to point out a significant change made to the above document today.

Earlier today, there was a "Standard" build and a "Compatibility" build.

The "Standard" build excluded support for "data", "computed", "methods", "watch", "provide/inject", "mixins", "extends", and all lifecycle hooks.

In the updated document, the old "Compatibility" build became the "Standard" build, and the old "Standard" build became the "Lean" build.

[boubiyeah]

Not sure why Evan is not being more transparent regarding this renaming.

It would be easy to just say "yes, I got a bit carried away with the naming and my big future plans, but the community reaction made me realise perhaps it was not a great idea"

Insead he's like: "what? it was the plan all along :)"

[gustojs]

That's partly my fault. Evan focuses on more technical sides of things but there are people in the team that focus more on the community aspect and we didn't catch that potential naming issue and the whole message that the RFC gives away.

We're all still learning how to work with the RFC documents. We want them to be an important tool for the community but initially, the response from the community was very low. Paradoxically this whole situation made the wider community aware of those RFC documents so hopefully it will go in a good direction. But that initial low response made us believe "oh we have time to sort out things like the phrasing". Turned out it was wrong.

The advice to change the names came from the community and it was a good one. It got support in the core team internal channels and got implemented.

[dessant]

> Compatibility

That's a clue for where the Vue team's mind is regarding the current API. Compatibility to me reads like legacy. That's in contrast with the claims above that this is just a new optional API to serve a broader range of use cases.

[gustojs]

This is a phrasing issue. In the team we use the compatibility word all the time in the "it's a good feature proposal but what about compatibility" context. For us this word had a positive conotation and we missed the fact that it can be treated in a different way. That's a good lesson for the future.

[swyx]

very significant indeed! thank you

[andrewprock]

The one option obviously missing is the "Production" build, which ships the 2.x API without any of the fancy new stuff that people don't want.

[gustojs]

With Vue 3 we're introducing tree-shaking of individual Vue features which will get rid of unwanted

The "production" build will ship with the stuff that particular project uses. That means both what they use in their codebase and what Vue uses internally to handle that code.

But there also has to be a way for Vue to understand what the user wants to be in the bundle. This is easier for the users who use the new syntax, where the individual features are explicitly imported.

[dfabulich]

May I request an addition to the Q&A section?

"This API is so different, shouldn't you rename the project?"

Scroll down in the comment threads here and you'll see this question raised over and over again; I think it's fair to say that it is "frequently asked" and belongs in a FAQ.

[conta]

I would love to see their answer to this but my guess is that it would be: "Nope. See Semantic versioning (semver.org)"

[seanlaff]

Evan I think this is a great experiment. React hooks was an interesting idea and I like how Vue’s approach feels even more reactive (a la observable.com)

There seems to be an overall trend towards more reactivity and I applaud Vue for taking a creative approach to that. Will it stay, and become the da facto paradigm to do webdev? Only time will tell, but I don’t think we should be afraid to experiment with it.

The Vue team have always been excellent stewards of the project. I’m sad to see so much negativity here :(

[kabes]

It kind of reminds me of Meteor's Tracker reactivity system more than react hooks. Since you used to work for Meteor for a short while, how would the 2 compare?

[tshannon]

I don't get all the negativity. From a typescript perspective, this looks like a breath of fresh air compared to the component based API.

[hinkley]

And people are voicing their opinions. Hope you’re taking notes