Damn bro Vue 3 sucks actually. It's just a big function now with arguments like "`this` can be sometimes confusing when TypeScript is used." - hell no, my component was a class and this was the fucking class. nothing was confusing about this.

It's all a clusterfuck of magic now, I don't see why writing `ref(5)` or `return { all of your shit }` after `setup() { complete business logic inclusive functions here }` is better.

I was so looking forward to all the improvments, but why do we need these 3 apis with actually no difference, tried to be explained by the same image of colorful blocks in every single fucking article?

what happened to methods? am i seriously supposed to return them from a function? that just feels wrong.

the image in question btw. like nice, the code moved. wow.

Oh btw, if you're trying to read some code on the image: that's not compression, the image has that size. because the argument here seems to be "defragmentation!" instead of acutual usefulness.

The composition API was the reason I switched to Angular with all new frontend projects. There’s some good in Vue 3 as well, and I see where they wanted to go and the intentions are good, but the implementation.... eh, let’s just put it this way: the drawbacks far outweigh the good in it.

MFW both sides of my psyche agree to just write HTML5 / CSS3 / ES6 frontends forever staying completely out of the rise and fall of frontend frameworks and still writing REST compliant offline first SPA with ease because it's not hard.

@HiFiWiFiSciFi yeah well you must've been that guy who provided all the samples for Vue 3. Just one job, one prop, one string, telling me hello world.

Hey, OP. Were you working on enterprise level applications with VueJs before 3 came out?

@nitwhiz i can feel the frustration - kinda thought the same when first seeing it.

Seeing what good devs can do with it (directus 9 for example), and getting the hang of composition api myself im starting to see the massive benefits though, and i LOVE it.

Also, it's backwards compatible so even with vue3 you aren't forced to change anything. The only feature im missing so far is being able to do away with the .value wrapping when constructing an object with multiple refs/computed on there. Maybe it's possible and i just haven't found out how though.

@eval i guess it just takes some time to get used to it, yeah. It doesn't feel like a transition, but more like a clean cut, even though there are migration guides everywhere.

@telephantasm yes. That and I heavily used it for private projects, too. That's why i was very excited for the performance boosts and all that. Didn't expect the "syntax" or "how it's done", when it comes to SFCs, to change that much.

@nitwhiz but you do know that old and new syntax can be mixed without any real downsides?
I can't migrate most projects because getting quasar-cli to work with vue3 would not be worth it. But i added @vue/composition-api, and started using it where it brings a benefit. All the old code stays with the old API until there's a good reason to migrate.

Well I assumed you used it for private projects. But, I actually don't know of anyone who uses it for enterprise webapps, that's why I specifically asked you that. Just wanted to hear a professional Vue dev's point against 3, because I really don't wanna waste my time like that time we all switched from AngularJS to Angular (REMEMBER GUYS?).

@telephantasm Don't hold yourself back because of my words, I'm very jumpy, when it comes to forming an opinion..^^

After using it a bit, it got better. I still think it's weird how this stuff is thought through tho. Like, what's the actual use case of this composition-stuff? Is it really just a comfort thing so I can put code for the same thing in a component into one file? Because that was never really a problem imo. Just make smaller components. I won't use these compositables anywhere else than in the component that made me write it. Maybe for sharing a state, but that's it.
Or am i missing a prominent use case here?

All in all it just doesn't feel like "yeah that's so nice, it was worse in Vue 2" _for me_.

Maybe it's just not ready to be heavily used with typescript class components. Because writing just big fucking objects and/or functions to make components is pretty dumb.

@eval that's right but I really want to get a grisp for the new stuff and APIs and ideas of Vue 3.

@nitwhiz i mostly agree with the "it's not really needed often, just make nice small components" - because yes, components SHOULD NOT look like the colored example.
But there is a use for it - like you said mostly sharing state. But sharing state in a clever way, which doesn't really work that well just with VUEX and utility functions. I think you (and @telephantasm) should really look at Directus 9 source code. That's an example of a large project where Vue3 brings huge benefits. It's really amazing to see how well a project like this can be extended, and i'm sure it's partly because of Vue3. Because with composition API you start writing some functionality in an easily reusable way, not because you have to but because it's not much harder and just makes sense.

This was something that i felt was missing from Vue2. And i really think that migrating to Vue3 but leaving options API for at least all the old code is not a sin - because options API is not wrong in any way, for many components it's probably even a bit easier to use. But you have the option of the more powerful paradigm when you need it.

@eval would you mind providing a link to Directus 9 source?

// EDIT: Here it is, for those interested in taking a peek: https://github.com/directus/...

@eval definitely going to look into it when I get home :)

I just had an idea. Could it be that the problem solved by the composition api never existed with typescript class components? Because there are no "options" or something like that, it's just a class with methods, props, getters and setters. Via Decorators i can tell a class prop to be a component prop and so on. Watchers are just `@Watch` on my method.

This whole options thing is indeed a mess and I can see that it got better by the composition api.
But please don't tell me people write actual enterprise without TS class components? We don't, at least.

@nitwhiz unfortunately yes, people do write enterprise shit with no TS and using Options API. I should know, I spent almost a year trying not to tear my hair out with one such case...

@nitwhiz true, the "Order" problem isn't really there with class components.
But tbh i think that (the problem they always show so prominently) is not important at all. The real power of composition API is like the name says: composing new functionality that is specific to a component from small parts that are specific to the project. The only way to do this before was with mixins and extends, and the problem there is that the small parts can't really interact in a way that is both easy to read and flexible.
Sure, you can add getters with dynamic names by using something similar to ...mapGetters, you can make a mixin factory if you need to add more than just either getters or methods or data.

I think it's also nice you don't have to pollute "this" with internal stuff anymore, or are at lesst able to rename it in a sensible way. But it does take a lot of getting used to

Yeah! Vue3 sucks big time! There are also not many job opportunities here in India. Angular seems stable now. Vue lost its charms in this update. We have completely discarded Vue3 initiatives from our office.

I want to come back here and clarify, that I love vue3 now.

The arguments still make no sense if you used class components before, but the nice thing with vue3 is, that these setup functions are a nice compromise between class components and the option api.

@nitwhiz Yeah, this colorful block has nothing to do with real life code, they fully skipped clean separation of code by functionality like this part is data, this part is functions, this are computed values, in Vue 3 all this missed up completely

@eval having compostion API as recommended screwed up all the documentation and examples in all third parties packages that just don't provide or even support options API, for example it's a real problem with Nuxt 3 when you try to build project with options API there

@vedmant separation by what you call functionality is something i would consider an antipattern, just like when people thought it's a good idea to keep the css as far from the html it affects as possible.

Stuff that interacts the most should be closest to one another. So a few computed, a ref and a watch that all handle a certain part of the functionality should be together, not separated because they are different types of stuff.