Sacrificing Simplicity

[ethandunford]

At this point, Vue will pretty much let you use any pattern from any framework you want. If you want Vue to look and feel like React, you can make it look and feel like React. If you want it to look and feel like Angular, you can make it look and feel like Angular. And with the new component definition API, you'll be able to make it look and feel like Lit. While this flexibility is attractive, I worry that Vue is sacrificing the simplicity that made it so attractive in the first place.

There is no clear or documented approach on the best way to use typescript, which leads to a lot of confusion as examples online are either simple and straightforward or quite over-engineered.

[posva]

Vue is sacrificing the simplicity

How did you get to that conclusion? Vue hasn't sacrificed its API

lot of confusion as examples online are either simple and straightforward or quite over-engineered.

What examples are you talking about?
Using the composition API seems to be the preferred approach for TS users but you are free to do otherwise

[yyx990803]

The keyword is "you are able to", but also you don't have to.

• Absolute majority of Vue usage is centered around single-file components.
• Composition API + <script setup> will be the recommended API moving forward, especially if you want good TS support.
• Yes you can use class components, but it's not part of the core API and only used by people who really really like classes (and before we had good TS support via Composition API).
• defineCustomElement is a purely additive API to cover a special use case (distributing framework-agnostic components). It's not going to be the default approach when you build a Vue-only app, so comparing it with Lit is inaccurate.

The Angular/Lit resemblance are never on the default path - they cover edge cases for users with strong opinions, but they don't affect typical users.

When it comes to the co-existence of Options API vs. Composition API - in a way, that's an inevitable cost when we try to introduce fundamental new ideas into the framework without breaking existing APIs. Consider the other options:

• Only keep Options API and never introduce new ideas. Long term result: stagnation, no composability (example), limited scalability, forever inferior TS integration.
• Drop old APIs and directly switch to new APIs. Result: splitting the ecosystem, angering existing users (example: Angular 2).

I don't think either of the above would be better than the current state.

The good news is that the API and DX around Composition API has stabilized, so the main focus now is to overhaul the documentation to provide a clear recommended path using the new APIs. This is exactly what we are working on at the moment.

There is no clear or documented approach on the best way to use typescript

Yes, the docs are a bit outdated in this regard. The current recommended approach is:

• Use SFC + <script setup> + Composition API
• Use VSCode + Volar (or WebStorm once its support for <script setup> ships soon)
• Not strictly required for TS, but if applicable, use Vite for build tooling.

[Jutanium]

I want to be super mindful about the awesome work that has been put into Vue 3 when I write this. I do think that there are some more points that can be discussed here, and I just want to share my experience as a Vue user in hope that they can help when thinking about those new docs!

The coexistence of Options API and Composition API is deeper than backwards compatibility or trying to introduce new ideas without breaking old ones. It isn't similar to React Hooks vs React class components, for example: you can use the Composition API in the same component as the Options API. If the recommended way forward was to go all-in Composition API, it hasn't been clear up to this point, and even with the release of <script setup> there's a lot of ambiguity and surface API complexity that come up when adopting use of Vue 3.

<script setup> hasn't been introduced as the "new way forward" - I didn't realize that until I came to this post. So for me as a longtime Vue user working on Vue 3 for my new projects, I've been presented with many options. I could use the options API just as before, including the use of mixins. Or I could use the setup() hook and the composition API just as a way to replace mixins when I need to do some composition (I call this the composition API is for composition approach). Or I could use the setup() hook as basically a way to replace the created lifecycle hook, as it functions similarly. In that vein I can also use the setup() hook to expose non-reactive/readonly data to the template, or as a more explicit way to manage template refs, and any combination of the above.

Or I could use the setup hook and basically replace the options API entirely, and stick everything in there. But why should I do that? What are the tradeoffs here, and what is Vue's position on its own Options API? So far, everything has been up to me to figure out. Should I figure this out on a component-by-component basis or on a project-by-project basis? Yes, it can be great that I "am able to but don't have to", but it provides additional overhead and complexity - if the community can do anything here, a Vue developer should better learn everything.

The new <script setup> hook does seem to commit to a way of using the composition API - replace everything with it - but that isn't how the project has presented it. In the blog post it's described as "a compile-time syntactic sugar that greatly improves the ergonomics when using Composition API inside SFCs" but we still lack clarity on when we should use Composition API inside SFCs. I certainty lack clarity on the place of the Options API in Vue's philosophy in 2021. Is it indeed just a way to support the old way of doing things, but the Vue team has devised a better way? So far, it's hard to tell from the docs that Vue believes the Composition API - let alone the <script setup> - is any better than the Options API.

[yyx990803]

@JokerMartini do note name is now optional in most cases: https://github.com/vuejs/rfcs/blob/master/active-rfcs/0040-script-setup.md#automatic-name-inference

[JokerMartini]

Good to know i was unsure of that. Thank for the follow info.

[rbluethl]

@yyx990803 "new projects should go all-in Composition API (and if using SFCs, with <script setup>)", I'm wondering what else there is besides SFCs? I've never seen anything else than SFCs in larger projects. Could you elaborate a bit on this? What are other approaches where script setup wouldn't be the best option?

[yyx990803]

Smaller projects may not use a build step at all. Some users with React background do use JSX/TSX with Vue, despite it being sub-optimal.

[BenJackGill]

@yyx990803 Can I suggest you add <script setup> as an option to the Vue Cli? That would boost it's uptake dramatically, and make my life easier at the same time. I would even argue that you should make <script setup> the default for all Vue 3 projects.