Svelte Notes (1) - No Silver Bullet
# FrontendIn the previous chapters, I mentioned that I can’t get enough of Svelte. The core concept of Svelte is “reducing what needs to be done at runtime through static analysis + compilation,” which minimizes the time spent doing diffs in the Virtual DOM and eliminates a hefty runtime.
However, the path Svelte takes inevitably encounters some issues, the main one being that Svelte can’t do too much for you at runtime.
- Take this issue (Render slot fallback content when there’s no content) for example; Svelte should render the
fallbackwhen slot content is empty. However, because of code like this:
<Box>
{#if foo}
something
{/if}
</Box>
During static analysis, it can only determine that there’s an if statement inside, concluding that there is content. In reality, the rendering will be blank instead of using the fallback.
- While it’s true that compilation happens, runtime still exists. There’s a tracking mechanism in the background to handle dependency updates. As long as the browser lacks built-in reactivity, the framework must address this issue. Moreover, even though the current compiler strives to minimize the size of the output bundle, as features accumulate, the bundle size may gradually catch up. In larger projects, this difference might not be as noticeable.
- Without a Virtual DOM, another challenge arises in testing. One of the advantages of a Virtual DOM is that it provides abstraction, making it easier to implement based on interfaces. Unlike React, which is relatively easy to test, this does involve considerations for developer experience and user experience.
Additionally, when writing code, I really dislike the mindset of “XXX framework is awesome! Everything else is garbage.” Such thinking not only stagnates personal growth and technical advancement but is also quite unacceptable.
Of course, this doesn’t mean we should aim for a utopia where everything is great—choosing a framework or language reflects your taste.
There’s a line from the anime “Ping Pong” that I really like:
卓球に人生をかけるなんて気味が悪い (Betting your life on table tennis is truly unsettling)
While saying “unsettling” might be a bit of an exaggeration, there really isn’t any framework that you must cling to for dear life. Your skills should be defined by your ability to master the framework, not by being dominated by it.
In summary, introducing this framework at a company may require some further observation. However, for quickly creating a small (or even medium-sized) project, I find it extremely user-friendly and easy to jump into development. All in all, it’s a framework that makes me feel ワクワク (excited), and I’m looking forward to its future developments.
Related Posts
- Make Your Hyperlink Underlines Look Better: text-underline-offsetBy default, underlines sit very close to the text, and some designers dislike this style. Personally, I don’t think it looks very good either.
- Why Web Design Shouldn’t Chase Pixel PerfectOnly pay attention to Pixel Perfect when it really matters; otherwise, it often leads to a lose-lose situation.
- Let’s Write Colors with CSS HSL! (And a Better Way)In web development, the traditional HEX and RGB color notations are widely used, but they are not very readable or intuitive, and their capabilities are limited in wider color spaces such as P3. HSL (Hue, Saturation, Lightness) provides a more intuitive way to define colors, making it easier for developers to understand and adjust them. By describing colors through the three dimensions of hue, saturation, and lightness, HSL makes color adjustment more human-friendly. In design systems in particular, HSL can better represent lightness variations in a color palette.
- The reasons to avoid setting line-height to 1 and using ellipsis whenever possibleThis article discusses why it's not advisable to set the line-height to 1 in web design, as well as the linguistic issues encountered when using ellipsis.