My first impressions of Vue & Nuxt

Colin Wren
4 min readMar 21, 2021
Photo by Evie S. on Unsplash

I’ve recently picked up a project which has been written in Vue 2 & Nuxt and I thought I’d document my initial impressions in the hope of doing a follow up in a couple of months time to see if my gut feeling holds true.

For context, I’ve got about 4 years of working with React and React Native in various different professional and personal capacities so this does influence how I feel somewhat.

I’ll try to stop this post from becoming a Vue vs React one but I won’t deny that some of my love of more immutable & functional code comes from working with React.

This post won’t be a deep dive into the inner workings of either technology, nor will it be that structured. I’m writing this to capture my initial thoughts, so don’t expect to learn much.

Components

I remember many years ago when web components were emerging I watched a video from Google about Polymer and how the HTML, CSS and JavaScript would all be combined in one class and thinking about how amazing a solution it was.

Previously I had written Styleguides with tools like KSS and got tired of having other developers take my examples, butcher them and then complain that things didn’t look right and I thought web components would solve all these issues.

With a lot more experience under my belt I no longer think defining CSS in your components is a good idea (I’m ok with importing) as this mixes the concerns of structural and presentational logic.

The coding standards of the Vue codebase I’m working on state that all HTML, JavaScript and CSS need to be in the one file but this isn’t an issue with Vue itself as I understand these can be separate.

However, it feels backward to me that you define your mark up which can contain HTML, other components (who’s name changes case between definition and use) and presentational logic ( v-if etc) and then you define the script which returns the data that template will use.

This approach means I have to translate my component’s data definition into what will be rendered, jumping through logic within the component’s template to get a better idea of the final output.

It may be there’s a design pattern I don’t know about which will give me a more functional syntax but for now I can’t say I find Vue’s component structure easy to work with.

State management (Vuex)

While Vuex isn’t a first party library of Vue it’s something that I think a lot of Vue developers work with so I think it’s worth covering as I have a few gripes with it.

The first thing that really stood out to me about Vuex is the fact that state is mutable and while I understand that you don’t call the state mutations directly, the fact that you’re directly updating state instead of creating a new object doesn’t sit well with me.

This mutable state has led to a number of discussions around unit testing as it was common for people to create a mutable state object, pass this into the mutation to update it and test the expected state value was updated.

This test approach however does not detect unwanted state mutations and I can’t help but think if the state updates were immutable that this wouldn’t be such an issue.

I do like the term ‘getters’ for reading values out from the store though as it feels a lot more semantic than the term ‘selectors’ that Redux uses.

Nuxt

So far I find Nuxt ok but I guess this is mostly due to the fact that I’ve not had to do too much with it but there is one thing I’ve yet to really understand the need for — modules.

The code base I work with has 3 different APIs it needs to communicate with, each with their own credentials for authentication and while in something like React I’d have created an API module with functions for handling calls to these APIs it appears in Nuxt the approach is to use this.$axios everywhere.

I guess this is similar to my issues with mutable state in Vuex but something doesn’t feel right about using this.$axios as I can’t guarantee what state it’s in before I use it.

Summary

These are just my initial thoughts on Vue and Nuxt and it’s likely my opinion on some aspects will change as I learn ways of working with these technologies in a manner that I’m happier with.

For now though I would say I very much prefer React to Vue.

--

--

Colin Wren

Currently building reciprocal.dev. Interested in building shared understanding, Automated Testing, Dev practises, Metal, Chiptune. All views my own.