I had the same vibe and I still have it regarding Nuxt 3.
Had it with React when it moved to functional components from class components.
But I convinced myself I have to dive deep enough to understand it since a lot of people seem to like it. And now I like the Composition API more in general.
Apart from one tidbit: I constantly forget where I need to put `.value` after a variable name to extract its... value.
Being conscious of variable types and function signatures helps you avoid trivial errors and become a more efficient developer. That's just a fact.
You can argue with it or ignore it however you want, but that's simply true.
I also know as a matter of fact that I am more productive than many of my colleagues when working with non statically compiled languages, and that my code is more robust, partly due to the typing I use everywhere. I have colleagues that write JavaScript functions that takes a parameter that could be 4 different types of objects, completely undocumented, and they don't know what's happening one week after shipping the code. I can't stop them doing stupid things like that. They like wasting their life debugging things and refreshing the browser, what can I do.
I raised the same concerns multiple times (there was a whole drama thread on GitHub issues at the time) about all of this and it’s clear that the Vue team don’t really care about developer experience or keeping consistent APIs.
If they were going to poorly clone react hooks api then I decided it wasn’t worth my time sticking to the niche framework and went back to react which I now really enjoy.
That and the bad TS support and broken dev tooling for years and the endless deprecated and abandoned tools like Vue CLI replaced by Vite and Vuex replaced by Pinia just highlighted the absurdity of trying to continue using Vue.
Also, JSX/TSX is clearly a superior approach with its vast ecosystem of support. Vue can use TSX but good luck with its single docs page and GitHub issues about it open since 2021.
> the Vue team don’t really care about developer experience
This is how you stir up drama instead of constructive discussions. Clearly the team do care quite a lot about developer experience, but they might have different ideals and goals than you do. So lets discuss those differences as adults.
Vue is all about developer experience. It is a framework! But you can’t make everyone happy which is why there are multiple frameworks. If React makes you happy, good for you. Vue made different trade-offs in order to achieve a different DX.
Looking into the different trade-offs is interesting.
I don't like where Vue is headed and I really dislike some of their newer design decisions but as some other commenter in this thread also stated, them having different opinions does not mean that they think the subject at hand is lower priority.
But also it needs to be said that improving DX (or UX, when we are at that) is not about pleasing the majority. It's about the experience for our target audience, which doesn't have to be the majority.
I can also care about design, while my choices look ugly for most people.
This is what I was getting at. The 2 to 3 migration and steam rolling over any raised concerns on GitHub while concurrently abandoning Vuex and Vue CLI for alternatives definitely does not even begin to meet minimal DX commitments.
Pinia have a far better DX than Vuex though. Vuex had a lot of boilerplate and “stringly-typed” actions. Of course the migration in itself have a cost.
Vite is so great it is getting adopted by other frameworks. (It is not tightly coupled to Vue)
There was absolutely no reason Pinia couldn’t have been Vuex 5.
I raised that point more than once and was always given the lamest reason for it.
They believed people would be “too confused” with the breaking changes in the new API.
This was always a dumb explanation. That’s what major versions are for - breaking changes. Of course upgrading from Vuex 4 to 5 would involve refactoring code.
Pinia is of course mush better and has real types. But they did themselves a huge disservice by not making that Vuex 5. That lack of focus on cohesive framework options and senseless deprecation of already established libraries is the major problem.
Sorry for being reductionist. I will try to do better. But you literaly say you are happy with the API changes from Vuex to Pinia, so it is unclear to me what you dislike apart from the name change?
I don’t work on Vue itself and cant speak for that team. I’m a developer who use both Vue and React daily and seem to be an exception in that I rather like both, while recognizing both have different strengths and weaknesses (I have also tried other frameworks like Angular which i didn’t like).
I mean, where are you getting "the majority" from? At least for myself and my company, we're heavily invested in Vue and we love CompAPI. Most people I interact with in the Vue 3 community also seem to like it with some niggles here and there (like the oft-misunderstood `.value`).
During the transition from 2 -> 3 it was a bit messy and I was even against the CompAPI originally, but after having actually used it in our app, it's miles better IMO. I understand all the pro-Options arguments and don't necessarily disagree with a lot of the criticisms about CompAPI, either.
OptionsAPI still exists, and probably always will, since it's already and always was an extra layer built on top of the underlying CompAPI, which itself was exposed publicly in Vue 3.
"Our highly educated and well ret... regarded colleges from a different department have different priorities that do not seem to contribute to our shared goal as defined by the Policy which our dear leadership bless us with" (finishes writing and takes 1h lunch break)
Had it with React when it moved to functional components from class components.
But I convinced myself I have to dive deep enough to understand it since a lot of people seem to like it. And now I like the Composition API more in general.
Apart from one tidbit: I constantly forget where I need to put `.value` after a variable name to extract its... value.