In this blog i’m going to talk about my experiences on how I started doing front-end development as a back-end programmer and how a framework helped me transition from back-end developer to “full-stack”. The reason I use quotation marks at “full-stack” is because this term is a bit of a vague term. It’s a term which lost it’s value a bit because of it’s use. The framework that helped me is vuejs. So I will talk about some of the features of this framework that helped me and explain why they helped me.

Background

Lets start with a little history about me. My name is Mark van der Steenhoven, 25 years old and live in Amsterdam, and work for a company called DigiMonks. A company that focusses on Big data creation and analysis. I studied computer science for 4 years at the Hogeschool van Amsterdam, a study that only teaches Java as a programming language. Things like front-end don’t get attention and it’s kind of expected you to learn this by yourselves. With that being said, when I finished my study and started working at DigiMonks it was expected I also knew how to front-end since they also created dashboard etc. So it’s not hard to imagine I had a hard time with things like SSR, webpack, virtual-DOM and all the cool things in front-end world. I found myself looking for a structured way to front-end. I’ve never liked jQuery for a variety of reasons. One of them, because I was never any good at it, the code became messy and when the DOM changed my script would break ( We’ve all been there ).

How I started using Vuejs

My first contact with anything a like framework was Facebook’s React, which looking back, might have been a bridge to far to start with. It’s not so much a framework but a library. It gives a lot of flexibility and a wide variety of tools to accomplish the same thing but in a different way. Managing state was done with Flux, Redux, or react-easy-state or… some other npm package. You see my problem here? I had no idea what to pick at the time, things like a store were new for me so I quickly grew tired of the endless options I was being served. Boilerplates I found on the internet differed so much from each other I was missing structure and quickly felt bloated. If you are experienced it’s perfect, it empowers the programmer with full control over it’s application. But, this is not what I needed at the time.

Next up was Vuejs, our company uses Laravel so I quickly came in contact with Vuejs since the Laravel community adopted this to be it’s framework of choice. My first application I had to work on was a one page application. With SSR the need for a store and a router. I was being thrown into the deep from the start. But the base of the application was already written so I only had to find out how to work with it. This was remarkably easy.

Why? Vuejs has it’s own community and at the time, SSR was done with Nuxtjs. A framework inspired on Nextjs. A store was mostly done with Vuex, a state management library which is inspired by Mobx. The difference is, Vuejs adopts these tools so well, it’s almost like they are part of the framework. So my thought at the time was: “well, I guess these are the tools I should use.” And looking back, I think I was right. But to keep it simple, during this blog i’ll only discuss Vuejs. If I get requests to also write about Nuxt and Vuex I might write about it some other time. Since this is not a blog about how to get started with Vuejs, i’ll just talk about some features that helped me a lot without going in to deep. Just so you get an idea how and why these specific features helped me.

Everything has a place, vue components.

Component based front-end developing is a way of writing your application. it’s a way to create reusable parts in your front-end application that receive properties and use these to show or fulfill some sort of behaviour without knowing the context they are being used in. (Correct me if i’m wrong ). The way components in Vuejs are structured is amazingly easy.

<template>

<div>

<div class="someClass">

{{someData}}

{{fullname}}

{{numberToBeIncremented}}

</div>

<button @click="increment">increment</button>

</div>

</template>

<script>

export default{

props:['somepropertie'],

data() {

return{

someData: "this is a data field",

firstname: "mark",

lastname: "steenhoven",

someApiResponse: []

numberToBeIncremented: 0

}



},

methods:{

increment(){

this.numberToBeIncremented += 1;

}

},

computed:{

fullname(){

return this.firstname + this.lastname;

}

},

async mounted(){

const response = await this.$http.get('http://domain.com/some-api/posts')

this.someApiResponse = response.data;

}





}

</script>

<style scoped>

.someClass {

background-color:red;

}

</style>

This code represents a vue component with the features I use the most. It starts with a template tag, here we write our html elements and show the data or state of the component, why I think this is a big plus is you can just write your html almost like you are used to. The second thing I noticed is everything has a place where it should be. Functions that are supposed to do things triggered by a user interaction or changing some data attribute are put in methods. Things you’d like to map, or mutate for a specific visual display like parse a date to another format go in the computed object, mounted is the place where we fire of our API calls and place the response in a data object. Mounted is part of the components lifecycle, you can read more about this in the docs but this is the place where you would want to do your API calls because it’s the moment the component is already rendered in the DOM. Properties passed by a parent component go in the props attribute. The data attribute is a function that returns an object. This can be used for a wide variety of things, it can be used to fill a component with some default data. copy the response of API call and pass this to a child component among other things. Last but not least, we have the style tag. It’s where you would write your styling (duh). What makes it special is you can make the styling scoped. Which means that the classnames, stylings or whatever you want to do styling wise is isolated within this component. The structure of these components is so well documented and because Vue components always have the same structure, it’s also is easy to transition from project to project.

