gustojs

I'm sorry to hear that. The class API will still stay with us though, even the current plugin solution will work better thanks to Vue internals rewritten to TypeScript. It won't be as good as the function API, but during the works on a native class API we realized there are problems with classes API that even a native solution wouldn't solve.

The class API will remain the current status of an add-on. The idea was that if we make the class API built in to the core, it will somehow be better than now and remove all the issues with it. More and more into the game it was turning out that's not that easy.

Even the decorator thing was problematic. Remember that the core Vue library is supposed to work both with and without build tools, but in case of TypeScript it's not possible. There is a decorator proposal for JavaScript but it works differently than the TypeScript one so there would be a clash.

In the meanwhile we found out a new solution that not only solves these but also some other problems (composability).

Making it two separate project means the library authors have to write two separate libraries using two separate API - the more flexible and easier to maintain (written among others with library authors in mind) function API and the object API that they often have to fight against right now.

That would be a huge problem. Right now they can just use the API they want and it will work for all the users regardless if they use objects, functions or classes.

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.

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.

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.

One of the biggest advantages of the function API is the flexibility it gives for the library authors, making them more powerful and much easier to maintain, so instead of fighting against the API they will be able to focus on new fancy features, better documentation or community support.

This gain will be visible for all Vue developers regardless of which API they use because we all want to have the best quality libraries in our ecosystem.

Only in the first world clients pay enough for such a team to make a living. Not a case for other countries.

I don't see an issue of learning Vue and not being able to write native apps for iOS and Android as a valid one.

Weex quickly gets better and is maintained by Alibaba, a company of the same scale and with development resources comparable to Facebook or Google. NativeScript recently started work on Vue port, the project is already available for testing. That's excluding the Cordova solutions like Onsen and Framework 7 having official Vue ports.

To that, PWA slowly becomes the new trend for mobile development, native apps are not necessarily the optimal solution to every use case.

The "++ many more in the future" is an optimistic assumption. As much as I wish it to be fulfilled, same can be said about any other framework.

Vue is widely praised for its official documentation, often pointed as one of things differing it from React. But if you have other experience, I'd kindly asked you to mention the places you remember were wrong, so that I can submit a PR for them.