Svelte impressions

Here’s a short (30-minute) talk I gave about SvetleJS.

Where I’m coming from

(Or, if you don’t want me to end with a preposition: From whence I come)

Generally, I eschew JavaScript frameworks. I have had jobs that centered around Backbone and Angular and spent a couple quarters working on an app written in React.

I’ve come to prefer the use of specific libraries that solve specific problems, like d3-shape and the like, rather than frameworks that define the structure of the application. I think that — unless it is an extremely trivial app — the developer should think through the structure themselves and the app will benefit.

I first tried Svelte a couple of years ago, when I worked on a project that my colleague Aliza had started in Svelte. I was struck by how little I had to know about it to be productive. After the project ended, though, I didn’t really think that much more about it.

A few months ago, I started trying Svelte. Today, I gave a talk to some colleagues about it. Here’s the notes. (They’re terse in order to encourage me to actually talk, so if you need any clarifications, email me! jimkang@fastmail.com)

The talk

How Svelte started

About four years ago, Rich Harris at the NYT built the Svelte framework for the NYT audience. Interactivity was necessary for a lot of their features, but any code on their web pages had to be small. It had to work with a vast general audience’s browsers and network connections.

Philosophy

  • Compiler does the work, not the user’s computer
    • No runtime, just generated code
    • Usually very small
      • React’s runtime is about 140K alone
      • Svelte apps I’ve built are consistently around 60K
  • Code mostly looks like normal HTML, CSS, and JavaScript
  • Doesn’t try to stop the developer from doing things, for the most part
    • Feels like it respects developers

How to use Svelte

Svelte has components.

  • They feel more like mini-web-pages than like components in React or directives in Angular. They’re not unlike Rails partials.
  • A component can have JS, CSS, and HTML.
    • But they don’t have to have all of those things. You can have a component with just HTML.
    • People who are comfortable with HTML and CSS but not with JS can help work on your app.
  • If you want just JS, you can just write a standard ES6 module and import it into the component you want to use it in.
  • You can have just one component if you don’t like components.
    • You can have that one component import modules that render a bunch of DOM elements.
    • Touching the DOM from JS is not forbidden. It’s fine.
  • Compiling components yields:
    • JS functions that insert and remove your HTML, as appropriate.
    • Scoped CSS. That is, CSS selectors that go under a randomly named class that’s applied to the component’s DOM element.
      • That way, the CSS from this component does not affect sibling or parent DOM elements.
      • It does not write everything into a style attribute. So, your CSS is still respected. You can still have global CSS if it makes sense to organize things that way.
  • The components are DOM-oriented. If you have an app that is mostly non-visual code, the components don’t help you that much.

Reactivity

  • No virtual DOM diffs. Direct updates of specific stuff that needs to be updated.
    • The stuff that needs to be updated is determined at compile time, not when a user clicks on something.
    • Popular reason for this is performance.
      • This isn’t important to me, personally.
        • I don’t care about performance until there is a noticeable problem.
      • However, I do care about programs doing too much stuff.
        • The more stuff there is, the more that can go wrong, and the more you have to inspect when it does go wrong.
        • Solve problems with no code if possible, or super reliable code, like HTML with no JS.

What does it generate?

  • Example: A simple animated gif maker
  • Scroll through unminified bundle as you talk about the code
  • Svelte utils
    • Very plain and straightforward
  • Component code
    • There’s a single current_component.
    • There’s a list of callbacks to call after various events. - There’s a schedule_update to schedule flush() (and therefore update()) calls.
      • Uses a resolved promise’s then() to schedule.
        • Promise then callbacks are run as microtasks, which go before the macrotasks (which setTimeout callbacks are run as).
        • Svelte itself doesn’t use setTimeout AFAIK, so it probably intends component updates to go before user setTimeouts.
    • There’s a list of dirty components. The dirty components are the ones that need to be updated.
      • Updating means to:
        • Run pre-update callbacks
        • Reset the dirty flag on the component.
        • Render the fragment (call the fragments update method)
          • Creates components for each objects
        • Queue up the post-render callbacks for the component
    • init() is when components are mounted. It will call components mount() methods, which will actually create the DOM elements for the component.
    • Generated component code is much more readable than most framework code IMO
      • Not unlike code you’d write yourself
  • Modules
    • node_modules
  • User modules
  • User components
    • The m function (mount) creates the DOM elements for the component. Looks like a series of insert and append calls, plus mount calls to subcomponents.
      • These are all also what you’d expect.

Rollup

  • An independent app bundler also started by Rich Harris.
  • The tree-shaking is incredible and easy. It’s what actually makes your app small.
  • Worth using all the time, even without Svelte.

When should you use Svelte?

  • If your app doesn’t do much with the DOM, not worth it.
    • Updated a large mostly-audio-and-network only app to use Rollup, but not Svelte. Got about 80% smaller!
  • There are some apps I see out there that could just be HTML, CSS, and JS in a <script> tag. Those should be just that.
  • If you have an app that already does DOM stuff and works fine. Don’t rewrite. Stop rewriting things in newer frameworks in general, don’t spend your life that way, you won’t live forever.
    • Definitely try Rollup, though.
  • Part of the reason I tried Svelte again is that, if I look for a job as a web developer, I need to be able to point to some framework
    • Hiring managers will think you are crazy if you say “frameworks are unnecessary for many of the situations they are used in”. Your foot won’t get in the door
    • That said, Svelte isn’t popular
    • Funny surprise to me: Svelte’s value for me ends up being purely technical in the end