Sit comfortably as I tell you a tale of adventures and discoveries—a new chapter of scaling our startup’s tech stack. A quest that, in the last months, has led the Snipcart team in newly found territories.

A quest that we are now ready to share, to help anyone who could possibly have to go down the same route at any given moment.

I’m talking about our current progressive migration from our old Backbone architecture to the younger and more modern Javascript framework: Vue.js. If you listen to JS podcasts like us, you know we’re not the first ones to make the Vue move, and definitely not the last.

Gitlab, for instance, also wrote about their choice to go with Vue.

In fact, Vue’s growth is quite impressive, having surpassed Javascript libraries like Backbone and Ember, and slowly creeping up to Facebook-backed React’s level. It still shows no sign of slowing its ascension.

I won’t explain in details Vue’s history or how it works here, because we already made a blog post about it. However, it’s important to recall that it is a progressive framework, designed from the ground up to be incrementally adoptable.

Knowing this, it should be a child’s play to slowly implement Vue.js components into our pre-existing code, right? Well, let’s dive deeper into our experience so far, starting from the beginning.

Why Snipcart needed to move on to a new framework?

We started Snipcart almost four years ago (time flies, does it?). At that time the JavaScript ecosystem was far from what it is today. If you go back four years, you can forget about tools like Webpack. The most advanced “module” system at that time was RequireJS, and it was a pain to configure.

As a developer-first product, we really need to keep our things up to date. However, we know we can’t always be on the edge either.

If so, we would always be rewriting everything.

But we knew for a while that Backbone and RequireJS were making it harder to maintain Snipcart.

About two years ago, we switched from RequireJS to Webpack. It gave us a big boost in productivity, allowing us to switch from AMD to CommonJS, to use Pug as a templating engine, etc.

But we now face another problem, if we can call it a problem. We were looking at the new kids on the block such as React and Vue.js, and realized that the way these frameworks were dealing with the components was much more friendly.

#vue #vue.js #programming