Youda personally evaluated Vue3 and Svelte (Vue is better after 19 components!)

Recently, Youda personally created a warehouse to evaluate Svelte and Vue3 components. This is actually very interesting to me, because I recently adopted Svelte for development in business projects.

So what is the result? (The look of anticipation, I thought you would write Svelte code for evaluation.

Everyone is familiar with Vue, if you don’t know what Svelte is? You can see rising star front-end framework Svelte from entry to principle .

In general, Svelte is a No Runtime-a framework with no runtime code.

The following is Jacek Schae , using mainstream frameworks on the market to write the same Realword application volume:

<img src="https://s3.qiufengh.com/blog/image-20210711222239287.png" style="width: 500px">

Please see the detailed research steps below. If you are not interested in the research steps, you can skip to the end to see the conclusion.

Research steps

For fairness, todomvc chose 060efb2d24f89e for construction and comparison, and then listed a series of steps.

1. todomvc component that conforms to the specification and has the same functions.

   • Vue: todomvc.vue (using <script setup> syntax)
   • Svelte: todomvc.svelte (based on official implementation , in order to fairly remove the uuid method, hurt, disappointed, it turns out that you have to write the components yourself)

2. Components are individually compiled using the online SFC compiler of their respective frameworks

   • Vue: sfc.vuejs.org @3.1.4 -> todomvc.vue.js
   • Svelte: svelte.dev/repl @3.38.3 -> todomvc.svelte.js

3. The compiled file is Terser REPL , and then ES imports and exports are deleted. This is because in a bundle application, these imports/exports not required or shared among multiple components. (It can be understood as similar to third-party code and will not affect the size of the internal implementation of the component)

   • Vue: todomvc.vue.min.js
   • Svelte: todomvc.svelte.min.js

4. Then the file using gzip and brotli ( Brotli is a open source data compression library , similar to gzip ) compression

   • Vue: todomvc.vue.min.js.gz / todomvc.vue.min.js.brotli
   • Svelte: todomvc.svelte.min.js.gz / todomvc.svelte.min.js.brotli

5. In addition, in the SSR environment, Svelte needs to compile its components in "hydratable" mode, which will introduce additional code generation. When compiling Svelte, use option hydratable: true to enable SSR and repeat steps 2-4.

   The code generated by Vue in the SSR environment is exactly the same, but some additional hydration-specific runtime code (~0.89kb min + brotli) is introduced.

6. For each framework, Vite used by default to create and package the build (Svelte uses hyderable: false ). Each application sets the SSR mode at the same time and builds it again.

By default, Vite packaged to generate a vendor chunk (= framework runtime code) and an index chunk (= component code).

	Vue	Vue (SSR)	Svelte	Svelte (SSR)
Source	3.93kb	-	3.31kb	-
Compiled w/o imports (min)	2.73kb	-	5.01kb (183.52%)	6.59kb (241.39%)
Compiled w/o imports (min+gz)	1.25kb	-	2.13kb (170.40%)	2.68kb (214.40%)
Compiled w/o imports (min+brotli)	1.10kb	-	1.88kb (170.91%)	2.33kb (211.82%)
Vite component chunk (min+brotli)	1.13kb	-	1.95kb (172.26%)	2.41kb (213.27%)
Vite vendor chunk (min+brotli)	16.89kb	17.78kb	1.85kb	2.13kb

Note: w/o means without and "removal" means

<img src="https://github.com/yyx990803/vue-svelte-size-analysis/raw/master/chart.png" width="600px">

analysis

In the client mode, analyze from the column of Vite vendor chunk (min+brotli). Svelte App imports 1.85kb min+brotli framework code, which is 15.04kb lighter than Vue. This seems very powerful, but this is because of the difference in the runtime of the framework. (Svelte has no runtime, Vue has runtime)

Let's take a look at the component code again, Svelte's min + compressed output size is ~1.7 times that of Vue. In this case, a single component will cause a size difference of 0.78kb. In the case of SSR, this ratio rises further to ~2.1 times, where a single component causes a difference in size of 1.23kb.

Todomvc is very representative and represents the components that most users build and use in application scenarios. We can reasonably assume that similar size differences will be found in real scenes. That is to say, in theory, if an application contains more than 15.04 / 0.78 ~= 19 Todomvc size components, the Svelte application will eventually be larger than the Vue application.

In SSR scenarios, this threshold will be lower. In SSR mode, although the frame difference is 15.65KB, the Compnent Count threshold drops to 15.65 / 1.23~= 13!

Obviously in real-world applications, there are many other factors: more functions will be imported from the framework, and third-party libraries will be used. The size curve will be affected by the percentage of pure component code in the project. However, it is conservatively estimated that application APP is larger than the threshold of 19 components (or 13 in SSR mode), the volume advantage of Svelte will be less.

in conclusion

Two conclusions were made especially in the warehouse README , and I moved it to the end.

• The Svelte single component is about 70% larger than the Vue3 single component in normal mode and 110% larger in SSR mode. (Official account author Qiufeng's note: In fact, there is a problem here. This 70% refers to the current todomvc component size By comparison, it does not mean that all Svelte components are 70% larger than vue 3 components. In other words, if a 100k size Vue component, Svelte components may only have 101k instead of 170k!)
• For the project, when the written components are larger than 19 components (13 components in SSR mode), the advantage of Svelte compared with Vue3 does not exist.

In general

The purpose of this research is not to say which framework is better-it is concerned with analyzing the impact of different framework strategies on the size of the volume.

As can be seen from the data, the two frameworks have different advantages in terms of bundle size-depending on your use case. Svelte is still great and suitable for disposable components (for example, as a custom element packaging), but it is actually its disadvantage in terms of size in large-scale apps, especially SSR.

In a broader sense, this research aims to show how the framework compile-time compile-time and runtime spectrum runtime: Vue uses a certain compile-time compile-time optimization on the source code, but choose The heavier compile-time returns a smaller generated code. Svelte chooses the smallest runtime, but at the cost of heavier generated code. Can Svelte further improve its code generation to reduce code output? Can Vue further improve tree-shaking and make the baseline (runtime framework) smaller? Can another point of framework find a better balance? The answer to all the above questions may be yes-but now we need to be clear that "frame size" is a more detailed topic than just comparing the size of the Hello World application. This study is to prove this.

personal opinion

The following is the personal opinion of the author of the official account, not the opinion in the survey by Youda.

Jacek Schae generally wants to highlight that in the comparison of the framework, the RealWord application that uses 060efb2d2502f5 statistics is a bit unfair, and more detailed comparison should be required. In fact, for the issue of the package size of Svelte, React and Svelte have been extensively discussed in the Svelte Github a long time ago.

Svelte does have a threshold that will make it no advantage in size after a certain degree, but in general, as long as it is not particularly complex in the middle and backstage management applications, Svelte should be smaller than other frameworks.

Especially in some H5 games, if you want to write applications in a React/Vue data-driven way, but you don't want to introduce such a large runtime, it is indeed a very good solution. Recently, I am developing a mobile web page based on Three.js. A preliminary estimate is about 30-50% less volume than using React. The specific value cannot be given complete data because it has not yet been migrated. Another point is that the non-runtime framework is also a great help for the rendering of the first screen. You can split the first screen components. The non-runtime first screen components are actually very small, which is very useful for mobile terminals. It is very friendly, because after all, there is still a certain pressure requirement to use SSR to correspond to the server.

The above is a little humble opinion after reading the analysis and comparison of especially big ones~ If you are short of deficiencies, please point out more.

Original research

https://github.com/yyx990803/vue-svelte-size-analysis

back at the author’s previous highly praised articles, maybe you can get more!

• 2021 front-end learning path book list-the road to self-growth : 570+ likes
• Talk about the front-end watermark from cracking a design website (detailed tutorial) : 790+ likes
• article takes you to unlock the mystery of "file download" : 140+ likes
• 10 kinds of cross-domain solutions (with ultimate big move) : 940+ likes

Concluding remarks

+ like + favorite + comment + forward , original is not easy, I encourage the author to create better articles

Pay attention to the notes of the Qiufeng, a front-end public account that focuses on front-end interviews, engineering, and open source