Hello! I’m Zhenya Kucheryavyi, front-end director at Rentu. In this article I’ll tell you how we moved from Vue2 to Vue3, what bumps we hit and what we learned. The article is not hard.
Let’s start with the stack we had:
-
Vue 2.
-
Nuxt 2.
-
Vuex.
-
Element-ui
-
Bootstrap.
-
Argon (admin template for $20).
-
amCharts 4 and 5.
-
Bad bikes.
-
Jest.
-
Webpack 4.
The stack is just like a stack, although a bit old. But I still wanted to move and here’s why:
-
Slow code.
-
Memory leaks.
-
Bad DX.
-
Legacy technologies that are difficult to hire people for.
-
Problems with onboarding.
-
Long pipelines – deployment could take 1-2 hours.
Everything would be fine, but besides the reasons, we also had a reason – on December 31, 2023, support for Vue2 was stopped, which further aggravated the existing reasons.
Coordination
After discussing all this with the CTO, I came up with a simple migration plan:
-
Cut out the old one.
-
Updating dependencies.
-
We’re moving.
The task is understandable, but time-consuming, because there was a lot of stuff to cut out. For example, we didn’t want to move to Nuxt 3, because in general we don’t need it – the system is closed, SSR is unjustified.
After evaluating the plan, the CTO determined that it was a generally safe option, but potentially endless. Therefore, he suggested an alternative – simply create a new project and copy-paste the code there, throwing out everything unnecessary.
I’m a sucker for such things. They tell me that you can throw out the old and make a new one – I agree. Spoiler: in vain.
And to explain why the CTO even proposed this option, we need to make a few digressions:
-
CTO is luckier than me. For example, we went scuba diving together. He felt unwell, he made a gesture to the instructor and they lifted him up. And I almost died that day (kulstories on request).
-
CTO is a workaholic, best described by his own quote: “Finally, it’s the weekend, I can work properly.” When evaluating, he simply multiplied his efficiency by the number of people in the front-end team.
-
The CTO didn’t touch the front for over a year.
And this is my first mistake:
Ignored red flags when planning.
But the process has already started
I divided the move into 120 tasks, created a table in the wiki so as not to duplicate components, and we began the move. According to the initial estimate, a month should have been enough.
A month later, I reported on the successful completion of 80 tasks out of 120. Not a fountain of course, but we were approved for an additional month, so we continued the migration.
At this time I realized that a month was not enough for us:
-
People spend a long time fiddling with tasks.
-
It is difficult to conduct a review.
-
Some components are duplicated, despite the table.
And this is my second mistake:
The tasks are too big.
There was nothing left but decompose them.
And now, a month later, I report that we have completed 130 out of 160 tasks.
A month later there were already closed tasks 160 out of 200.
I won’t beat around the bush and say right away that in the end we spent 350 tasks on the move + a bunch more were spent on bug fixes.
We can’t cope
At this point I started to burn out, because people Badly managed despite my efforts. To save the situation, I decided to throw all my strength into this and also started writing code:
And this is my third mistake:
Worked with code when needed to work with a team.
The move is over
Despite the pain, burnout and extended deadlines, we still completed the move. In total, it took 30 man-months instead of 8.
We got a new stack:
-
Vue 3.
-
Element plus.
-
Bootstrap (drank in the process)
-
amCharts 4 and 5 (almost everything is 5).
-
Vite.
-
Vitest.
-
Better bikes.
The indicators have also improved significantly:
-
Dev build in a second, not in 2 minutes.
-
Memory consumption is 2 times less.
-
Improved DX.
-
Latest dependency versions.
-
Deploy in 7 minutes, not an hour.
What have we learned
Just three simple points:
-
Uninvolved people should not influence planning.
-
Decompose.
-
Working with people is more effective than working with code.
That’s all?
Some conclusions are at the junior team leader level and from the category “Do well, but don’t do bad.”
What really happened? And why were other companies able to move much faster than us?
And the answer is actually very simple – because we were a startup quite recently. And startups survive due to such practices as hero engineering – when you work as hard as you can to solve any problem. Be it dropped sales or unrealistic deadlines.
And here we have a little flashback:
People Badly managed despite my efforts.
But in reality, everything was a little different:
People worked not enoughto complete the move on time.
And it’s even hard to blame these people. They weren’t the ones who agreed on the deadlines, they weren’t the ones who started such a long marathon in which hero engineering stops working because everyone is already exhausted.
And in general, this is a practice that really shoots you in the foot over a long distance. It’s like having a person bailing water out of your boat 24/7, when you could have simply repaired the hole.
And this is my real mistake:
Play a hero to hide management’s mistakes.
Present conclusion
Acknowledgement and Usage Notice
The editorial team at TechBurst Magazine acknowledges the invaluable contribution of the author of the original article that forms the foundation of our publication. We sincerely appreciate the author’s work. All images in this publication are sourced directly from the original article, where a reference to the author’s profile is provided as well. This publication respects the author’s rights and enhances the visibility of their original work. If there are any concerns or the author wishes to discuss this matter further, we welcome an open dialogue to address potential issues and find an amicable resolution. Feel free to contact us through the ‘Contact Us’ section; the link is available in the website footer.