Why building an app with VueJS has become a better alternative to Angular

Why building an app with VueJS has become a better alternative to Angular

When building an app, there are several questions that come to your mind: * Which Javascript framework provides the best performance? * Which Javascript framework is most compatible? * Which framework is suitable for small size...

When building an app, there are several questions that come to your mind:

  • Which Javascript framework provides the best performance?
  • Which Javascript framework is most compatible?
  • Which framework is suitable for small size applications?

When you have so many options to choose from, you can get confused with which framework to choose to create your app?

Nowadays, as per stack overflow statistics, Javascript is a popular front end language in the market. And there are certain popular front end frameworks such as Angular, React and Vuejs. Among which React is most popular.

Here are the statistics from the stack overflow survey that shows the popularity of vuejs and angular js.

So, here you can clearly see that vuejs is more popular than Angularjs.

Angular js vs Vuejs

Let’s look at the differences between Angular and Vue more specifically.


Google released angular in 2010. It is a typescript based javascript front end web framework. It was released prior to Vuejs. Today it is known as Angular but before 2016, it was called AngularJS.

Suffix ‘JS’ was removed from the name after the release of Angular 2+. On 28 May 2019, the latest version of Angular, which Angular 8.0.0 was released. Some of the most popular companies using Angular are Google and Wix.

General pros of Angular

  • Two-way data binding: AngularJS has an amazing tendency to replicate the changes happening in the model to the views almost instantly.

  • Quite popular and well used: Angular has a big community of professionals supporting it.


General Cons of Angular

  • The learning curve is steep. Since it has several facets and features, this javascript framework which is definitely harder to learn than its counterparts such as react and vuejs.

  • Consistently updating: Significant changes are introduced frequently. Hence, it becomes difficult for developers to adapt to the changes at a similar pace.


Vuejs was released by an ex-engineer of Google, Evan You in 2014. It is gaining constant popularity. Its latest version, version 2.6.10, was released on 20 March 2019.

It is the youngest member of the family of Javascript frameworks. It has practically overcome the limitations of the other frameworks to provide ease of the next level to the app developers.

It’s one of the most starred JS frameworks on Github. Thanks to its features, relatively easy learning curve, and ability to create efficient, fast, and sophisticated single-page applications.

When it comes to performance, Vue is an amazingly fast tool. At an incredibly small 18KB after gzipping, this technology will probably have a long life ahead.

Websites using Vuejs are: GitLab and Alibaba

General pros

  • Overall performance: With its manageable size and the ability to incrementally adopt parts of its technology, the performance of Vue makes it a great tool.

Image Credit: Log rocket

  • Ease of use: As compared to other javascript frameworks like Angular, Vue is quite easy to learn, which makes it appealing for both beginners and longtime professionals.

  • Great documentation: The dedicated team behind Vuejs has put a lot of effort into the tool’s documentation which is incredibly helpful for users.

  • Easy project integration. This permits you to start using Vue instantly in your project.

**General Cons **

  • Smaller Job Market: As I have mentioned earlier in the blog, it is a relatively new framework, the wider market has yet to embrace Vue. Thus, it may take a little more time before we see a high demand for new, skilled Vuejs developers in the job market.

  • Small Community: Since it is a new framework, it does not have that large community as Angular has. But yes, it will take some time and it is true that its community will become big soon.

Since you have seen a fine comparison of Vuejs and Angularjs. Now you can easily decide with which technology should you go for. So, I have chosen the most popular technology vuejs which is a progressive and more compatible technology than others like Angular. Also,

  • Vuejs has the highest number of Github stars. It is around 153k.
  • Vuejs is a progressive framework that is mostly used for creating web apps. Progressive framework means that if you have a website made in Angular, you can easily add some pages to your website in vuejs or you can convert your complete angular website into the Vuejs web app.
  • Vuejs is the fastest front end framework in the present time. It is 4 times faster than React.
  • Unlike Angular which is managed by Google, Vuejs is managed by the community.
  • Vuejs is a lightweight framework.

Now, Let’s code a simple app for listing the tasks to do. Let’s name it a Taskdo app.

1.** Install vuejs via command-line Interface.** Just type a command in Terminal and install the app code to create a full-fledged app.

