· 3 min read

Svelte Notes (1) - No Silver Bullet

This article was auto-translated from Chinese. Some nuances may be lost in translation.

As mentioned in the previous chapter, I’ve fallen in love with Svelte. Svelte’s core concept lies in “reducing what the runtime does through static analysis + compilation,” thereby cutting down on Virtual DOM diffing time and eliminating a bulky runtime bundle.

However, the path Svelte has chosen is bound to run into certain issues—the most prominent being that Svelte can’t do much for you at runtime.

  • Take this issue (Render slot fallback content when there’s no content), for example. Svelte is supposed to render the fallback when slot content is empty. However, when there is code like this:
<Box>
	{#if foo}
		something
	{/if}
</Box>

Static analysis only knows there is an if statement inside, so it determines that content exists. In reality, it renders blank space rather than falling back.

  • While compilation is its hallmark, it doesn’t mean there is no runtime at all. Under the hood, there is still an update mechanism tracking dependencies and applying updates. As long as browsers don’t natively implement reactivity, frameworks will inevitably have to handle this. Furthermore, while today’s compiler does its best to minimize bundle output, as more features are used, the bundle size can gradually catch up. In larger projects, the difference might not be as noticeable.
  • Without a Virtual DOM, another pain point is testing. Another benefit of the Virtual DOM is providing an abstraction, making it easy to test against interfaces. It is not as effortlessly testable as React—though this naturally ties back to developer experience (DX) versus user experience (UX).

Also, when programming, I really dislike seeing the attitude of “Framework XXX is the greatest! Everything else is trash.” This kind of mindset keeps you stuck in place, both in your career and in your technical growth, and it’s quite undesirable.

Of course, that doesn’t mean pretending everything is sunshine and rainbows and every tool is equally great. Choosing a framework or language also reflects your taste.

There’s a line from “Ping Pong” that I really like:

卓球に人生をかけるなんて気味が悪い (Risking your life on ping pong is disgusting)

While “disgusting” might be an exaggeration, the truth is no single framework is worth clinging to stubbornly. Your strength should be defined by your ability to master frameworks, not by letting frameworks master you.

In conclusion, it might be best to observe a bit longer before adopting this framework at work. But for quickly spinning up a small (or even medium-sized) project, I find it exceptionally handy—you can dive straight into development. All in all, it’s a framework that gets me excited (ワクワク), and I look forward to seeing how it evolves.

Related Posts

Explore Other Topics