Svelte is a new front-end framework written by the authors of Rollup. Its slogan, compilers are frameworks, and the idea is to do static analysis at compile time, generating the smallest set of features needed to reduce the volume of packaged code. Another feature of Svelte is that instead of using the virtual DOM architecture popular with frameworks today, it compiles the code that generates the minimal DOM manipulation, thus avoiding diff operations.

There are two key advantages to Svelte:

• Small size after packaging
• Theoretically the same performance as handwritten native JS

Performance aside, another selling point of Svelte is that it can be packaged in a smaller size than other frameworks to fulfill the same requirements. Let’s understand in principle why Svelte is smaller when packaged than other frameworks.

For this code

<script>
	let name = 'world';
</script>

<h1>Hello {name}!</h1>
Copy the code

Will be compiled into

function create_fragment(ctx) {
	let h1;

	return {
		c() {
			h1 = element("h1");
			h1.textContent = `Hello ${name}! `;
		},
		m(target, anchor) {
			insert(target, h1, anchor);
		},
		p: noop,
		i: noop,
		o: noop,
		d(detaching) {
			if(detaching) detach(h1); }}; }Copy the code

Hello {name}!

Hello {name}!

never changes, so Svelte doesn’t introduce responsive update-related code, doesn’t use lifecycle hooks, and naturally doesn’t have lifecycle related code, which is how much code this component compiles.

If you use the same code as React, even if you don’t use hooks or class-related functions, you still need to import the entire React package, and that’s where the volume gap opens.

Now that we know how Svelte works, we can do some theoretical analysis. In principle, it’s just an advanced introduction on demand. You don’t have to pay for code you don’t use, which sounds great, but in other words, if you do use all the features, you still have to pay.

The question is, when does this volume advantage disappear, and what is the critical point? The Svelte community was also concerned about this issue #2546, so someone did the experiment and put it in the Svelte-it-Will-Scale warehouse.

To find the critical point that affects the volume advantage, you first need to find the volume relationship between the Svelte source code and the packaged code. Testers took Svelte components of different sizes from some real-world Svelte projects and plotted the source volume and packaged size after removing style-related code.

X-axis is the source volume size, Y-axis is the volume size after packaging, different lines represent the results of different compression algorithms. From this diagram, we can get a formula:

Svelte component packed bytes = 0.493 * source size + 2811

Next, the experimenter used the same method to measure the React framework, and got the following diagram

The formula is:

React component packed bytes = 0.153 * source size + 43503

Now, with these two formulas, we can easily figure out where the critical points are with third-grade math, but just for intuition, let’s draw them, right

As you can see from the figure, the tipping point is at 120 KB, that is, if your component-related code for your application is around 120 KB, the volume advantage of Svelte compiling on demand is gone

In practice, it’s really hard to get 120 KB of code associated with normal application components, plus using techniques like code-spliting. And when the experimenters looked at real-world Svelte projects at the same time, they found that none of them were even close to the tipping point.

Therefore, using Svelte does give your project a volume advantage.