2 way binding with v-model

In a lot of cases you want keep track of data which is changed in some sort of input field. V-model is a bit magical but it’s a way to create a two-way data binding on inputs, textareas etc. This makes it easy to keep track of current data in for instance a form.

And as you can see it is something that’s easy to use, i’ve used ( and misused) for loads of things. It makes it easy to keep user input in sync with your state. This is one of the things you now don’t have to worry about when using Vuejs.

Easy to implement in existing applications

Another thing i’d like to discuss, is the the way you can use Vuejs in already existing applications. At the company I work, we used a lot of jQuery. And I found myself struggling with this. So what I tried to do was implement Vuejs for small things like a form with some elements that appear and disappear based on some input. The vue application was sometimes one component, or one or three. But even for these small features in an already existing system, they became fun to write and easy to implement. Now I don’t know how this is done in React or lets say Angular, so i’ll just discuss the way Vuejs does this. If you’re using angular or react, you might say “that’s also easy with the framework I use!”. Which is good! I’m just here to talk about how vue in this case helped me.

<script>

import Vue from 'vue'

import SomeComponent from '~/components/SomeComponent' new Vue({

el: "#app",

render: (h) => h(SomeComponent)

})

</script>

In this code sample we create a new instance of Vue, I gave this instance the element in the html it should mount on. In this case, an element with “#app” as it’s id. And we give it a render function with the component we would like to render. When you’re using Vuejs in an existing application, this component will often be the root component where other child components are used. And that’s all there is for using it in an existing application. Easy right? If you’re a programmer you’re probably going to work in applications that you have not written. This is one of the reasons why Vuejs made me so happy with how easy this is to implement in existing applications. I don’t have to worry about css classes I have to give to certain elements. I can just write my own isolated application within in the already existing dashboard or website.

Data driven

Last but not least, and this is not something specific to Vuejs, but to almost any front-end framework, is that they are driven by data, not by the structure of your DOM. When this data changes, so does the visualisation of this data. If a list has 10 items, and one is removed in jQuery or plain javaScript we’d have to remove this from the DOM ourselves with a query selector. Performance wise, it is expensive to alter the DOM. That’s why Vuejs and react use a Virtual DOM. A virtual DOM is a representation of a html file in javaScript.

// An unordered list represented as Javascriptlet

domNode = {

tag: 'ul',

attributes: { id: 'someId' },

children: [ // where the LI's would go ]

};



In this way, we can use the DOM API directly from our code. Updates performed are done to the javaScript object, which is cheap. After the virtual DOM has been changed, a sync is performed to sync the virtual DOM with the actual DOM. After this sync, only the elements that have been changed are rendered to safeguard the performance of the application. If after this you have no idea what I just said, i suggest you read up on it since it’s a quite interesting feature to know about.

Conclusion

When I started front-ending I struggled with jQuery cause working with the DOM using query selectors is just not a way your front-end becomes sturdy. The work I delivered was just not good enough. This is the reason I started looking for frameworks that would hopefully give structure. Vuejs was the framework for me, the components are logical and easy to understand. V-model helped me with keeping my users input in sync with my component state, although a bit magical I did not have to worry about this anymore. Last but not least, I needed something that was easy to implement in already existing applications. In my opinion, Vuejs is strong in this aspect. And one of the things that was not specific to Vuejs but I loved the fact the frameworks are data driven. If the API you wrote is good and consistent you can now trust your front-end implementing it in some visual aspect to do as expected and trust that as long as the API does not change, it won’t break. An added bonus is the virtual DOM that also improves the performance of your front-end application.

Wrapping it up

In this blog I talked about what struggles I had as a back-ender who had to work on the front-end. And how I ended up with using Vuejs as my framework of choice.

I talked about some of the features that helped me the most. This to give you an idea of what made it so easy for me to quickly transition from the back-end and become the front-ender I wanted(had) to be. I hope that after reading this blog you get a sense of the transition I went trough and helps you if your currently in the same process as I was. Or if you are a back-ender that wants to do front-end, to give you a sense of where to start!

Thank you for reading and I hoped you enjoyed the first blog I’ve ever written. And if you’d like me to write more about Vuejs, nuxt, vuex. Leave a comment!