Cover image for Why VueJs is the next big thing - a personal perspective

Why VueJs is the next big thing - a personal perspective

georgedel profile image georgedel Updated on ・5 min read

Disclaimer: In this post I list those things that triggered my interest on VueJs and I do not expect everyone to agree with the statements below. This is not a competition for the best front-end framework/library. The following post is a result of my exposure working on Angular, VueJs and React as a professional. Feel free to place your own thoughts on the comments and possibly end up in a robust conclusion. Finally, when mentioning Angular, I am talking about Angular 2+ and not AngularJs.

It's a fact that the decision for which library to use depends on which of those tools could cover your needs each time. As a professional I worked on the most popular ones (Angular, React, VueJs), I found all of them equally great, but I dare to say that VueJs is my favorite one. Like it is mentioned in several posts, VueJs is a combination of React and Angular and I totally agree with that - VueJs actually embrace the greatest features of Angular and React.

Googling around, I found out that most of the blogs are talking about the popularity of the front-end frameworks and libraries considering graphs and job postings, numbers of downloads per library etc. I will try to make my approach more practical, naming those features that VueJs "borrowed" from Angular and React and I like the most. Long story short, here we go:

Two-way data binding

..or else "model binding". By saying two-way data binding in a general term means that any changes to the model object, will affect the UI and vice versa. I find this feature very handy in terms of code maintenance and possibly readability. Two-way data binding is used in VueJs and Angular but not in React. When working with React, you have to manually bind the updates by calling a function from the event handler - most of the times this is nothing more than a lambda function which updates the state by setting the current value - but still this is a concern which could be avoided by having the two way data binding feature.

Easier integration in an existing project

