Hacker News new | ask | show | jobs
by karaokeyoga 2562 days ago
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.

4 comments

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 :)"

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.

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

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.
very significant indeed! thank you
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.
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.