Category Archives: Javascript

Get More Done with Vue.js: Vue and Performance

Vue is fast

In this lesson, we’re going to look at a very important topic in the development industry today, performance. If you’re a front end developer, you should be concerned about performance when it comes to public facing websites. So how does Vue.js compare with other modern front end frameworks and what features does it have that we can take advantage of to improve performance in our webapps? Continue reading

Get More Done with Vue.js: You Can Do More with Vue

You can do more with Vue

My third lesson on Vue.js focuses on it’s flexibility. Vue is simple enough for you to start writing components with HTML and plain JavaScript. But Vue was also designed with flexibility in mind. This means you are not just limited to creating components with HTML and plain JavaScript. Vue has an official Webpack loader for Vue components called vue-loader that enables support for ES2015. If you prefer to use TypeScript, Vue has official type declarations for TypeScript for Vue core, as well as vue-router and Vuex. Continue reading

Get More Done with Vue.js: Get Things Done Faster with Vue.js

Get Things Done Faster with Vue.js

My second lesson on Vue.js is focused on it’s simplicity. I think one of the things that makes Vue.js very appealing is it’s simplicity compared to other front end frameworks. To get started with Vue, all you need is familiarity with HTML and ES5 JavaScript. Anyone with these skills can start “building non-trivial applications within less than a day of reading the guide” (according to the documentation). So how does Vue’s simplicity compare with other popular front end frameworks? Continue reading

Get More Done with Vue.js: What is Vue.js?

What is Vue.js?

Welcome to my first lesson on Vue.js. This is the first post in a series on Vue.js that I will be posting over the next few weeks. This post is designed to introduce you to what Vue.js is and how it works. Let’s get started!

Vue is a framework for building user interfaces, similar in many ways to another JavaScript library called React. As UI frameworks go, Vue is designed to be simple and flexible with a heavy focus on performance. Because of this, Vue can be implemented incrementally. The core library of Vue is focused on the view layer only, so it can be easily integrated with other libraries or existing projects. One of the things that makes this possible is the size. Full-featured and minified Vue 2.0 with compiler included is only 23kb. However, Vue is also powerful enough, when used in combination with a tool chain and supporting libraries, to build full featured Single-Page Web Applications. Continue reading

npm and Small Focused Modules

A lot of discussion has been happening around npm and it’s vulnerabilities since one module being unpublished about a week ago caused problems for lots of developers and their teams. Sindre Sorhus, a prominent developer and publisher on npm, wrote about why he thinks we need small reusable modules, like the one that was unpublished last week. You can read his thoughts on this here. You should read the whole post, but here is a snippet that sums it up.

People get way too easily caught up in the LOC (Lines Of Code). LOC is pretty much irrelevant. It doesn’t matter if the module is one line or hundreds. It’s all about containing complexity. Think of node modules as lego blocks. You don’t necessarily care about the details of how it’s made. All you need to know is how to use the lego blocks to build your lego castle. By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works. Our short term memory is finite. In addition, by having these modules as modules other people can reuse them and when a module is improved or a bug is fixed, every consumer benefits.

Strong versus Loose Typing in JavaScript

Being a long time JavaScript developer, I’m perfectly happy with the fact that JavaScript is loosely typed. I think the reason strong typing in JavaScript is gaining in popularity is because more and more developers are using JavaScript that are used to programming in strongly typed languages. So there’s no reason for me to use something like Typescript that adds static typing to the language. Anyway, I came across this quote from Douglas Crockford in his book, JavaScript: The Good Parts, which explains my feelings on the subject better than I can.

The fashion in most programming languages today demands strong typing. The theory is that strong typing allows a compiler to detect a large class of errors at compile time. The sooner we can detect and repair errors, the less they cost us. JavaScript is a loosely typed language, so JavaScript compilers are unable to detect type errors. This can be alarming to people who are coming to JavaScript from strongly typed languages. But it turns out that strong typing does not eliminate the need for careful testing. And I have found in my work that the sorts of errors that strong type checking finds are not the errors I worry about. On the other hand, I find loose typing to be liberating. I don’t need to form complex class hierarchies. And I never have to cast or wrestle with the type system to get the behavior that I want.

Unit Testing Ajax with Sinon.js and QUnit

I’ve done unit testing with JavaScript using QUnit, but I’ve never tried writing unit tests for Ajax. I recently learned about Sinon.js however, and that has taken unit testing in JavaScript to a whole new level for me. By default, Sinon.js doesn’t work with QUnit, but fortunately you can add another script to make it work.

While attempting to write unit tests for Ajax, I had trouble finding good information. I actually found the solution in the Sinon.js docs. The secret to unit testing Ajax is not spies, stubs or mocks that are available in Sinon.js but the Fake XMLHttpRequest. This allows you to test Ajax calls and callbacks without making actual Ajax requests. The following test passes in QUnit.

test("ajax tests", function () {
    var xhr = sinon.useFakeXMLHttpRequest();
    var requests = sinon.requests = [];

    xhr.onCreate = function (request) {
        requests.push(request);
    };

    var callback = sinon.spy();

    $.ajax('/some/article', { success: callback });

    equal(sinon.requests.length, 1);
    equal(sinon.requests[0].url, "/some/article");

    requests[0].respond(200, { "Content-Type": "application/json" }, 
'[]');

    ok(callback.called);
});

You can see the code working here in jsfiddle. As you can see, the Ajax request was called with the right url. With the respond method, we were able to make our fake Ajax call return a 200 code so that the callback will be run as well. The trick is calling the respond method every time a request is sent. You just have to increment the number of the array item.

Here I am only returning an empty array because I couldn’t get the code to work in jsfiddle, but you can control what data is returned by the Ajax call, as well.

That’s it. I didn’t go into detail here about how QUnit or Sinon.js work, so you will need to check out their respective documentation if you are wondering about that. Unit testing Ajax is just one of the benefits of Sinon.js. If you aren’t already using it, I recommend that you do.