Although all the three of them can fully cover the needs of a Single Page Application solution, there are also those cases where you just need to write a piece of more elegant javascript without having to carry on the whole framework/library. A real case scenario I usually face is when I want to add some ajax calls in a legacy Multiple Page Application (written let's say in .NET MVC with Razor) and I want to avoid using the "obsolete" to me JQuery. I am not saying that JQuery is not doing the job, but even pure javascript can do the job either. So since we are moving forward, I guess that a more modern solution could be more effective. This is where VueJs and React are dominating - it is quite easy to include a bit of VueJs or React code in a "non VueJs" or "non React" application. Although Angular introduced the Angular Elements it is still not a straight forward way to apply them outside an Angular application. Basically this is because Angular was introduced as a framework, when React and VueJs as libraries, so this is a nice starting point for the next listed feature.

Grow as you go approach - initial package size

Like it was mentioned before, Angular comes as a full solution for Single Page Applications so the initial package of (approx) 500KB contains all the relevant tools like the Router, HttpClient, built-in form validation, built-in pipes etc. As such, whether you need them or not, Angular will install them by default. VueJs and React (80KB and 100KB each) offer some more flexibility/scalability though. The initial installation is in a more frugal format and any extra packages can be installed thereafter. So at first place you get only what you need and as long as your needs grow, you can extend the setup with more tools.

Functional and Class components

Red whine, white whine.... I presume that this decision is mostly depending on each developer's style or even on the team's agreed code guide but still. Having the option to choose between Functional and Class components is offered in VueJs and React but not in Angular. I am not saying it's good or bad using one way over the other, but still it is a level of freedom that Angular is not supporting anyway. With Angular the only option is the Class components.

Built-in API

Following the previous thought, this one is a matter of personal preference as well. Comparing React and Angular, I find that Angular offers a massive API and this can be either good or bad. The Angular API covers tons of use cases in a new syntax, when React API is simpler and relies in a lower level (pure javascript). Obviously this is something that affects the learning curve as well. Thankfully VueJs contains a simple enough (to adapt quick) API but not that extensive like Angular. A conditional iteration in a VueJs component's template for example can be achieved by v-for and v-if (*ngIf, *ngFor in Angular) etc when in React we have to play with more pure javascript commands like map, spread operator etc. But again, this is a matter of personal preference.

Separation of Concerns

Separation of concerns is one of the fundamental principles when talking about professional coding. Organizing the code in sections by having each section responsible for a specific operation prevents a lot of problems in terms of code maintenance and readability. In VueJs and Angular the components hold the html, javascript and css in separate code blocks and that increases the readability possibly but for sure, it serves the Separation of Concerns Principle. On the other hand, React introduces the JSX syntax which is a mixture of javascript and html because of the belief that those two are a bit of tied to each other.

To summarize, there is no good and bad library/framework. The first step in order to choose what suits our case, is to consider the needs of this case in depth. All the three mentioned tools (Angular, VueJs and React) were built by skillful developers and the aim was to be used efficiently by developers. As a personal preference though, VueJs is my favorite tool for the reasons mentioned above. Your opinions are also welcome

Posted on by:

georgedel profile



.NET | .NET Core | Angular(2+) | VueJs | React | Typescript | AWS | Azure | Docker


markdown guide

Wrong. Totally wrong, I disagree.

Just kidding. πŸ˜‚ I've never used Vue, but I've taken peeks at it and it seems pretty sweet. I will also mention Svelte. It seems like the "next big thing" as well, with the code being bundled on build time. Have you ever used it?


Thanks for your comment Jarod. I had a brief indeed and I am impressed by the fact that Svelte is so tiny. Although, I didn't have the chance to explore it's API so far. If you want to express your thoughts in detail about Svelte into an article, I would be more than happy to follow. Thanks again!


I'm not proficient enough in Svelte yet to do a post, but I do have a multi-part tutorial on Gatsby building a landing page in the works!


I also think Svelte may be the next big thing...


Possibly, I'm looking forward to see Svelte battle-tested like the above libraries. Let's hope it's gonna be another great tool to consider.

There's not all that much to battle test. Svelte is a compiler, once you build the bundle for deployment svelte is no longer involved at all.

Good point. Thanks for that


One other thing I don't see mentioned often is how easy it is for other developers to jump into Vue.

Its just (or can be just) JavaScript, HTML and CSS and the JS syntax/api isn't too crazy, so the mental overhead of hopping into Vue vs looking at React JSX or Angular's massive api, makes it easy for others to read and understand it.


Fully agree. I learned vue in 1 day. Never felt as proficient with angular or react (especially react) after considerably more time invested.

Started with angular 1.. angular 2 or whatever they're calling it these days was more frustrating than not. And react seems unnecessarily obtuse just to be unnecessarily obtuse. I've been doing this too long to care to spend time fighting the tools anymore. Vue makes sense, it's easy. There's no reason to add extra complexity... svelte likewise seems pretty easy, and that it generates small output without the need for a renderer in the deployment is also quite compelling.

Love me some vue but I think svelte is really "the next big thing" if I had to pick one.


This is true WakeskaterX. The learning curve for VueJs is pretty gentle. I found it easy to dive in VueJs. Thanks for your comment.


You resumed everything with one single sentence:
VueJS have the best of both worlds!

Thanks George, I share the same thoughts, Vue deserves more love ✌


Vue does deserve more love! Thanks for your comment Manuel.


Two-way data binding

You do know that react and flux exists because it's an untenable pattern for large apps? Literally that is the use case for flux πŸ˜€

From what i can conclude is that vue is excellent for small prototype-like apps and legacy apps that need to be modernized peacemeal.


Thank's for the comment echoes2099. I am aware of flux and redux and state management in general indeed.

VueJs can stand even for enterprise level applications as well. Thanks for your comment.


Can attest. Have a large, non trivial, application built with vue in production..

It used to be react.


whether you need them or not, Angular will install them by default

Not true. While it might add them to your package.json, they will get stripped down at build time, unless you actually use them. Angular Ivy hello world is as small as 3kb.


Thanks for your comment. Please see below the default package.json (after running ng new "project_name"). Not to mention, it will install typescript by default, jasmine, rxjs by default and a bunch other tools too - while in VueJs and React you have the ability to start with a frugal configuration and amend the packages as you go.

"name": "testapp",
"version": "0.0.0",
"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"test": "ng test",
"lint": "ng lint",
"e2e": "ng e2e"
"private": true,
"dependencies": {
"@angular/animations": "~8.2.0",
"@angular/common": "~8.2.0",
"@angular/compiler": "~8.2.0",
"@angular/core": "~8.2.0",
"@angular/forms": "~8.2.0",
"@angular/platform-browser": "~8.2.0",
"@angular/platform-browser-dynamic": "~8.2.0",
"@angular/router": "~8.2.0",
"rxjs": "~6.4.0",
"tslib": "^1.10.0",
"zone.js": "~0.9.1"
"devDependencies": {
"@angular-devkit/build-angular": "~0.802.1",
"@angular/cli": "~8.2.1",
"@angular/compiler-cli": "~8.2.0",
"@angular/language-service": "~8.2.0",
"@types/node": "~8.9.4",
"@types/jasmine": "~3.3.8",
"@types/jasminewd2": "~2.0.3",
"codelyzer": "^5.0.0",
"jasmine-core": "~3.4.0",
"jasmine-spec-reporter": "~4.2.1",
"karma": "~4.1.0",
"karma-chrome-launcher": "~2.2.0",
"karma-coverage-istanbul-reporter": "~2.0.1",
"karma-jasmine": "~2.0.1",
"karma-jasmine-html-reporter": "^1.4.0",
"protractor": "~5.4.0",
"ts-node": "~7.0.0",
"tslint": "~5.15.0",
"typescript": "~3.5.3"


That still doesn't change the fact that everything that is NOT used will be treeshaken away. That is right now, with Ivy will get even better, every part of angular core that is not used will be stripped away, see bundle size of this example ng-ivy-demo.firebaseapp.com/bundle.js

And that it install devDependencies? You can't possibly think that is a problem or a disadvantage.

I'm not shitting on neither vue or react, I think they are both great. But the code size argument against angular is simply uneducated.

The overall point of the section is that it is "hard" to escape from the frame that Angular generates by default when at the same point the other two libraries offer a more "tailor-made" approach. The library size is a parameter to support my statement.

I tried to make my post gentle, so please avoid the vocabulary you are using.


Another point here I haven't heard much about is build time. Angular builds take an insane amount of memory and are anything but fast. Every CI machine I've had to run angular builds or required extra memory. It will straight up max out 4gb of memory even for basic builds. My app right now, which is middle-sized takes 9 minutes to build in CI. That's insane! That's like compiling something from c. Another app of mine built in Vue of comparable size takes 2.5 mins.


Indeed, this happens usually when you build for production, you are right. Thanks for your comment.


Having been a long time AngularJs and Angular dev, I totally agree with your point that Vuejs is better for mixing in rich, client side development with server rendered HTML.

I've done it with every version of Angular, and it is a far better experience with Vuejs.


Thanks for your comment Sean.


I love Vue. As a concept, it friggin nails it. I love Typescript just as much for scale/stability, though. I'm DYING for cleaner Vue+TS workflow.

Honestly, I'm reticent to kick-off anything big until that happens. I'm kinda on hold, and that stinks. C'mon Vue 3!


Thanks for your comment Kevin. I admire your enthusiasm!


Your points to me seem more like personal preferences than actual unique selling points for Vue. You could replace Vue with a plethora of other options like Aurelia, Svelte and even something like Ember.

A framework in particular will always promote separation of concerns. Vue is also fast becoming React Lite in its approach and anti class stance. As far as I am aware, classes are out in Vue 3.

There is a reason Angular is popular in enterprise and government. You don't need to glue third party libraries together for basic functionality, it's well documented, easy to test and verbose. Angular require you to work in a standardised way, something libraries like Vue and React do not offer.

I hear more about Svelte these days than I do Vue. So, it'll be interesting if Vue can remain relevant and competitive in speed and bundle size.


Thanks for your comment Dwayne. I am not sure if you read the disclaimer or even how I end my post. Of course this is personal preference, that's what I state anyway. And of course Angular is popular because it is coming as a full solution. This is what I state as well. As about Svelte, do you have a popular website to mention? Vuejs is battle-tested (you can do the googling yourself). But again, did you read my post at all? Thanks for your comment.


totally agree except the next word :)


Good point! Thanks for he comment Ceyhun.