Why We (Too) Choose Vue
19 September 2018 |
Artiom Nistrean | About a 6 minute read
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:
- We want it to perform.
- We want it to be reasonable.
- We want an ecosystem.
- We did not want to do any DOM manipulation ourselves.
- 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?)
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:
- HTML templates | We like HTML. We like templates. We like HTML templates. JSX can make one squeamish at times. HTML templates feel natural.
- 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!
- 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.
- 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.
Enter: Nuxt Brothers
And then the sugar came.
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.
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
AND Digital Places 23rd In eConsultancy’s Top 100 Digital Agencies Report
AND Digital’s Flagship Learning Conference Returns For Its Third Year
Waterfall Vs Agile: Which Methodology Is Right For Your Organisation?
React Native Engineer (London)
Champion software quality and technical vision for AND and our clients, work on large-scale projects and help junior and mid developers grow in their roles.
Technologies you will be using
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested
DevOps Lead (Reading)
Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.I'm Interested