Vue 2 was the closest thing that I’d really like to use: just my data with methods + declarative ui with bindings.
Call me old-fashioned, I still prever model-view relationships separated. Can’t see what’s wrong with having a non-visual model that works on its own and then putting views on top of it to make it accessible to a user. Not only that, I don’t get why I would write model logic in a way that would nail it to a views system.
Js objects have observable properties and (with some care) they can even be shared across different subsystems/libraries.
What I’d like to see is a UI library that takes my “instanceof Foo” with its value properties, getter properties and methods and observes it. Then I write vue-like html or hyperscript with an assumed root object:
The my_counter remains free to use elsewhere or to be included into a larger structure. The goal is that ui will notice “.count =” anywhere and schedule an update to dom.
Js is absolutely full of features which all these frameworks are trying to reimplement for some reason. There are rough edges that Vue addressed (array obs mostly) and I thought that wow that’s its purpose with some helpers around it. Nice, the next step is to deprecate Options in favor of just js. But it went completely downhill since with sfc and composition and all.
Completely my feelings as well. I have an old desktop app I wrote a few years back in Vue2. The NodeJS version and all related libraries are outdated. But I can’t bring myself to update it to Vue 3. Every time I sit down, I am left wondering why such a rewrite is even necessary. So it’s still chugging along with contributions from others for the old code. When GitHub actions stops building the binary packages, I will have to eventually update I think.
Vue is great. I loved the old Options API and was resistant to the new setup/composables way of doing things. But as soon as I tried the new way I loved it. I think it will scale much better as well.
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)
Me too. The options api enforced grouping and you could lint the ordering of the lifecycle methods, methods, computed, data etc. Thjs made it very easy to know where to find something inside a component
Grouping is good until you have a UI component that needs to do 3 different things. It will be a mess because everything is mixed together. See official example: https://vuejs.org/guide/extras/composition-api-faq.html . This has been tremendously useful for developing large components.
If you haven't found a need for this, great for you. Options APIs will also continue to be available for the foreseeable future. But that doesn't mean it is better in any way.
I like the options api but what I like about the setup api is that you don’t have to import components then specify them in components property. Makes it a lot easier when doing go to source, and you can just import them automaticallly with dev tools.
i find it so much harder to grok the structure of Vue 3.x code. A data variable or prop can be defined literally anywhere. And it could be directly reactive or a ref. It's all cognitive load I didn't need before. Vue was always "worse" than react in both mind share and flexibility / purity and power. But it made up for all of it with the beautiful intuitive simplicity. So much of that is lost but I find it hard to argue any of the other aspects are better than React now. So Vue just feels overall a bit mediocre now.
I will say, with 2.x about 50% of bugs where not using Vue.set(...) in some obscure place or way, and those have all gone away, which I love.
We're currently going through a migration of writing new components in composition style, but obviously have a lot of experience with the options API and a lot of existing code using it.
It's taken the team some time to get used to how to do things in the new way, but on balance, we do like it.
It feels like there have been some odd caveats, like the new reactivity system approach not working exactly like we'd expect. But caveats exist in the options API too.
Yeah, I don't get it. I used Vue because it was straightforward. The options interface was Vue. Now, if it keeps getting more complicated and also has two ways to go about things, and the docs are split into two as well... Why not just go for React that's complicated and more popular?
I thought the composition API was clunky at first and resisted migrating for a few minor versions, but it's matured nicely. I find it much simpler than the options API, and migration was much easier than I expected.
I don't see it as two ways in practice, just the legacy way for old projects (which still has good support), and the newer/better way.
Asking because my experience is that as soon as you have a large and complex component that needs to have multiple, mostly independent functionalities, you'll find the composition APIs to be a godsend. Not to mention all the IDE support. You won't see that until you have first have experience with it.
Vue makes things simpler and when you get a hang of the reactivity fundementals, it is a breeze to work with.
React has more 3rd part support. Larger ecosystem and much better tooling. You’ll have better editor support, linting, formatting etc with jsx.
My issue with React these days is that it is basically owned by Vercel at this point. And the development direction reflects that. Go check out the official docs. “quickstart” of React is basically “Use Next”. I personally like React a lot but hate Next with a passion after working on a couple of large Next codebases.
You can obviously avoid that (or prefer next).
I think signal based reactivity is on the works to be standardized in JS so the vue approach might get faster / better if it does. The language itself will provide the reactivity primitives all but react (vue, svelte, solid..) use basically.
Biggest functional difference is that Vue's reactivity is built on Proxy objects, which lets you simply bind your view layer to your model layer and things just keep in sync, without any extra APIs to think about. React has useState which gives you a setter that you need to use with an entirely new object each time. In Vue you can just change a property deep inside the model layer and the view updates.
That's what's keeping me in Vue primarily. I think MobX does something similar in React but the API is clunkier than Vue.
On top of that, the API is just much nicer. None of the confusing functional language and concepts e.g. "what exactly did the programmer intend by this 'useEffect' call??"
> In Vue you can just change a property deep inside the model layer and the view updates
I never used vue for production apps, but my feeling tells me this could be a problem when the app becomes big.
If you change a prop deep inside the model layer the chances of triggering an unintentional view update are higher? By using setters, you're essentially creating a more structured and controlled way of updating your application's state. But I have the react googles on, maybe I am missing something :)
The two binding happens in context of forms and user editable fields only. So, it is actually mirroring real world of a value can be changed from two different sources I.e. HTML and javascript.
Once you are in js land, changes occur in one direction only, I.e. from parent to child. Child cannot update parent directly via two way binding. Child need to emit an event. This brings vue in line with react to issues and semantics.
Ok then the parent is talking about those situations (forms and user editable fields) not about state in general in the library, correct ? If that’s the case, weird comparison.
I've been a React boi since day 1, was happy to leave v1 Angular behind back then. Since then, I've played with them all, and have had a couple professional experiences with Vue, one very recent:
It is not close to React in terms of maturity, which is for me the largest issue with it, especially around TypeScript, Storybook and bugs. In my 10 years of React I have not encountered a single bug in it (not saying there weren't any, I just wasn't affected). In my month of Vue I had one blocking tooling bug and one ripping-my-hair-out-for-a-few-hours core bug. On the upside, a Vue contributor had a video call with me on the former and Evan himself fixed the latter within a day or two
Docs are mostly good, but React wins here too. What React Docs do really well, and what might be under-appreciated, is talking about trade-offs and pitfalls. Vue could use some of that, especially since it promotes mutability as its most idiomatic path, which can have subtle side-effects one should be mindful of. And I would bet many people, coming from more immutable frameworks, fall head-first into these pitfalls.
Vue, like Svelte, is (since v3 afaik) all-in on SFC (Single File Components). I personally dislike the singular focus on this style of component-ing. I like having multiple components per-file, doing higher-order component-ing (e.g. having a record of components) and having other exports from the same file. Sure, one could probably work around these by adding more files, but I don't like it when frameworks incentivize spraying files. I also have that critique with Next.js, though I find the bundler-boundary trade-off argument more convincing there.
I do like the ease of co-located styles though!
An interesting nut that I'm trying to crack is how I feel about Vue's model-binding. Binding a state variable directly to a component, without separately specifying the getter & setter like in React, does make for more concise code. But then there is the aforementioned pitfall of this leading to mutation and possible spooky actions at a distance.
So my summary is: Some interesting differences to React, but overall not worth the divergence and community energy splitting. I think the things React is innovating on are still the most interesting ones in the view-library ecosystem. That said, I found the Vue contributors to be very nice people to interact with.
Vue 2.x didn't know what it wanted to be, Vue 3.x feels decent and not at the whim of JS shitfluencers on YouTube. One can be perfectly productive in it and it scales to CRUD apps of any size.
I personally enjoy React and TSX and a minimal setup but it is a constant battle to keep it minimal because the ecosystem is driven by merchants of complexity.
React is more mature, as it has a much larger ecosystem, community, employment opportunities, corporate support.... Vue is simple and delightful when used in small projects. In other words, they are not comparable.
Vue is absolutely a lot more delightful compared to React even in large projects, thanks to fine grained reactivity which React still lacks after all these years (I know people have come up with various bandaids). React wins in ecosystem, i.e. the breadth of available libraries.
I've built with React a few years ago but React is still at the top by a large margin. Second is Angular because a lot of enterprise apps are built with either React and Angular. Vue's is definitely 3rd and a big jump in popularity had to do with Chinese dev's using it simply because Evan You is Chinese.
Vue uses the actual DOM instead of the virtual DOM but try and build something tiny with both and see which programming model you like and choose that UI library.
I actively use both, and I actively detest ever working on the React parts of the codebase, and look forward to any and all Vue tickets, even the crappy ones like refactoring untyped 5k LoC Vue components.
People always bring out the bigger community or whatever in React, but IMO that's a huge big red negative against React. Every single React project will have its own way of dealing with state & routing at a minimum, which are the two things that should basically be identical regardless of the application (unless we're talking some hyper-specific circumstances, but for 99% of projects out there a golden path would be more than enough). There's lots of different patterns out there, and to this day you've got people wondering WTF is even going on with the 27 different state management libraries and 6 different Router libraries available to you. For miscellaneous packages, the only ones that I feel Vue is really missing out on would be things like Framer Motion which is a bit of a shame, but for the most part, 99% of most JS libraries out there will work just fine in Vue, especially Vue 3. We use Three.js a lot in our Vue 3 app and it works flawlessly, as it would in any other framework.
You automatically get better performance straight out the gate with Vue. In large apps, unless you have a React wizard who does nothing but optimize the React code 24/7, Vue will still be faster without you having to contort yourself into pacifying the framework. It's leaner both bundle-wise and logic-wise. There are far, far fewer footguns in Vue, the worst case is usually some weird quirkiness with deeply nested reactive objects, but even that is pretty rare in my experience. In a React codebase you're pretty much guaranteed to run into some reactivity footgun sooner rather than later, and it can often be a complete nightmare to deal with.
Don't even get me started on the whole Vercel bullshit, where they basically took over the project and are now pushing change after change that benefit Vercel and nobody else. The whole SSR meme needs to die, IMO, it has been such a clusterfuck of unnecessary complexity.
I also personally think the Vue docs are miles better than the new React docs, but this one's probably up to personal taste, as I see some people in this thread that prefer the React docs. Similarly with JSX, this comes down purely to personal preference. I prefer SFCs, some people prefer JSX.
Some things that React is better at, to keep this rant fair(ish):
- Undeniably better TS support. CompAPI has helped a ton and Vue has caught up a lot, but React still eeks out
- The community aspect, as in people posting guides and articles about it, is much bigger. Though in my experience most of these types of articles/posts/guides are long outdated or promote terrible practices (again, due to how easy it is to hit a footgun in React)
- Tooling and editor support is better for React, though with WebStorm I don't feel like it's that bad in Vue. No clue of the state of things on different IDEs.
- Despite my issues with Next and Vercel specifically, it's still IMO better than Nuxt. I haven't used Nuxt professionally, but at least for personal projects it feels quite buggy and unstable. Bare/"vanilla" Vue vs "vanilla" React is no contest though, Vue wins by a mile
Call me old-fashioned, I still prever model-view relationships separated. Can’t see what’s wrong with having a non-visual model that works on its own and then putting views on top of it to make it accessible to a user. Not only that, I don’t get why I would write model logic in a way that would nail it to a views system.
Js objects have observable properties and (with some care) they can even be shared across different subsystems/libraries.
What I’d like to see is a UI library that takes my “instanceof Foo” with its value properties, getter properties and methods and observes it. Then I write vue-like html or hyperscript with an assumed root object:
The my_counter remains free to use elsewhere or to be included into a larger structure. The goal is that ui will notice “.count =” anywhere and schedule an update to dom.Js is absolutely full of features which all these frameworks are trying to reimplement for some reason. There are rough edges that Vue addressed (array obs mostly) and I thought that wow that’s its purpose with some helpers around it. Nice, the next step is to deprecate Options in favor of just js. But it went completely downhill since with sfc and composition and all.