{"id":13844,"date":"2016-07-06T12:15:25","date_gmt":"2016-07-06T09:15:25","guid":{"rendered":"https:\/\/www.webcodegeeks.com\/?p=13844"},"modified":"2016-07-05T23:16:36","modified_gmt":"2016-07-05T20:16:36","slug":"consider-vuejs-next-web-project","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/javascript\/consider-vuejs-next-web-project\/","title":{"rendered":"Consider VueJS for Your Next Web Project"},"content":{"rendered":"

Whether or not you\u2019ve ever heard of VueJS<\/a> before, never fear. I\u2019m here to share some insights on how and why we at Codeship used this \u201cnew\u201d library for our Docker-builds UI, Jet<\/a>.<\/p>\n

What Is VueJS?<\/h2>\n

To get a rough idea of what Vue (pronounced \u201cview\u201d) does, think about it as the \u2018V\u2019 in an MV* pattern. If you\u2019d like to compare it to something else, it\u2019s probably closest to React<\/a> but with a far lower barrier of entry. No need to learn something like JSX<\/a> or pre-compile files just to give it a try. Drop it into your HTMLs header like any JS library, and you\u2019re all set. Templating will probably look familiar to anyone who has worked with Angular or Mustache in the past.<\/p>\n

So let\u2019s talk about what made VueJS so attractive for us at Codeship.<\/p>\n

Data-driven versus DOM-driven UIs<\/h4>\n

Separation of concerns is a common term in software engineering. Yet when it comes to UIs, we see code like this all too often:<\/p>\n

function textReturningFunction () {\r\n  return 'Hello World!'\r\n}\r\n\r\n\/\/ Set some text in jQuery\r\n$('.someElement').text(textReturningFunction())<\/pre>\n
I wrote JS like this for a long time early in my career. But if you think about it, this code is pretty far removed from the idea of separation of concerns.<\/p>\n
The JS has to know a lot about your markup and the general structure of the DOM. At any given time when the markup changes \u2014 .someElement<\/code> gets renamed to .some_element<\/code>, for example \u2014 your JS will break. The function that\u2019s actually returning the data we want to show did not break though. It\u2019s still returning Hello World!<\/code> when called. In this instance, the data is the same, but the binding is broken. This happened because the JS is DOM driven.<\/p>\n
Let\u2019s look at a simple VueJS instance that should print out the same text as above.<\/p>\n
The Markup:<\/strong><\/p>\n
<div class=\"app\">\r\n  <span class=\"someElement\">\r\n    {{ msg }}\r\n  <\/span>\r\n<\/div><\/pre>\n
The JS:<\/strong><\/p>\n
new Vue({\r\n  el: '.app',\r\n\r\n  data: {\r\n    msg: 'Hello World!'\r\n  }\r\n})<\/pre>\n
The Vue instance is a simple object. Running this code will do the trick, and you\u2019ll find <span class=\"someElement\">Hello World!<\/span><\/code> on the page. If the class on the span<\/code> would change now, it will not break the JS because the class is not referenced.<\/p>\n
To stay true from the start, we still referenced an element in our Vue instance. The .app<\/code> element is the entry point from which Vue will handle things. If that one gets changed, the reference needs to be updated as well.<\/p>\n
Reactivity<\/h4>\n
All variables in Vue are reactive. This means they are observable and can have watchers attached. Variables that change will automatically inform their peers of the change. On the VueJS side, there\u2019s actually a very detailed description of this system<\/a> that I highly recommend you read.<\/p>\n
For quick understanding, compare Vue\u2019s behavior to dirty checking in Angular. If something changes in Angular, it\u2019ll start to search for that change. It\u2019ll compare new values with old until no more changes are found, and it will update what\u2019s necessary. This takes time and eats up resources while correlating with the complexity of the application.<\/p>\n
A reactive data system like Vue uses may need more initiation time upfront, but that\u2019s a good price to pay.<\/p>\n
Components<\/h4>\n
Vue\u2019s flexible but simple system is built around the concept of components. Components are small, reusable parts of the UI. Actually, this should be nothing new \u2014 the majority of JS frameworks these days are built around that concept. Web Components are a known solution for quite some time now. The problem is always the browser-wide implementation.<\/p>\n
Vue takes care of this by providing a browser-independent component system. This system is straightforward to use and falls in line with the rest of Vue\u2019s structure.<\/p>\n
!New Call-to-action<\/p>\n
Why We Chose VueJS<\/h2>\n
Inside the Codeship application, we have one high-load and interaction-heavy page: It\u2019s the build detail page of our Docker-based build infrastructure (Jet<\/a>), letting the user read terminal output. The challenges of this page after the initial release included:<\/p>\n