2.** After that put the necessary code in it.**

Here are the code snippets of the TaskDo app that I created. It can enlist all the tasks that you want to do at the scheduled time.



		<section class="hero is-fullheight has-background-grey-lighter">

			<div class="hero-body">

				<div class="container">

					<div class="field">

						<div :class="[ { 'is-loading': isSaving }, 'control is-medium']">




								class="input is-medium"

								placeholder="Enter a new task..."





					<div class="has-margin-top-10">

						<task :tasks="tasks"></task>







This is the HTML part. Another part written in JS is mentioned in the separate code snippet shown below. Js starts with

Angular 9 Tutorial: Learn to Build a CRUD Angular App Quickly

What's new in Bootstrap 5 and when Bootstrap 5 release date?

What’s new in HTML6

How to Build Progressive Web Apps (PWA) using Angular 9

What is new features in Javascript ES2020 ECMAScript 2020

Angular – introducing semantic versioning

Angular – introducing semantic versioning

Using semantic versioning is about managing expectations. It's about managing how the user of your application, or library, will react when a change happens to it. Changes will happen for various reasons, either to fix something broken in the code...

Using semantic versioning is about managing expectations. It's about managing how the user of your application, or library, will react when a change happens to it. Changes will happen for various reasons, either to fix something broken in the code or add/alter/remove a feature. The way authors of frameworks or libraries use to convey what impact a certain change has is by incrementing the version number of the software.
A production-ready software usually has version 1.0 or 1.0.0 if you want to be more specific.

There are three different levels of change that can happen when updating your software. Either you patch it and effectively correct something. Or you make a minor change, which essentially means you add functionality. Or lastly, you make a major change, which might completely change how your software works. Let's describe these changes in more detail in the following sections. Angularjs Online Training Hyderabad

Patch change
A patch change means we increment the rightmost digit by one. Changing the said software from 1.0.0 to 1.0.1 is a small change, usually a bug fix. As a user of that software, you don't have to worry; if anything, you should be happy that something is suddenly working better. The point is, you can safely start using 1.0.1. Angular Training

Minor change
This means the software is increased from 1.0.0 to 1.1.0. We are dealing with a more severe change as we increase the middle digit by one. This number should be increased when functionality is added to the software and it should still be backward compatible. Also, in this case, it should be safe adapting the 1.1.0 version of the software.

Major change
At this stage, the version number increases from 1.0.0 to 2.0.0. Now, this is where you need to the lookout. At this stage, things might have changed so much that constructs have been renamed or removed. It might not be compatible with earlier versions. I'm saying it might because a lot of software authors still ensure that there is decent backward compatibility, but the main point here is that there is no warranty, no contract,
guaranteeing that it will still work.

What about Angular?
The first version of Angular was known by most people as Angular 1; it later became known as AngularJS. It did not use semantic versioning. Most people still refer to it as Angular 1.
Then Angular came along and in 2016 it reached production readiness.

Angular decided to adopt semantic versioning and this caused a bit of confusion in the developer community, especially when it was announced that there would be an Angular 4 and 5, and so on. Google, as well as the Google Developer Experts, started to explain to people that it wanted people to call the latest version of the framework Angular - just Angular. Learn more Angularjs Online Training

You can always argue on the wisdom of that decision, but the fact remains, the new Angular is using semantic versioning. This means Angular is the same platform as Angular 4, as well as Angular 11, and so on, if that ever comes out. Adopting semantic versioning means that you as a user of Angular can rely on things working the same way until Google decides to increase the major version. Even then it's up to you if you want to remain on the latest major version or want to upgrade your existing apps.

Migrating from AngularJS to Angular

Migrating from AngularJS to Angular

Migrating from AngularJS to Angular a hybrid system architecture running both AngularJS and Angular


Dealing with legacy code/technologies is never fun and the path to migration isn’t always as straight forward as you want. If you are a small startup, trying to balance business requirements, scarce resources and aggressive deadlines, it becomes even more complicated.

This is the situation one of the startups I was advising was facing.

A bit of background

