Recently @Desert Autumn published a comparison between Angular and Vue. The comparison between frameworks is a cliche, but it’s also an ongoing topic, and Vue’s own documentation directly compares it to other frameworks. As an open source solution, there is nothing wrong with the comparison itself, but when writing the comparison between Vue and other frameworks, we tried to do two things:
1. Make sure your facts are accurate. Some have namely, did not have namely, uncertain do not say, got wrong certain change.
2. Keep your tone neutral. Point out other people’s faults but don’t mock them; acknowledge their strengths freely.
Earlier, @Wang Zhicheng proposed a comparison between Vue and Angular, and we revised it accordingly. Continued monitoring and feedback from the community is also welcome — the purpose of the comparison is not to distort perceptions, but to help people make their own judgments.
W3Cplus@w3cplus@w3Cplus@w3Cplus@w3Cplus@w3Cplus@w3Cplus@w3Cplus@w3Cplus@w3Cplus
Facts first.
CLI/tool chain
First, the positioning of CLI is inconsistent between the two frameworks. Vue-cli is not a packaging tool, it is just a scaffold, the initial tool. The real packaging is the WebPack configuration and NPM script within the project after initialization. Vue-cli was intended from the start that the real toolchain for the project was in the project template, not in the CLI.
By contrast, @angular/cli is a full-package command-line tool. Everything is executed through ‘ng’, but this does not mean that the command Vue of ‘ng’ does not have corresponding functions — for example, in vue-cli generated projects:
- NPM run dev corresponds to ng serve
- NPM run build corresponds to ng build
- NPM run lint corresponds to ng Lint
- NPM run Unit corresponds to ng test
- NPM run E2e corresponds to ng E2E
@angular/ CLI all vues except i18N. It is a factual error to say that many of the features required for daily development require developers to download and configure Node modules from third parties. Looks like Desert is rushing to write an article without even running through vue-CLI-generated projects.
Second, CLI command/parameter more = better? There’s no such thing as create-React-app crying in the bathroom. If we take a closer look at the screenshot, the ng Build parameters correspond to different underlying WebPack configurations. To be honest, I believe that not only I, but many other developers, would rather read the WebPack documentation directly to tweak the actual WebPack configuration (and commit it to the project) than learn an extra set of abstractions that Angular encapsulates because of the changing requirements in production. Configurations that are completely encapsulated by the CLI are not conducive to secondary development.
To be honest, @Angular/CLI does have some lessons to learn, such as ng Serve support for SSL. We’ll continue to incorporate improvements in vue-CLI as well, but the toy analogy doesn’t make sense when we don’t even know what vue-CLI can do.
Asynchronous loading module
I don’t know why Damo has taken an incomplete screenshot of an old Chinese document somewhere – the most recent documentation on asynchronous loading is the following link:
- The section of the documentation on asynchronous components
- The section of the routing documentation about lazy routing
Vue changes a component (and all its dependencies) to be loaded asynchronously. All it needs is to add:
import Foo from './Foo.vue'
Copy the code
to
const Foo = () => import('./Foo.vue')
Copy the code
It’s that simple. Three points to note here:
- When this is done, other components or modules that the component depends on will be automatically divided into the corresponding chunk. There is no such situation as “manually change 500 components” as suggested by The Desert. Besides, the function of code segmentation on both sides is provided by Webpack, I really don’t know whether Damo really does not understand or deliberately misleading.
- The so-called route level splitting is done by treating this component as a route component, and not even changing the route configuration table.
- What’s more, such asynchronous components don’t have to be used only at the routing level — wherever you use a component, they can be seamlessly replaced with asynchronous components, a flexibility that Angular loadChildren simply can’t match. For example, with a dynamic long form page, you can even dynamically grab the rest of the form based on the user’s current input (a use case that WepBack maintainer Sean Larkin discovered and used in production).
Unit testing and integration testing
Unit testing of Vue requires you to install and configure Karma + Jasmine yourself
— Factual error. Vue-cli’s Webpack template comes with built-in Karma + Jasmine configuration out of the box and comes with an initial test case, NPM Run Unit. This proves once again that Desert never ran through vue-CLI-generated items.
Vue single test not only supports Karam + Jasmine – in fact the community has a wide range of single test feedback for Jest, Ava, We are working on an official single test library called Vue-test-Utils (developed by the developers of avoriaz, the most popular single test library in the community) that will further simplify common component single test assertion requirements, and will also have guidance for integration with all major test runners.
In terms of integration testing, Vue gets a zero because it doesn’t do anything.
— Factually incorrect. The VUE – CLI WebPack template comes with an out-of-the-box Nightwatch + Selenium E2E test configuration built in, along with an initial test case, NPM Run E2E. This double 叒 proves once again that Desert has not run through vue-CLI generated items at all.
As you can see from the support for integration testing, Vue can be copied pretty well in places where the technical level is not high, but once the technical threshold is raised, Vue can’t be copied, or copied not as fast.
— Integration test this kind of thing, what is the technical threshold to speak of, also need to copy? By the way, the vue-CLI initialization project came with integration tests long before @angular/ CLI was officially released…
TypeScript
The article directly talks about how good TypeScript is, meaning that it’s something only Angular has. In fact:
- Vue Family buckets come with official TypeScript typing since release 2.0;
- Vue has an official TypeScript Component Class decorator;
- There are many users who use the Vue + TS combination in production environments;
- The VSCode + Vetur plugin provides perfect IDE type hints;
- The TS team is actively working with Vue to drive a better Vue + TS experience, and the next version of Vue will be able to achieve complete type derivation without even using a Class decorator.
I’m not denying that Angular is a TS-oriented framework, so the default Workflow is more tightly integrated with TS, but the experience of developing a TS configuration alone doesn’t make a significant difference.
AOT & Treeshaking
The bigger your project gets, the more you realize how important it is to have AOT, and Vue can’t do anything about it, the developers are on their own.
— Factually incorrect. Vue has had a template compilation strategy in mind since 2.0: the framework’s dist file itself is divided into compiler-inclusive and compiler-free versions, the former can be compiled directly in the browser, and the latter is dedicated to AOT compilation at build time, stripped of the size of the compiler. Vue-cli-initialized projects default to AOT status — note that this has been the case since Vue 2.0 was released almost a year ago, before @Angular/CLI supported AOT.
There are many other optimizations in Vue at build time, details of which can be found at the end of my JSConf presentation in July.
Now, Treeshaking. The principle of Treeshaking is also mentioned in slides above. Here are a few points:
- Until WebPack 3.3, Treeshaking relied on rollup. At the framework level, the Vue dist file is a rollup flat ES Module. (Note that this is a design that was introduced in Vue 2.0, and was later used in React.) Igor Minar mentioned that Angular wants to use the same release build), which minimizes the size of the framework itself.
- Treeshaking, @angular/cli is also rollup. And when finally webpack 3.3 support real treeshaking (in the document called the scope hoisting) – any use webpack project as long as enabled ModuleConcatenationPlugin can get similar Rollup Treeshaking effect. For vue-CLI templates, enabling it by default is a piece of work, but at this stage we just want to wait for it to be more stable.
team
As I’ve said long ago, it’s shortsighted to disparage a project as “one person.” Ruby started with Matz, Python started with Guido, and Linux started with Linus. Any project, especially an independent open source project, has a development process. What happens to Angular 1?
Vue’s Contributor Graph has some details that can be easily overlooked without an estimate. I was the only one writing the 2.0 code during the initial development phase, so most of the early commits were mine, and I kept all the fine-grained commits, such as indentation. After the late official release, commit begins to emphasize readability. A feature is generally rebase into several periodic commit, and most PR is squash into a single commit. So contributor will have fewer commits.
Again, let the numbers speak for themselves. Looking only at recent status, this site has an interesting metric: How many contributors did the last 100 commit come from?
Vue has 23, Angular 38. Angular has more, but it’s clear that Vue is not just me.
conclusion
Having said that, we can see that almost every technical comparison point in the article doesn’t stand up to scrutiny, and it’s clear that the author doesn’t know enough about the Vue ecosystem, that he’s trying to belittle it for the sake of belittling it, and that some of the technical details that were implemented earlier in Vue are copying Angular…
In one of my previous answers (Yu: What is your idea of a front end circle? I said I wanted the Chinese front end to be less grumpy, so I’ll try to stick to the technical facts here and:
Let’s hope Vue users and supporters don’t make irrational attacks on Desert or Angular.
Let’s hope Vue users and supporters don’t make irrational attacks on Desert or Angular.
Let’s hope Vue users and supporters don’t make irrational attacks on Desert or Angular.
Say three important things. This article is not meant to be a fight, just to clarify some technical facts. Students with higher requirements for themselves can not stand in line. Tying yourself to a frame is not a good thing. Your confidence should come from your ability to drive it, not be driven by it.
Why are there so many fake vue projects, while React and Angular are few? I also wrote this passage:
I once asked my boss and the leader of the Angular team this question: As the leader of Angular promotion in China, can I go up against those people who are very extreme and even vicious in the discussion about Angular on the Internet in China? Here’s what my boss told me: “Beating” the competition is not the Angular team’s goal. Our goal is to help developers and businesses build WEB applications for the future. It’s a very common sentence, but it left a deep impression on me, because I saw a brand new Angle, and they used to think like this. In contrast, many technology discussion boards in China can descend very quickly into personal attacks and waffle, giving the impression of a shrew. The front-end community, in particular, is becoming more showbiz. All the participants, including the questioner, please be quiet for a second and think, what do you want for yourself? Does beating your opponent in a war of words help you improve your coding skills or raise your awareness of the world?
At the end of that surly question, I admired the Desert. However… Now these two articles, really let me suspect that the desert is stolen number…
If you have no stolen number, touch your conscience and ask, you, face not blush?
—
Note: In order to avoid taking sides and quarreling, only those who follow me can comment, those who support Vue can just like it, thank you.