“Learning is not child’s play; we cannot learn without pain.”
― Aristotle
Countless frontend builders have been saying Vue will supersede React because of its better community support and more desirable learning curve. In most cases, considering the fact that large number of React developers still use class component and newcomers to the industry can jump right into the Vue world and become a Vue sensei overnight, this sentiment is true.
For the past 3 months, I have been working on a migration project focusing on upgrading Vue 2 to React 16.8+. After I learnt the ins and outs of both technologies in production, I realized I finally have this little privilege to talk about the missing parts the public always disregarded. Not here to start another jarring framework war, but if you are a reader who is looking for frontend solutions when it comes to lowering the project maintenance cost and improving the mental health of those engineers who worked on it, read on.
Scalability: read, understand and maintain
In order to create large scale software, code needs to be readable. You maybe encountered a situation when you cannot read some part of the code but still manage to make it work. This is an ultimate way to shoot your colleagues who are going to maintain that in the future in the foot. In this sense, Vue can make itself the culprit.
However, let’s face it, creating to-do list or count clicker is insanely easy with Vue compared to other frameworks or libraries:
Even for total novice in JS or Vue, he can still gauge what’s going on with this SFC file. Once the component grows and starts doing complex tasks and generating nested data, with 14 props in data() state, 20 methods, 12 computed data, 20 something ‘this’ here ‘this’ there, we are losing the power of OOP.
This singleton way of interacting between different objects(in this case, file) is bad because it’s oversharing and over-interacting, plus it violates SOLID principles when it manages different roles. Result? Hard to read, hard to understand and eventually hard to maintain.
Skill Transferability: It is not JS
Other than the obvious and obtuse @ and v-something syntax, I would rather describe Vue as a dynamic markup language that is user-friendly for JS developers. Oftentimes Vue developers will find themselves in a situation when they don’t have to master fundamental JS to master Vue. With no closure no declarative no composition, just fill in the template of this magical black box, and they are good to go.
“Is @ to use for decorator?”
“Why should we evaluate JS code in a double quoted string?”
These questions that are super important when you embark on JS journey seem trivial at this point. As long as you finish this ticket for today, nothing matters.
“Vue wordsmith is superior to C++ master”, they say.
When Vue is marketed as being “progressive”, its projection diverges from JavaScript’s development trajectory. Functional Programming is the now and the future, while OOP is the past.
Lightweight: lighter and lighter?
For startups, maybe lightweight technologies are the only sensible approach to build things from the ground up, due to financial and manpower related limitations. As in this case, there’s Svelte explicitly for lightweight monolithic software:
Functions are back, variables are back. Fully reactive, fully declarative and most importantly, you can tweak it into fully functional app.
If we have faster and more programmable tech out there, why would we use Vue as a short term solution?
3 months deep dive in legacy codebase had me learnt a ton, and it was a hard way. If I had the decision before the company made this leaden, monstrous and spaghetti coded verse, I would ask them to save the budget for other pain.
