Jacob describes how, when moving away from writing things with Rails, Gitlab needed the following things from a front end framework:
He says while there are probably no “wrong answers” in choosing a framework, Vue was the best choice for them because it had the smallest learning curve and was “drop-in”, meaning it didn’t initially require npm or Webpack, but it could still scale along with them.
He found that Vue had a small learning curve and devs could be productive immediately. Also, it is both opinionated and not opinionated. Meaning it provides a whole ecosystem with options for routing and state management, which you can choose or not, and Vue will work well either way.
Jacob describes how Gitlab had “baggage” from their prior tech stack, which included JQuery and CoffeeScript. One of their first steps was to remove CoffeeScript, which they compiled to ES5 then rewrote in ES6.
Instead of rewriting everything, they did progressive enhancement, delivering new code in parallel with the new features. Vue allowed them to start simply and get complex later, starting with Vue in .js files, then moving on to .vue files. Once they added Vue loader and .vue files, their performance drastically improved.
As their developers starting all writing in .vue files, they needed more consistency in how they were doing things. Implementing Vuex solved a lot of their issues regarding consistency.
Because of the virtual DOM, Vue was automatically taking care of a lot of considerations that they would have had to do manually with JQuery. As a result, they were experiencing a lot faster render times.
In other words, Jacob says Gitlab started with a lengthy, annoying development experience and has evolved toward a quicker, more pleasant development experience.
Gitlab even created their own docs on how they use Vue. Check them out.