I don't really think that it should be depreciated, As Evan said, Its depreciation will depend above use cases and I am using it in the 2nd last release 3.2.19 and it still works like a charm. I agree with the blind rumor that it's not maintained anymore but still no words from the core maintainer (@ktsn) that what is his plans, to continue with this or not. So directly asking for depreciation doesn't make sense at all.

@r-priyam
I agree that this library works really well with Vue 2. But I think it has completely no sense for Vue 3 (especially with the strange syntax from here: #465)

I, for one, would prefer someone to take over maintainership. I would hate to see vue-class-component die, as I love the object-oriented syntax (coming from desktop GUI toolkits like Swing and Qt) and use vue-class-component in all my personal Vue projects.

I disagree with the logic where the primary motivation to deprecate it is to reduce the options available. The library does make it simpler.

I like too to use this library. Don't deprecated this

Just my two cents as someone learning Vue for the 2nd time (the first experience being a freelance project in 2015). So, take this with a grain of salt if you'd like.

I have an extensive background in AngularJS & Angular and designed an enterprise solution for the company I work for in Angular. I would like to blend in some Vue and bring my own Vue knowledge back up to see if we are missing anything so I've been working on an internal tool with Vue 3.

I'm only a few hours into this project and really just getting my feet wet, but I can tell you from an outside perspective the Vue ecosystem already feels extremely fragmented. With that being said with the continued dominance in the marketplace with TypeScript it seems like the community would be missing out big time by deprecating this project. I have been going back and forth between writing components in Options API and Composition API and they're so maniacally similar that it's painful to discern the differences as a novice, but I also am not sure which is better and honestly I don't really know most of the pros and cons because they seem so subjective from everything I've read from the community so far.

I think a distinctly different coding paradigm like class declarations reaches out to a much larger sect of potential Vue developers. It specifically leans into TypeScript support and class declarations are significantly cleaner in TypeScript than handling either the Options or Composition APIs while trying to craft Vue components from my experience so far. It's understandable that some might not find it necessary but it seems like class components offer a much different experience with better TS support than either Options or Composition, and ultimately have gotten my attention solely based on the fact that I'm very comfortable with TS classes.

I am going to try this library out and hope that my comments are considered because I think the learning curve for Vue is much steeper than it used to be because the different style options of writing Vue code now feel very similar but extremely nuanced and to be honest a bit frustrating sometimes to parse through which I should even use in a project.

There are other great arguments in here.

May not need to be deprecated as it looks like, from Googling, everyone that is trying to continue using class based components in Vue 3 are just hitting road block after road block which is a shame.

Classes offer a lot of benefits, speed and memory usage being some of them, and I understand there are issues(that could be solved with time and effort IMHO, but that's up to the maintainers to decide).

To me the biggest and arguably the most important is legibility. Maybe it's from my background or not, but reading a nicely formatted class in code is quick, painless, easy to re-structure, easy to parse and reason. Where as the other APIs are effectively like staring at giant JSON blocks and are painful to parse and reason about. I don't want to code in webpack configs.

I'll be sticking to Vue 2. And it looks like a lot of others will be as well. This is reminiscent of the Python 3 situation, the community was fragmented and they had to drag out support for 2 for way longer than ever intended. They may want to reduce the surface area as another said, but this will likely just drag out the life of 2 well past its intended life. It's not an insignificant amount of users that want this as can be seen by the usage statistics of vue-class-component and vue-property-decorator.

I spent the past couple of days refactoring vue-class-component and vuex counterpart out of my Vue3 project and replaced it with the Composition API. Not only did I reduce code size, I reduced complexity, removed workarounds that I had to use due to vue-class bugs, and I think it's more legible than before.

Typescript works perfectly fine in Vue without the need for classes and I made this comment after finally deciding to refactor a medium-ish sized project as I came up against one too many roadblocks from using this project. I would recommend all readers to not worry about dropping vue-class-component as it was pretty simple to do. And the bug I hit resolved itself too by losing this dependency. You don't need classes to write good Vue code and have good Typescript support,

reduced complexity, removed workarounds that I had to use due to vue-class bugs, and I think it's more legible than before.

This seems rather opinionated -- my codebase which utilizes class components has reduced complexity, and code introspection is a lot faster and less difficult with class-based components.

With JS moving towards more and more classes (e.g. custom elements, etc), fully dropping support for class based components will do more harm than good for Vue and will push a lot of people towards Angular I think.

I'd sooner prefer to see vue-class-component get properly supported (as as you have mentioned, bugs with it tend to get ignored or downplayed.)

Vue 2 had great class support, I'm not sure I see the point of abandoning this fantastic way of using Vue which has many benefits such as reduced typing, improved organization (at least IMO), improved readability (albeit, this was with TS annotations that only works in Vue 2, another pain point with moving to 3) etc.

This seems rather opinionated -- my codebase which utilizes class components has reduced complexity, and code introspection is a lot faster and less difficult with class-based components.

That's fair. I more meant in the meantime, considering the lack of maintenance for this project, that for some projects it might be worth considering dropping the dependency.

This seems rather opinionated -- my codebase which utilizes class components has reduced complexity, and code introspection is a lot faster and less difficult with class-based components.

That's fair. I more meant in the meantime, considering the lack of maintenance for this project, that for some projects it might be worth considering dropping the dependency.

I'll be honest, vue class components is what won me over with vue. I guess ultimately I'd appreciate it most if Vue would come out with a stance regarding this because it being in limbo does no one favors.

Im optimistic!

I spent the past couple of days refactoring vue-class-component and vuex counterpart out of my Vue3 project and replaced it with the Composition API. Not only did I reduce code size, I reduced complexity, removed workarounds that I had to use due to vue-class bugs, and I think it's more legible than before.

Purely personal opinion, but the Composition API, especially <script setup>, is full of edge cases that make writing straightforward components unwieldy. You have to reason about different semantics, whereas vue-class-component is purely a different syntax for the Options API's semantics.

There's one particular edge case that has kept me on vue-class-component: beforeRouteEnter in components. There is simply no equivalent of it in the Composition API, so you can't just write the function in <script setup>; instead you have to write an empty Options API component definition so you can stick beforeRouteEnter somewhere, and then TypeScript won't let you refer to the component type inside the function because it doesn't consider it a type. Writing the same code with vue-class-component is very straightforward in comparison.

i make the https://github.com/agileago/vue3-oop to use class component in vue3. and its feature is class + tsx + di .

In my opinion, Composition API is a compromising plan to make it compatible with VUE 2's plain object component for resolving logical concerns problems. The class based components could resolve the problems perfectly and more elegant with JS or TS decorators. VUE 3 is also designed in TS and classes, so class based components should be first-class citizen in VUE 3 natively as default option.

And more, JSX as a general template language has a well supported type system in TSX and a large number of users. Class based components and TSX is the best practice for me.

The lack of a firm decision on this one from the maintainers (@ktsn ?) is making difficult for users to make design decisions for their projects. In our case, we very much like this component and would like to use, but if it's not going to be maintained we won't. And we are at a point where we have to review/rewrite a big chunk of the app and needs to decide what style of component writing to adopt. We are stuck not knowing if we should invest time in vue-class-component or not.

Otherwise, I hereby am thumbs upping everyone here who expressed support to keep this component alive. vue-class-component based code is so much more elegant and readable than the new APIs.