The startup was developing a SaaS for the last 2 years and (at the time) had around 15 clients worldwide. In these 2 years their code base grew pretty fast and lead to quite a lot of fast/reckless written code. There was nobody to be blame, this is pretty common in the startup world when business needs move way faster than you expect and you start sacrificing code qualify for quantity.

The system architecture was pretty simple. 
• a frontend application written in AngularJS (split into multiple modules that were selected at build time depending on the clients’ configuration)
• a backend application written in Python 2.7 and Django 1.9 using a Mysql database
• Celery for running async tasks

Each client would get their own isolated environment deployed on AWS:
• Apache in front of the Django application (deployed on multiple EC2 instances behind an ELB)
• AngularJS build deployed on individual S3 buckets with CloudFront in front of them

Path to migration

A few months before starting the migration, development was getting very slow, features were not coming out as fast, deadlines were missed and clients were reporting more issues with every update that we were rolling out. It was at this time that we started thinking more seriously about some kind of refactoring or major improvement.

We didn’t know exactly what we were going to “refactor/improve” so we started off by answering three questions (I recommend that anyone who is thinking about a migration/refactoring think really hard about the how to answer them):

1st question: Why is refactoring necessary now ?

This is a very important questions to answer because it helps you understand the value of the migration and also it helps to keep the team focused on the desired outcome. For example because i don’t like the way the code is written isn’t good enough reason. The reason has to have a clear value proposition that somehow directly or indirectly benefits the customers.

For us it was mainly three things:
 1. feature development was becoming painfully slow;
 2. code was unpredictable. we would work in one part of the application and break 3 other parts without realizing;
 3. single point of failure: only 1 engineer knew the FE code base completely and only he could develop new features on the codebase (this is out of a team of only 5 engineers)

So our goal was simple:

improve FE development velocity and remove the simple point of failure by empowering other engineers to develop FE features

2nd question: Who is going to do the migration ?

You can answer this question either now or after the 3rd question. Depending on the size of the company and on the available resources it can be one person, several people, an entire team, etc…

We were in a difficult situation. The only developer who could work on this couldn’t because he was busy building critical features for our customers. Luckily we had one senior backend engineer who wanted to get some FE exposure so he volunteered to take on the task. We also decided to time-box a proof of concept at 2 weeks. We did this because we didn’t know how long it would take to figure out a solution or whether the engineer could actually do this task since he hadn’t worked on FE before.

3rd question: What are we actually going to do ? The answer here usually involves some discovery time, a few tech proposals and a general overview of the options with the entire team while weighing the pros and cons of each.

For us one thing was clear from the start: we didn’t want to invest any resources into learning/on-boarding engineers on AngularJS. AngularJS had already entered Long Term Support and we didn’t want to have our engineers invest time in something that might not benefit them long term. This meant that refactoring the existing AngularJS code was not an option. So we started looking at Angular6 …

The migration

There a multiple approaches on how to have a hybrid app running different frameworks. After reviewing some options we decided that — for us — the best way to move forward was to simply have 2 separate FE applications deployed: the legacy AngularJS one and the new Angular one. This meant that any state on one app could not be transferred to the other application, which wasn’t such a big deal for us since only new modules were going to be developed using Angular and our modules didn’t share state with each other.

From the client’s perspective everything would look like one application, except for a page reload when they would move between the applications.

Pros to this approach

  • speed: get something up and running without untangling legacy code
  • safety: no risk of breaking the current live app since it would be a new code based deployed next to the old one (especially since a developer with no previous exposure to the project was working on it)
  • stop legacy development: we stop adding more code the an already unmanageable codebase

Cons to this approach:

  • maintaining legacy code: it didn’t address feature improvements on existing modules; old modules would still be in AngularJS for an undefined period of time
  • duplicating parts of the code: since the new app had to look and feel like the old one any themes, custom components would have to be written in both places. Also some parts of the layout would have to be duplicated in new app (like header, menu, etc.. ) and any changes to those components would have to be done in both apps

We already knew of a new module that we wanted to build so we started form scratch with a new Angular 6 project and we used this new module for our 2 weeks proof of concept.

Step 1— same domain

Have both apps running on the same domain so that they have access to the same cookies and local data. This was extremely important since only the AngularJS app would continue handing authentication & authorization.

Step 2— look and feel

