Function-based component API (extended discussion)

[wspl]

I used Vue on almost all projects, and even migrated a React project with 100k+ of lines of code to Vue. So I am also a user who loves Vue very much.

The reasons why old Vue is so attractive to me and why new changes make me depressed are listed as follows:

• If I want to implement a certain logic, there is usually only one way. I can start working right away without extra thinking. However, in future versions, it will make people harder to choose in the use of legacy APIs or new APIs. I don't think this should happen when using a framework.
• Code organization is easy, even for a team of 100+ of people, the code written will not be much different. Because object-based (or options-based) component definitions constrain the location and implement method of logics of the component. But the function-based component definitions which providing freedom for developers, but also brings uncertainty and lower readability (I need to find in setup() where a value is, where a method is, and which fields are computed, whether a field named isEnabled is value or computed).
• Based on these advantages, Vue can be learned very quickly. I don't need to be familiar with JavaScript's syntactic sugar or future features to be able to produce with Vue. However, after losing these advantages, it is hard to say that Vue will be a friendly framework. It is more like a project that has been constantly disturbed by the React community and has lost its own characteristics.

The steepness of the learning curve, the readability of the code, and the possible migration costs of the old API being deprecated... these are all terrible problems.

The introduction of function-based APIs has brought about tremendous changes. In a sense, this can be considered a new framework. After all, if the object-based API are deprecated, almost all Vue plugins have to rewrite, and the plugin author should also consider providing Vue 2.x compatible. Not only did the Vue project have a division, but its plugin ecosystem also split.

So I think the Vue team can consider learning about Express and Koa, separating a new framework from Vue to serve high-end users who really need these new features.

Even if the function-based api really becomes mainstream, I won't give up using Vue. Because SFC is the most important feature of Vue for me. But based on my short work experience on WeChat(Tencent), this change will really affect my colleagues (C++ developer) who write web pages in Vue. Because they don't have the energy and time to systematically learn JavaScript syntax and best practices. Everyone just wants a tool that can produce projects quickly.

(Please forgive me for my broken English, it is not my native language, so this is a bit difficult to read. But I am still very eager to express my thoughts.)

[yyx990803]

I think most of your arguments have been addressed in this reply.

[jonaskuske]

(I need to find in setup() where a value is, where a method is, and which fields are computed, whether a field named isEnabled is value or computed)

With the current API, you need to figure out whether isEnabled is a value or computed so you can find it, because they are in different locations.
Then you need to find where a related method is, because it it somewhere further down the file, between other methods doing completely unrelated things.

With the function-based API, you just need to figure out "what is this code doing", get to that part of setup() and everything will be right there – isEnabled can be there no matter if it's a value or computed, the respective methods can be right next to it, no searching necessary.

You probably use Single File Components, instead of putting all the <script> sections of your components into one folder, the HTML template into another folder and the styles in a third. Precisely because grouping things that are related and have the same concern makes for better ergonomics.

All that said, if you want to group by type, the setup() API is flexible enough to allow for that.