Ali Soueidan

Ali Soueidan Front-End Developer

👋 Hello, I am Ali, a Developer based in Hamburg/Germany, and this is my Blog.

Why I (as a freelancer) use Vue

People often ask me why I decided to work with Vue. As a freelancer, in addition to technical aspects and personal preferences, my strategic orientation also plays a role. In this article, I would like to take a closer look…

Why I focussed on Vue, instead of other JavaScript Frameworks

Basically, all three frameworks solve more or less similar problems – they provide better maintainability, more efficient development and allow to create web applications with a modern UX (reactivity, modularity, etc.). They differ mainly in how they achieve their respective goal. When I started my freelance career – I had to decide where to put my Focus at. The options to consider between where Angular, React or Vue.

Every journey begins with a choice!

During my time as an employee we were still working with vanilla JavaScript and/or JQuery, which at that time was more of a substitute than an alternative to the other mentioned solutions. Since I had just started my own business, there was not much time to dive deep into each framework – so this article will (at least as far as Angular and React are concerned) rather scratch the surface – it will be less about how far the frameworks are superior or inferior to each other, but rather I would like to talk about what I personally liked about Vue instead of the others, when I had to decide as a freelancer.

Why I decided against the other frameworks

Basically, I think that all of the popular JavaScript frameworks have their raison d’être. So I explicitly chose Vue not because I think the other solutions are fundamentally bad, but because my personal preferences were more compatible with Vue than with the other solutions.

Why not React

I just couldn’t really warm up to how React did certain things – even though it was the most widely used „framework“ (actually, a library) on the market at that time. For me it already started when I opened the documentation, one of the first code examples is the Hello World Code Snippet.

Hello world in React.js

The way React handles markup reminded me kind of of PHP, where markup and script are mixed together, which I did never really liked when using it. Also React offered the least possibilities out of the box, respectively one had to rely on solutions out of the community – basically that doesn’t have to be bad – but I like better with Vue e.g., that the core team itself provides important solutions, because there will be a corresponding interest that these solutions work well and will be developed further. Also (and even more than in Vue) in Angular one gets provided with many build in solutions, which are maintained and developed by the Angular Team itself.

Also the documentation of the React Library seemed to be the worst of them three (to me) – a good tidy documentation may not necessarily have anything to do with the quality of a technical solution (even if it kind of conveys to me a certain claim to quality), but it is and will always be the first place to go when there are new features coming up, in the beginning of the learning process or simply as a permanent reference book – one will simple depend on it and often use it, so it should be good!

React was already widely used, many freelancers (competitors) were already very experienced in using React, some of them had grown with the library and had already gained a lot of project experience. On the other hand, Vue on the other hand was new, so I saw a potential strategic advantage here to position myself accordingly on the market.


Google decided to throw Angular completely out the window and start over with Angular 2 – this didn’t inspire much confidence in me at the time. Google already relied on TypeScript with Angular, and all in all delivered the most complex solution of the three, which would have meant an additional learning effort, and since I wanted to get started as quickly as possible, this was a clear contra-argument at that time – even from today’s perspective, I have to say that a high learning effort for me rather speaks against specialization, not because I don’t want to make the effort (who doesn’t like to learn new stuff might be in the wrong job being a developer), but rather because a technology will be more difficult to establish and thus spread if learning it involves a higher effort, since the initial investment costs for companies are correspondingly higher. So in the case of Angular, it was primarily the skepticism about the wide adaptation of the framework in the private sector that made me decide against the framework.

Why Vue?

Some of the reasons why I, as a freelancer, decided to use Vue instead of the other two solutions are already clear from the previous text, but beyond that there were a few subtleties that still inspire me today and make me happy to work with the framework.

Single File Components

In the meantime, the point that initially caused me the greatest skepticism is almost the biggest argument for using Vue – Single File Components! A big plus of the common JavaScript frameworks is that you can work modularly – with Single File Components this concept is taken to the extreme, so the entire code of a component – from markup to style to script can be processed within a single file. Working as an employee it was strict forbidden to mix Markup, Style, and Script within a file, why at the beginning the concept of Single File Components seemed to be strange to me. Anyways – after a short familiarization with Vue, it absolutely felt natural to mix these areas together. It’s just great to have all the code of e.g. the button component simply contained in the corresponding file and not having to pay attention to several separated files next to each other, further more within the file the three parts are clearly separated – everything is just at its place! and the concept of Single-File-Components work beautifully with an Atomic Design architecture, which I love to work with – so all in all Single-File-Components are a big plus of Vue to me – btw. these are optional, so if you want to keep it classic just got for it.

Easy to learn

By using Vue, some things have changed – but some things have stayed the same and I think that’s a good thing! Each Single File Component basically consists of three parts: markup, style, and script. In Vue I can write the markup as usual and use normal HTML or a template engine of my choice with the same syntax I am used to, the same goes for stylesheet languages. So, in these areas you don’t have to get used to much (even if with the extended possibilities of course some new things are added) – besides everything remains well readable as it always was (markup in react as mentioned before didn’t appeal to me at all). Overall, getting started with Vue was pretty comfortable – familiar patterns can be maintained in some places and the documentation is very understandable and well structured, so the learning curve here is also relatively steep.

How it has evolved

When I joined, Vue 2 was the current version. In the meantime, we have arrived at Vue 3 and even though I have not yet been able to use Vue 3 within a project yet, I think it’s great how the framework is developing. With the Composition API comes a new syntax, which is especially good in larger projects, Vue 3 also offers a now better Typescript support (is written in Typescript), added multi root components (finally), higher render speed, tree shaking (thus less unnecessary ballast). Via the Vue blog you are also constantly kept up to date and informed about news from the ecosystem, which is just nice.

Nothing special but I like it

Many of the concepts in Vue also exist in the other frameworks – which doesn’t make them any less cool! Lifecycle hooks, templates (merging markup and script), scoped styling, reactivity, state management (Vuex), component-based development, and on and on.There are countless extensions to the framework, such as Nuxt, which simplifies the developing world in some places and enables server-side rendering.


At another point in time, I might have decided differently, maybe I would have tended towards React in 2015 and stayed with it until today or (depending on the case) would have switched to Vue anyway. Vue was strategically the best solution for me (from a freelance point of view), even if I was a bit speculative here, it paid off at the end – I still enjoy working with the framework, love the possibilities it offers and like how the framework has evolved.