20 Jan

VueJS: First Impressions

With all the new libraries and frameworks it is pretty hard to keep up with all of them, and that is if you can even decide which ones are worth spending time one, over the last year or so I was exposed to many a new tech stack, with React for work and just personally playing around with React-Native, Aurelia and Angular2. Each of them attached to a new project, partly justified by wanting to try it out or form my own opinion.

Previously I had written about Aurelia, which I was very impressed with after than Angular 2 disaster, if you like, you can read more about it here:

Aurelia: First impressions

This time round I decided to dive into Vue.JS, a lot of good things are being said about it on the web, with it apparently being faster than react, with it’s implementation of Snabbdom, a simple and powerful Virtual DOM focused on performance. On top of that is is notably smaller than React sitting around 14kb.

Of all the frameworks and libraries I have worked with over the years, one thing that stood out to me about Vue.JS was the documentation, very detailed and easy to follow, covering multiple use cases and all the various options, where applicable, for each of it’s built in methods.

Now for a look at the code, the following example is for a very simple component, written in absolute bare-bones, just for you to get an idea of how things are structured..


Vue.JS uses a template file containing both you template body and a script section, and these files are saved with a .vue extension.

Vue.JS itself is completely template agnostic, you can use handlebar/directive template as above, you can also use JSX, or even build it up very manually using es5 or es6 string interpolation if you prefer.

This file pretty much handles it all, you will define the HTML structure as well as relevant scripting logic, and either define a <style> block or import a style sheet like in the example.

The script tag is where all the real work begins, we start by importing Vue and whatever components we intend on using within the component.

name: 'Events', components: { 'header-bar': Header, 'search-bar': Search, 'list-data': List, 'footer-bar': Footer, },

Above we have a snippet from the default export object, we start with the components name, followed by a components object. This object defines a key which is the tag name for the HTML element within our template with its value being the component we imported a little further up.

Next we have some of our methods to control initial logic and define usable functions.

data() {  return { data: [], searchTerm: {},  }},

The data() function is used to setup default data for initial rendering of the component, here the data key is setting itself as an empty array as later when we fetch the data it will become and array of objects, and we do not want to break the render by defaulting with invalid data types.

created() {  // API/Service calls would go here  return { data: [ {}, {} ],  };},

created() is similar to reacts componentWillMount life cycle method, this is the best place within the life of the component to go fetch any data that is not available on initiation of the component, in this case to go fetch the actual list items.

methods: {  search() { // Search method written here  },}

methods() is where you define functions that will be used within the component itself, or passed down to a child component as props, as is the case with search(), the child Search component will receive this method via the props, and this will then be fired off when a user interacts with the search component.

One thing that was not specifically included in the example but was was referenced was props, like react and probably many other libraries at this stage, Vue.JS also supports props, and like react they can be anything that a child component needs, be it static text, a function, and array of data needing to be looped over, or an object with key value pairs for simple dynamic display.

Props are quite simple to define, within the default export you would add another key, called ‘props’ with an array of all the props it is expecting to receive.


Above would then be an example of the search component, as you can see it is taking in 2 props, the submit method and term, which is a model for handling the search value that will be passed into the function.

This was just a taste of what is possible with Vue.JS, you will see many more examples by visiting their documentation at Vue.JS docs.If you wish to quickly spin up an application and start playing around with Vue.JS, I can suggest taking a look at the Yeoman generator created by FountainJS.

Working with Vue.JS was a great pleasure, I found the learning curve very shallow, however that could purely be based on my experience, as mentioned before I have worked with a few in the past.

The default template structure feels very similar to how it was working with Angular, so developers coming from that background may pick it up a bit faster than they would react. I cannot really go un-learn react to see if it influences how easy it was to pick up Vue.JS.

VueJS: First Impressions was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.

11 Nov

Aurelia: First impressions

Recently had a small personal project that I wanted to rebuild, a project I had initially started quite some time back using AngularJS 1.x, but had never gotten around to finishing it.

Since then, there have however been countless changes in the Javascript world, with ES6 and all the new frameworks available, it seemed a better idea to simply start over with something newer. My first consideration was React, as currently at work we are developing with it, and I had recently used React Native to build a mobile application, it seemed the logical choice, also in part as it is to be the web version of the mobile application, Lusus.

Then I remembered that Aurelia, something that was on my 2016 ToDo (learn) list, and being both a small and personal project, there was no harm in trying something new, not like it had any actual deadline. Worst case scenario, I dislike the framework, formed a valid opinion and can try something else.

Having worked with both AngularJS 1 and 2, I was not really sure what to expect from Aurelia, it was the idea of Rob Eisenberg as he was not happy with the direction the team was taking with Angular 2, and personally neither was I, quite frankly I found it to be a horrific disaster, but that is my opinion…

Starting off could not of been easier, a quick spin up of the Aurelia skeleton navigation application, ES6 flavor of course, and I was off.

My zero second impression was confusion, expanding the ‘src’ folder in Atom to find a mess of files with no apparent structure, which is not something I am used to, but very easily rectified to my personal preferences.

Having read none of the documentation, watched no online tutorials and effectively going into the framework all but blind, I expected just jumping in to be more difficult than it was, it however felt both familiar and different at the same time.

From AJS 1.x I would have to say some of the more menial things have been simplified, including modules/components is a simple require tag.


If you take a look at the block above you will see 2 ways of including a component, the first could be considered a ‘smart’ component which contains a view with logic, where both files share a name and only differ in extension.

Second would then be ‘dumb’ or a simply view component, containing no logic.

Rendering those imported components are just as simple, following the same convention as your file name.


Binding logic to your components is almost intelligence in the way it wires everything together, firstly you do not actually need to specifically reference the JS file within your component, everything is wired together with the extension-less ‘require’.

This does mean however that there are some rules around naming your files/classes. File need to match, and class names need to be the CamelCase version of the file name.

For data binding, you simple need to import ‘bindable’ module, declare your binding reference, and add in an optional change handler, useful if you need to do any modification to the data for view purposes, like date formatting.

There was definitely some learning that had to happen, but I would have to say that this is how I would have imagined AngularJS 2 to have turned out.

This is not to say that Aurelia is perfect, and maybe I still need to do some additional learning, but I found it’s error logging and failure handling a bit too graceful and silent. No errors are logged to the browser console when you made a typo for example, so you will make a change, things do not line up and the application just sits there in the browser in a state of limbo with no indication as to what is wrong, not even a useless message like ‘error’ shows up.

API Call fails and you have not written specific handling for it, it either returns to the previous view, or hangs again without any indication, this could of been intentional as well really should be handling errors ourselves, but I still feel it is a bit too graceful.

Also just really silly, with the build in gulp processes, the build which is used for dev minfies the index.html, but the export (production) step does not, not even 10 seconds to fix it, but still funny.

All in all, anyone coming from AngularJS 1.x looking to move into the next generation, I would highly recommend Aurelia over Angular 2.x, there is infinitely less stupidity and bad decisions in Aurelia, and a much stronger familiarity.

VueJS: First Impressions