Get your keyboard out of your way with Svelte
- EmNudge Front-End Developer and Pedagogy Proponent
Why prototyping with Svelte is faster. Why Svelte's approach to abstractions and removing boilerplate is a categorically better model for faster iteration and stronger applications.
Hey there, I really like using Svelte.
I could tell you about its compilation or reactivity model,
but I think my favorite features are probably better shown directly.
I'll often use Svelte to quickly prototype an idea.
What if we have a bunch of sliders that loop around as they increase,
all offset by a little bit?
What if we have a bunch of boxes rotating inside each other,
with each box also adding rotation velocity to the boxes it holds?
When we work on web applications, we very often deal with user activity.
We're not just showing content, we're creating an interactive experience.
Svelte does a remarkable job of getting out of the way
and allowing us to simply focus on features, not lower-level implementation.
Let's say we want to find out which font looks best next to Verdana.
We could check them out one by one, but without putting them side by side, it can be hard to tell.
What if we used Svelte to make a web app for that?
In only 23 lines of unminified code, we made a fully functional web experience.
The equivalent vanilla version stretches at a minimum 61 lines of code across two files,
and that's not even accounting for the mental overhead of maintaining your own reactivity
system and the fragility of our code base.
It's not just that we're typing less code, but that the code we are typing is more accurate
to what we're trying to build.
the library is taking care of everything else for us.
When assessing the usefulness of a new framework, there are a couple of important details.
Does the framework produce lean builds?
Does it produce performant code, adhere to locality of behavior, encourage well-formed
code, help with refactors and feature iteration?
But the most important one, in my opinion, is does it tighten your focus on unique, application-specific
In other words, does the framework allow you to focus on the application?
Does it remove the common obstacles to iterate quickly?
Does it bundle related behavior in our files?
Are we punished for making ergonomic choices with larger or less performant builds?
Svelte does an incredible job at allowing us to concentrate on what matters.
Acting as a UI reactivity language that sits atop the well-known CSS/HTML/JS boundary,
our code only changes minimally and obviously.
code that we write is aimed at adding and manipulating features to our application,
not at shaping the surrounding glue code that permeates our code base. It does this with
reactive expressions, stores that auto-unsubscribe on unmount, transitions, animations, actions,
its preference for native HTML/CSS/JS where possible. There is strikingly little glue
code when adding in a third-party library.
The ability to connect data and inputs together so elegantly, it's felt, is one of its strongest
selling points. It's not just that it's less to type, but that it's easier to reason about.
As our systems grow in complexity, these reactive updates do as well. Handling this on our own
would often require a whole lot of event listeners and mutations, shrinking our actual application
in favor of all these state hookups.
Adding a new control requires very little additional Svelte code. This is because it
is acting like an incredibly well-made DSL.
The reactivity is implicit and obvious.
We can understand what the generated code will look like
without needing to bother with any of it.
The performance of Svelte applications
and the small bundle size gets brought up a lot,
but that's not really why I enjoy using Svelte.
I enjoy it because of the massive improvements
to the developer experience and velocity.
Svelte being fast and lean is just icing on the cake.
It means that I can enjoy the development experience without worrying about how my farmwork
itself is negatively impacting these areas.