Both apps The goal was to make the new app look the same as the original application. So we: 
 • copied over all the stylesheets
 • implemented the base layout of the application (header & menu drawer)

Step 3 — authentication & authorization

We had to duplicate the authorization logic in the Angular6 app and make sure the correct session tokens were available to allow access to the module

Step 4— routing between apps

Since our main navigation links would take you to either app, we decided do move all that logic to a backend service called menu-service. This would eliminate the need to write any navigation changes in both apps and also would allow for greater runtime control over what navigation buttons we show.


HEADER: Authorization: Bearer xxxxx
GET menu-service/v1/menu/?type=0|1 (0: legacy, 1: new)
  "slug": "refresh",
  "name" : "Refresh",
  "icon" : "fa-refresh",
  "type" : 1  
 }, {
  "slug": "module1",
  "name" : "Module1",
  "icon" : "fa-module1",
  "type" : 1
}, {
  "slug": "module2",
  "name" : "Module2",
  "icon" : "fa-module2",
  "type" : 0
}, {
  "slug": "logout",
  "name" : "Logout",
  "icon" : "fa-logout",
  "type" : 0

In the above example based on the type value we identify that the module1 and refresh are links towards the new application while module2 and logout are links in the old application.
This information allows each application to decide whether to use the internal routing mechanism or do a window.location redirect

Example of routing in the Angular app (AngularJS does something similar):

export class MenuService {
  constructor(private router: Router) {  }
  onMenuItemClicked(menuItem): void {
    if (menuItem.type === 1) {
    } else {   
      const url = `${legacy_endpoint}/${menuItem.slug}`;
      window.location.href = url      

Step 5— building/deployment on a real environment

Like i mentioned in the beginning the AngularJS application was deployed to an AWS S3 bucket and exposed through Cloudfront to take advantage of the massively scaled and globally distributed infrastructure offered by AWS.

The result we wanted was the following: anything that has the url [https://hostname/v2](https://hostname/v2)/ is routed to the Angular application and everything else is routed to the legacy AngularJS app.

We used base-href and to make sure our Angular6 application builds accordingly

ng build --base-href /v2/ --deploy-url /v2/

Unfortunately we didn’t manage to achieve the desired routing behavior with AWS Cloudfront. This was a big disappointment since we had to pivot to a less optimal solution. (if anyone has any suggestion on how to do this in Cloudfront i’d love to hear it)

We ended up with the following structure:
• each app deployed in a NGINX Docker container

# AngularJS — Dockerfile:
FROM nginx:alpine
COPY dist /usr/share/nginx/html
# Angular6 — Dockerfile:
FROM nginx:alpine
COPY dist /usr/share/nginx/html/v2

• AWS ALB with path routing

Step 6: Local development

Local development for the AngularJS application didn’t have to change. However in order to develop on the Angular6 app you had to also run the AngularJS application to be able to authenticate and get the appropriate session tokens.

We were already using Docker for deploying our application as containers. So we added a Makefile target to run the latest from our Docker repository

# Angular6 — Makefile:
AWS_REPOSITORY = xxx.dkr.ecr.eu-central-1.amazonaws.com
JS_APP_NAME = angular-js
  docker run -p 8080:80 $(AWS_REPOSITORY)/$(JS_APP_NAME):latest


This might not be the cleanest or optimal solution, however it was the fastest way towards our goals. And this was the most important thing to us.

The goal of this post isn’t to teach you how to do a AngularJS to Angular6 migration but instead is to showcase our path when dealing with such a task.

Further reading:

An in-depth look at Angular’s ng template

Angular 8 Data (Event & Property) Binding Tutorial: Build your First Angular App

Angular 8 Forms Tutorial - Reactive Forms Validation Example

What is the difference between Angular and AngularJS?

<img src="https://moriohcdn.b-cdn.net/3e48d87dd5.png">AngularJS and Angular have been on trend as soon as the announcement of Angular 2 was done. There were a lot of differences between both of them. AngularJS was written in JavaScript whereas Angular in TypeScript.

AngularJS and Angular have been on trend as soon as the announcement of Angular 2 was done. There were a lot of differences between both of them. AngularJS was written in JavaScript whereas Angular in TypeScript.