Article

Why We (Too) Choose Vue

19 September 2018 | Artiom Nistrean | About a 6 minute read
Tags:


At AND Digital, we are often in a position where we need to work with legacy and, sometimes, very old and messy code bases.

Naturally, our role is often to rectify this situation: helping improve our clients’ technology ecosystem, and in so doing, enabling us – and them – to make improvements and drive positive technology change.

As experts in digital, we frequently take on the responsibility of choosing the tech stack for our client projects, advocating for what research and experience tells us is the best tool for the job.

With this authority comes a lot of responsibility. We cannot simply just chose the flavour of the month: we must do things with longevity in mind, accounting for the risks and rewards of our choices.

 

Where to start

The frontend landscape alone is vast and making a decision can be hard.

For example, there’s the React + Angular duopoly to contend with, and how do you avoid React? Or perhaps the client is using Knockout – so why switch? Or maybe a couple of the devs wrote a new framework: why not use that?! And let’s write VanillaJS, and do DOM manipulation ourselves…The list goes on, but the reality remains: choices must be made.

One of our client projects, for example, used an old jQuery implementation. It was ugly. It was messy. It was impossible to reason about…especially with multiple single files containing over 5000 lines of jQuery. Ugh. You literally could not read the file. It was time to act.

We had a set of key criteria in mind with whatever we did:

  1. We want it to perform.
  2. We want it to be reasonable.
  3. We want an ecosystem.
  4. We did not want to do any DOM manipulation ourselves.
  5. And, most importantly, it must safely sit side-by-side with other code.

 

How we found Vue

When searching for a framework that we didn’t have to arm wrestle with, we initially cast the net wide.

We started to do a ton of desktop research, looking with fresh eyes at what was out there. We’d had extensive experience with AngularJS and React, having written large single page apps in both. We knew we wanted something easy to work with, like AngularJS, but we didn’t want to work with JSX. We wanted some form of templating. (It’s HTML we want after all, isn’t it?)

 

 

We stumbled upon Stefan Krause’s JS web frameworks benchmark (screenshot above) the fourth edition, from Sept 2016: a real godsend for research, and indeed, a go-to-source for what’s happening in frontend Javascript Land. It proved the launch pad for further research.

This was way back when in 2016. We had AngularJS fatigue, JSX is ugly and Flux implementations were everywhere. Redux, yes – but it’s steep learning curve automatically deems it ‘complicated’. We wanted something different.

We were super impressed with Mithril.js but a comment by Stefan in the post announcing the earlier second edition of the benchmark popped out at us: “One of the vue.js creators contacted me and told me that they fixed vue.js in response to my benchmark”. That prompted us to look at the Vue 2.0 results in the fourth edition and wow: a major version update and almost the second most performant framework in the land. That’s how we found Vue.js – and now, we had to look closer.

 

What we found with Vue

What we found immediately impressed us. The documentation was excellent. The honest comparison with other frameworks was refreshing. The community was small and vibrant, but growing fast – in fact, Vue.js currently sits at more GitHub stars than React. That’s impressive, considering it has been around for a much shorter time than React. The flexibility and simplicity that Vue brings to frontend development has made it incredibly easy to adapt to any kind of application: modern or legacy.

A couple of specifics popped out:

  1. HTML templates | We like HTML. We like templates. We like HTML templates. JSX can make one squeamish at times. HTML templates feel natural.
  2. CSS, just plain CSS | CSS in Javascript, also can be awkward. Improvements have been made, but with HTML templates, it’s just CSS!
  3. Vue Router |  “With Vue.js, we are already composing our application with components…all we need to do is map our components to the routes.” POW!
  4. Vuex | For anyone who has worked on a large code base using Redux, it quickly gets complicated. Vue provides a simpler, more solid solution here.
  5. Single File Components | They wrap up all the good bits. They are just readable! They’re close to WebComponents and are easy to reason about. The syntax is, overall, pleasant.

Did we say single file components? Yes – single file components just make sense. HTML templates + scoped CSS + component Javascript. React can sometimes over complicated things, with JSX and the need for CSS in JavaScript. Let the tooling (vue-cli) do the work for you — take single file components, and translate them into components.

 

Vue code snippet

React snippet

 

Enter: Nuxt Brothers

And then the sugar came.

When Zeit Inc launched Next.js for React in later 2016, the two Nuxt brothers  — Sébastien Chopin and Alexandre Chopin — seized the great opportunity, Next for Vue: Nuxt!

Next, and then Nuxt, brought the first viable complete SSR (server side rendering) solution, for Universal JavaScript Applications: Nuxt for Vue.js. Combining a cli with webpack configs for dev and production, Nuxt “…presets all the configuration needed to make your development of a Vue.js Application Server Rendered more enjoyable.”

And with their static HTML generator nuxt generate we can now achieve extremely high performant headless web apps that are just plain ol’ HTML. With Nuxt 2.0 being around the corner, it begs the question: why couldn’t you build an complete commerce solution stack on this? Commerce engine, product catalogue, commerce content, personalisation…all generated to static HTML.

 

Choices going forward

We don’t always choose Vue, of course. We have a number of very successful projects running which use React, and it has served us very well. We are exploring Angular (without the JS) for some projects, and we write VanillaJS when needed.

But we choose Vue when we have direct choice, and can recommend something outside the React ecosystem.

 

Conclusion

Single file components sold us on Vue. But the ecosystem provides so much more: vue-cli, vue-router, vue-press, nuxt – the list goes on. The community has grown impressively: a number of our team attended the first Vue Conference in Poland and loved it, and we’re proud to support the Vue community with London’s very first Vue.JS conference this week.

Most importantly, we’ve been able to be incredibly productive using Vue. We’ve been able to introduce Vue safely into legacy code bases (even in situations where data is locked in JSPs), and  hae been able to make concrete demonstrable improvements to our clients’ technology situations by using Vue.js.

We’ll always consider Vue.js going forward for our projects.

Special thanks goes to Chris Wintle, who wrote up our very first independent client credential to provide the rationale for Vue.js use early on, and to Mike Pohlschmidt, who with me continues to advocate for Vue inside AND Digital and with our clients.

Read More From This Author

Share this blog post

Related Articles

Careers

We’re looking for bright, dynamic people to join our team!

Discover More Roles