How to try new things, the right way

Not too long ago we needed a new way in our business to manage some repetitive and complicated tasks which can only be done by a database or backend developer. And what better way to not repeat something every 2 months than to spend weeks on building an application for it?

No no, that’s not what we did. But I did have 2 days with slightly less on my plate, so it was the perfect chance to try out VueJS.

Because we want to be certain the option we go for is the best one, we need to try and compare said things. How do you measure two competing technologies, frameworks, methodologies etc.?

Timebox it!

Depending on your own circumstances, choose a period of time of a few hours or even days (or more?). You need a quick plan on what you want to do.

Try each of those technologies (or what ever it is) and see how far you get. That has the added benefit of showing you how quick and easy it is to learn or if the documentation is right and complete.

My experience

I needed to compare VueJS and see how quickly I can become productive with it, versus Angular.

I decided to give it 2 hours maximum for each and my plan was to simply send an Oauth login request.

If successful, save the token, then call an API to get a list of objects. Then I would display said list.

Sounds easy enough!

My experience at that point with VueJS was practically 0, while I had used Angular quite a lot.


I discovered that VueJS is superbly documented, there is a helpful community and it’s easy enough for a beginner to actually do something useful on day 1.

I also discovered that Angular is complicated and unpleasant to work with. Something I already knew 🙂

They are both good frameworks and this technique worked for me: I decided to use VueJS in the future (and I have) and to reduce my reliance on Angular. With less than 2 hours spent I was confident of a new framework, while not having wasted weeks on the wrong technology just because I read about it on a blog (the irony…).

What will you try next?

VueJS, Angular, React? What should I use?

Alright, alright!

Yes, there are so many posts about these 3 frameworks that you want to roll your eyes.

I searched and read about each of those, made trial projects, read comparisons and opinions, read about pros and cons and so on.

And yes, I did not find the answer I was looking for!

So, we’re talking about eye rolling: well, don’t do it just yet, cause we’re doing it better. Where everyone says “your mileage may vary” and there “isn’t an easy answer”, we say: yes, there is an easy answer. In fact, there are many easy answers.

Because you’re reading this, I will assume you already know what these frameworks are, but a very short summary is welcome:


And we’re talking Angular (not AngularJS). This framework started in 2009 which is really lovely. Has too many features built in (why do I need everything including the kitchen sink for every project again?).

The latest version has lots of cool features, new RXJS and new syntax (yey!).


  • Great documentation (which is the length of a long novel).
  • Two way data binding (which is a con if you ask my colleague). I’m undecided.
  • Modular.
  • Backed by Google who don’t really use it in their projects (much). How about eating your own dog food?


  • Too big.
  • Complex syntax.
  • Two way data binding?


React is a JavaScript library for building user interfaces. It is maintained by Facebook and a community of individual developers and companies. React can be used as a base in the development of single-page or mobile applications. (thanks Wikipedia)

So the good parts

  • Really flexible, you can do what you want with it.
  • Downward data binding.
  • Light weight.
  • Easy migration.

And the bad parts

  • Really flexible, meaning it’s easy to make mistakes.
  • Little documentation, meaning it’s difficult to keep track of changes and do things the right way. If there is one.
  • Not easy to learn.


And last but not least


Vue.js is an open-source JavaScript framework for building user interfaces and single-page applications.

Pretty much the same thing as the other two, but this one is not backed by a very large company.


  • Takes the best of both Angular and React.
  • Very good and detailed documentation.
  • Easy to learn and quick to get productive with.
  • Very small (20KB).


  • Not a very large market share. Although, Github stars are plenty.
  • Not backed by a company (although there is a large community behind it).

Phew, that summary is not very short.
Alright then, enough stalling, here are answers and questions (send yours, we’ll add them to the list)

I am a developer and am looking to make sure my skills are relevant.
Well then, React is the most sought after(70-80% of jobs for front-end mention it), followed by Angular. So if you want to find a job easy, there’s your answer.

I despise large companies who don’t pay their fair share of taxes and abuse their power.
Well then, use VueJS.

I want to rip my hair out because of two-way binding which causes a lot of issues and bugs.
Don’t use Angular.

I want to use a framework that’s quick and easy to learn.
Try VueJS.

I’m part of a very large team.
The decision is already made, isn’t it?

I have no clue what I should try.
Try them all or email us with questions

You get where this is going? There are answers for all questions. If you want to use one and not the other, do it! Don’t spend weeks analyzing things in too much depth. Jump in the deep end. You will quickly find out if that framework does not agree with you.

PS: We’re not saying don’t do research and spend your investors’ money trying out things.

Understanding Angular JS promises

