This article has participated in the call for good writing activities, click to view: back end, big front end double track submission, 20,000 yuan prize pool waiting for you to challenge!

Uvu recently created a repository to evaluate Svelte and Vue3 components. This is actually very interesting to me because I recently used Svelte for development in a business project.

So what are the results? (Expectant eyes, thinking uVU is going to write Svelte code to evaluate.

Vue is familiar, if you don’t know what Svelte is? You can see the upstart front-end framework Svelte from the beginning to the principle.

As a general introduction, Svelte is a No Runtime — No Runtime code framework.

Here are Jacek Schae’s statistics on the volume of writing the same Realword application using the mainstream frameworks on the market:

Here is the detailed research procedure, if you are not interested in the research procedure, you can skip to the end and see the conclusion.

Steps of the study

In the interest of fairness, UVU chose TodomVC for the build comparison and then listed a series of steps.

  1. Both frameworks implement a simple, compliant todomVC component with the same functionality.

    • Vue: todomvc.vue(using the <script setup>Syntax)
    • Svelte: todomvc. Svelte (based on official implementation, the uUID method has been removed to be fair.

  2. Components are compiled separately using the respective framework’s online SFC compiler

    • Vue: sfc.vuejs.org @3.1.4 -> todomvc.vue.js

    • Svelte: svelte.dev/repl @3.38.3 -> todomvc.svelte.js

  3. Compile the file using Terser REPL compression, then delete ES imports and exports. This is because these imports/exports are not required or shared among multiple components within a bundle application. (This can be interpreted as similar to third-party code and does not affect the size of the component’s internal implementation)

    • Vue: todomvc.vue.min.js

    • Svelte: todomvc.svelte.min.js

  4. The files are then compressed using Gzip and Brotli (an open source data compression library similar to Gzip)

    • 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, under SSR, Svelte needs to compile its components in “Hydratable” mode, which introduces additional code generation. When compiling Svelte, use the option Hydratable: True to turn on SSR and repeat steps 2-4.

    The code generated by Vue in the SSR environment was exactly the same, but some additional chocolate specific runtime code (~0.89 KB min + Brotli) was introduced.

  6. For each framework, Vite is used by default to create and package builds (Svelte uses Hyderable: false). Each application simultaneously sets the SSR pattern to build again.

The default Vite package generates a Vendor Chunk (= framework runtime code) and an Index chunk (= component code).

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

W /o = w/o

Analysis of the

In client mode, analyze from the Vite Vendor Chunk (min+ Brotli) column. Svelte App imports 1.85KB min+ Brotli framework code and is 15.04KB lighter than Vue. This may seem very powerful, but it’s because of the framework runtime differences. (Svelte does not have a runtime, Vue has a runtime)

Looking at the component code, Svelte’s min + compressed output is 1.7 times larger than Vue’s. In this case, a single component would result in a size difference of 0.78 KB. In the case of SSR, this ratio further increased to 2.1 times, where a single component caused a difference in size of 1.23 KB.

Todomvc is very representative and represents the components that most users build for use in their application scenarios. It is reasonable to assume that a similar size difference would be found in a real-world scenario. That is, in theory, if an application contains more than 15.04/0.78 to = 19 Todomvc sized components, the Svelte application will end up larger than the Vue application.

In an SSR scenario, the threshold would be lower. In SSR mode, although the frame difference was 15.65KB, the Compnent Count threshold decreased to 15.65/1.23 ~ = 13!

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

conclusion

Judah gives two conclusions in the README of the repository, which I’ve moved to the end.

  • Svelte single component is about 70% larger than Vue3 single component in normal mode and 110% larger in SSR modetodomvcThe component size comparison does not mean that all Svelte components are 70% larger than VUE 3 components. In other words, if a VUE component is 100K in size, the Svelte component may only be 101K, not 170K!
  • For projects, Svelte’s advantage over Vue3 does not exist when writing components larger than 19 (13 in SSR mode).

On the whole

The purpose of this study was not to say which frame was better — it was to analyze the effect of different frame strategies on volume size.

As you can see from the data, the two frameworks have different advantages in terms of bundle size — depending on your usage. Svelte is still great for disposable components (wrapped as custom elements, for example), but it’s actually a disadvantage in terms of size in large-scale apps, especially SSR.

In a broader sense, this study aims to show how the framework strikes a balance between compile-time compilation and Runtime Spectrum runtime: Vue uses some compile-time optimization on the source code, but choosing a heavier compile-time returns smaller generated code. Svelte selects the smallest run-time, but has the cost of regenerated code. Can Svelte further improve its code generation to reduce code output? Can Vue further improve tree-shaking, making the baseline (runtime framework) smaller? Can another framework strike a better balance? The answer to all of these questions is probably yes — but for now we need to be clear that “frame size” is a much more nuanced topic than simply comparing the size of Hello World applications, and this study is designed to prove it.

Personal opinion

The following is the personal opinion of the author of the public account, not the opinion of the survey.

In general, uVU wants to highlight that the comparison of frameworks using Jacek Schae’s RealWord application is unfair and needs to be more detailed. React and Svelte have been widely discussed in Svelte Github for a long time.

Svelte does have a threshold that makes it less of a size advantage after a certain point, but in general, Svelte should be smaller than other frameworks, as long as it is not a particularly complex back-end management application.

Especially in some H5 games, if you want a React/Vue data-driven approach to writing applications, but you don’t want to introduce such a large runtime, this is a great solution. Recently, we are developing a mobile terminal webpage based on three.js. It is estimated that the volume is reduced by 30-50% compared with React. The specific data cannot be provided because the migration has not been completed. In addition, the non-runtime framework is also a great help for the first screen rendering. You can split the first screen components. The non-runtime first screen components are actually very small, which is very friendly for mobile terminals, because after all, there is a certain pressure on the server to use SSR.

The above is my personal opinion after reading the analysis and comparison of THE UNIVERSITY of Utah. Please point out the shortcomings.

The original research

Github.com/yyx990803/v…

Go back to my previous articles and you may get more!

  • Here we go again! Achieve 500+ likes in 10 minutes for wechat “Blow shit” campaign

  • 2021 Front End Learning Path Book List — The Path to Personal Growth: 570+ likes

  • Teach you to achieve micro channel 8.0 “fried crack” 🎉 facial effects: 400+ likes

  • From a design website on the front-end watermarking (detailed tutorial) : 790+ likes

  • Unlock the secrets of “file download” : 140+ likes

  • 10 cross-domain solutions (with the ultimate trick) : 940+ likes

conclusion

❤️ follow + like + favorites + comments + forward ❤️, original is not easy, encourage the author to create better articles

Follow public accountNotes on the autumn wind, a focus on front-end interview, engineering, open source front-end public number