Seems like pretty legit reasons. I know that React has come a long way in terms of ease of use and docs now with most of the 16.x releases behind us. Was wondering if you started a Greenfield project toady.... Do you think you would evaluate again or stick with Vue?
Great article. I truly was trying to find a good situation where someone chose Vue over React or Angular and be able to articulate the reasons well.
It seems you are happy as a team with the decision! And can back up your choice with good reasoning..
I am developer from Tajikistan. I live in the United States of America. I love programming. I love learning new ways to solve problems.
I am also into photography, video/Youtube, and racing.
Location
Virginia, USA
Education
George Mason University, BS in Applied Information Technology
Honestly, for greenfield projects we would still stick to Vue. So far it has worked really well for us and there wasn't a situation where Vue was slowing us down or it had us looking for something else.
I am very excited about what's coming up in the next version of Vue.
I've been using Vue for about 3 years and love it. It's simple to learn and the Single File Component system makes understanding the code easy, however, with some of our larger apps, I've started to run into some issues with immutability. Once you start passing around a lot of data, utilizing Vuex and Vue's 2-way data binding becomes increasingly difficult to debug. It's lead to us adding extra boilerplate to ensure we're sending new copies of objects and not mutating existing data and has lended itself to some strange decisions in the code.
Don't get me wrong, I LOVE Vue, but because of these downfalls, I'm considering utilizing React where I wouldn't have before, because of its strong concepts of functional programming/immutability. Sure, we could add things to Vue, like Immutable.js or replace Vuex with Redux, but that adds complexity to the setup that's not well documented, nor is it part of the typical Vue setup.
For now, we're just dealing with any of the issues mentioned when they come up, but I feel like it's making our code less maintainable. It's unclear in the code why some decisions were made unless you run it without the changes. For this reason, I believe in the future we may eventually move to React, unless something changes in Vue 3. As much as I want to stay with Vue, because the ecosystem is wildly easier to learn and operate with, I feel like it's better suited to small-to-medium sized apps than large ones.
I am developer from Tajikistan. I live in the United States of America. I love programming. I love learning new ways to solve problems.
I am also into photography, video/Youtube, and racing.
Location
Virginia, USA
Education
George Mason University, BS in Applied Information Technology
I think if you stick to a disciplined approach to data access and mutation, Vue and Vuex scale fine.
I also have rarely used the two way binding in Vue. If you are keeping access to data from store with getters and mutate with actions, things should be easier to scale. Idk how much redux and react will help you if you are following those patterns
You're also going to end up creating a TON of boilerplate code to handle all your mutations. Mapping to Vuex values with one-way :value/@input events, or a get/set computed property is easy if your data is flattened but when you're dealing with large objects and tons of form fields that need to map to nested properties, you end up creating a bunch of actions and mutations to deal with everything. Alternatively, you save your state locally and use v-model to update the fields easily, then you commit to the store on submit. This approach is better with large data sets, so you're not commiting to the store with every field change, but great care has to be taken in order to not mutate the data in the store directly. You must deep clone your objects.
An easier approach with such big objects, is you deepClone them when you're going to edit them.
If the user changes anything, you save the changes; If the user cancels, you destroy the clonedObject.
That way your data remains untouched (whether you brought it from an API, or from Vuex) and you can still submit changes back.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Seems like pretty legit reasons. I know that React has come a long way in terms of ease of use and docs now with most of the 16.x releases behind us. Was wondering if you started a Greenfield project toady.... Do you think you would evaluate again or stick with Vue?
Great article. I truly was trying to find a good situation where someone chose Vue over React or Angular and be able to articulate the reasons well.
It seems you are happy as a team with the decision! And can back up your choice with good reasoning..
Honestly, for greenfield projects we would still stick to Vue. So far it has worked really well for us and there wasn't a situation where Vue was slowing us down or it had us looking for something else.
I am very excited about what's coming up in the next version of Vue.
I've been using Vue for about 3 years and love it. It's simple to learn and the Single File Component system makes understanding the code easy, however, with some of our larger apps, I've started to run into some issues with immutability. Once you start passing around a lot of data, utilizing Vuex and Vue's 2-way data binding becomes increasingly difficult to debug. It's lead to us adding extra boilerplate to ensure we're sending new copies of objects and not mutating existing data and has lended itself to some strange decisions in the code.
Don't get me wrong, I LOVE Vue, but because of these downfalls, I'm considering utilizing React where I wouldn't have before, because of its strong concepts of functional programming/immutability. Sure, we could add things to Vue, like Immutable.js or replace Vuex with Redux, but that adds complexity to the setup that's not well documented, nor is it part of the typical Vue setup.
For now, we're just dealing with any of the issues mentioned when they come up, but I feel like it's making our code less maintainable. It's unclear in the code why some decisions were made unless you run it without the changes. For this reason, I believe in the future we may eventually move to React, unless something changes in Vue 3. As much as I want to stay with Vue, because the ecosystem is wildly easier to learn and operate with, I feel like it's better suited to small-to-medium sized apps than large ones.
I think if you stick to a disciplined approach to data access and mutation, Vue and Vuex scale fine.
I also have rarely used the two way binding in Vue. If you are keeping access to data from store with getters and mutate with actions, things should be easier to scale. Idk how much redux and react will help you if you are following those patterns
You're also going to end up creating a TON of boilerplate code to handle all your mutations. Mapping to Vuex values with one-way :value/@input events, or a get/set computed property is easy if your data is flattened but when you're dealing with large objects and tons of form fields that need to map to nested properties, you end up creating a bunch of actions and mutations to deal with everything. Alternatively, you save your state locally and use v-model to update the fields easily, then you commit to the store on submit. This approach is better with large data sets, so you're not commiting to the store with every field change, but great care has to be taken in order to not mutate the data in the store directly. You must deep clone your objects.
An easier approach with such big objects, is you deepClone them when you're going to edit them.
If the user changes anything, you save the changes; If the user cancels, you destroy the clonedObject.
That way your data remains untouched (whether you brought it from an API, or from Vuex) and you can still submit changes back.