Promises are one of the most powerful concepts for Angular and JavaScript. They enable your application to perform other tasks while waiting for the result of another operation. According to the official documentation, A service that helps you run functions asynchronously, and use their return values (or exceptions) when they are done processing.

When do we use promises?

When we need to make a request, load some data or perform some other sort of operation, but we don’t know when / if we get the result.

There are three possible outcomes to making a promise request. First two are a promise that was fulfilled : Success, we get the expected result OR Error, we get a false of some sort.

The final option is the promise was rejected, an error was thrown.

This is all fine, but personally I’ve had a few issues first understanding promises, so let’s try to explain these in a simple way:

Promises and your tax return

Since the new fiscal year started, let’s do a tax return story.

We need to submit our tax returns, so we do this by using an accountant.

We get all our documents and then we give them to our accountant. She promises she will get the outcome in 3 working days.

That’s our request done and since we don’t just hang around the accountant’s office, we can do all sorts of other things, since the request is asynchronous.

So a few days later we get one of the possible outcomes from the accountant:

  1. The accountant says all documents are there, your tax return has been submitted, so we have a success.
  2. He tells us not all documents are here, some are missing and we need to fix it first, so we have an error, but a proper response from our request.
  3. The accountant has taken all our documents and those of other clients, emptied their bank accounts (not ours, phew…) and left to a third party unnamed tropical country without an extradition treaty to enjoy the illegal proceeds and have a relaxing life 🙁 ohhh…. So we don’t even get a reply to our request… plus… we don’t have copies of our receipts! Ouch…

Hopefully that clears it up a bit. But let’s look at some actual code.

Here are the controller and the service:


//function in accountantController.js
var startAccountantPromise = function() {
    //Imagine we have an accountantService somewhere that handles the requests and other operations.
    //This function returns a promise which we will deal with here    
        // then() - this function is always called when we get a response
        .then(function(data) {
            // our promise was fulfilled. We don't know which of the possible outcomes though, so we need to check
            if (data.taxReturn === 'accepted') {
                //weeeee, all good, so we... get on with our lives
            } else {
                // since the status is not 'accepted' it can be other stuff so... we need to check for missing documents
        }, function(error) {
            //the final option is the promise was rejected, caused by some sort of error
            //we can log to the console like this : console.log('error', error);

So that’s the controller, but that uses some functions that we need to see.


app.factory('accountantService', function ($http, $q) {
    return {
        submitTaxReturn: function() {            
            //the $http API is based on the deferred/promise APIs exposed by the $q service and it returns a promise by default
            //documentation here :$http
            return $http.get('')
                .then(function(response) {
                    if (typeof === 'object') {
                    } else {
                        //oops, invalid response...
                        return $q.reject(;
                }, function(response) {
                    //something went wrong, where is our accountant?!?!?
                    return $q.reject(;


Hopefully this little story demonstrated the asynchronous nature of the request we make. We don’t need to wait at the accountant’s office, we can perform other operations in the meantime.

When we give our documents we immediately get a promise, so we expect to hear back at some point.

The accountant is dealing with our request and all the operations on that end are abstracted from us as financial stuff is wizardry. We don’t need to know how the stuff is resolved, we only need to hear back the result.


Angular JS, Understanding $emit, $broadcast and $on

In late 2015 I started working with Angular JS as part of a project at work (Hybrid mobile app).

Understanding the concepts is quite important to make use of it in an efficient and extendable way.

Angular JS provides us with some events that we can use to communicate between controllers.

They are $on, $emit and $broadcast.

Here is a quick schematic on the direction of the events.


When using $on, Angular listens to an event of a given type. We can call it anyway we want. $on will catch any event dispatched by $emit or $broadcast.

Real life example from a hybrid app:

$scope.$on(AUTH_EVENTS.notAuthorized, function(event) {
 //do something to block the unauthorized page view attempt

(AUTH_EVENTS is a constant we are using in our app)

So what happens and how / where does this happen?

In an authentication service, the user is checked if logged in. If he / she is not, we will emit an event which will block the unauthorized page view.

So we need to broadcast this event:

$scope.$broadcast('AUTH_EVENTS.notAuthorized', { ... });

Since we mentioned broadcast, let’s quickly go through that.


Broadcast dispatches an event name downwards to all child scopes (and their children) notifying the registered $rootScope.Scope listeners.

$broadcast(name, args);

The event cannot be cancelled. The event starts at the scope on which $broadcast was called. All listeners for the event get notified, all events under the scope.


 is pretty much the same thing, just in reverse (going upwards into the $scope).

It will traverse all the $scopes until the $rootScope.

Unlike the $broadcast event, this one can be cancelled by any of the listeners.

Do try to keep the $rootScope clean 🙂