The Rosetta Stone — Örvar Kárason (CC BY-NC-ND 2.0)

My first Svelte component on NPM — and why it’s a big deal

Svelte is a promising technology that allows you to write web-components that are compiled into regular JavaScript.

Let me repeat that so that it sinks in:

Svelte allows you to write web-components that are compiled into regular JavaScript.

In other-words, you can write web components that:

  • are framework-agnostic
  • are interoperable & portable (they can be re-used easily)
  • don’t rely on a runtime that must be loaded in addition to the component

This is a big deal. Let me explain…

The promise (and illusion) of interoperability

The concept of web components (custom elements) has been around for at least 5 years. The idea is that anyone can write their own HTML element and all the browsers will know how to render it. Cool, right? Except the “all the browsers will know how to render it” part is a grey-area, with each browser vendor interpreting that statement in different ways.

Years passed. Interest rates fluctuated. Justin Beiber. Hipsters.

And then the “modern” frameworks arrived: Angular, Ember, React & Polymer (to name the most popular). Web components were finally possible! “I can write a web component in Angular and it just works EVERYWHERE… everywhere that has the Angular 1.x runtime installed, and is at least version 1.5, andand…”.

So while working on different code-bases, I had the following revelation:

One does not simply re-use a web component (but generating a meme is very simple indeed)

The promise of web components — interoperability — is an illusion. When you implement a component within a framework, your component can only be used within that framework (or require an adaptor/decorator to be created around that component).

“But I only work on <current favourite framework> codebases!”, I hear you cry. Well good for you! Enjoy a few more months of bliss and productivity. Then come back and continue reading this article once your current framework has undergone 1-or-more breaking changes. Or when your company nominates a different framework to use for future projects. It will happen.

Which brings us to the question of cost.

What will you do with all your existing framework-based components when you change frameworks?

Well, there’s always this option:

But you reap what you sow. So what will you do with all your existing framework-based components? It’s very costly to re-write everything. Would your customers be happy if they knew that 20% (or more!) of all development costs on a new project were due to re-writing existing components (which work fine with the old framework)?

A solution — JavaScript components

Svelte components are just JavaScript. There is no runtime. It can be used from any other JavaScript code-base (including React, Angular & Polymer). For example, here’s how to use my stylesheet-switcher component:

new StylesheetSwitcher({
target: document.querySelector('test-ssswitcher'),
data: {
id: 'mySSS',
label: 'Theme:',
stylesheets: [
{label: 'Light', linkHrefContains: 'light'},
{label: 'Dark', linkHrefContains: 'dark'},

The component is a constructor function, which takes a DOM element (the container for the component) and some data. (The API is pretty simple to learn too).

Since components are just JavaScript constructor functions, they are forwards-compatible with whatever the next amazing framework will be.

This means you can confidently invest in Svelte components because your runtime — JavaScript — is not going to be deprecated or changed in a backwards-incompatible way.
Well said, Fry.

What about “true” Web Components?

Browser support for custom elements and shadow DOM — “true” web components — is getting better. But it’s not possible to write a large application using web components without needing polyfills at the moment (unless you’re only targeting Chrome users using the latest version of Chrome).

Polymer 2 is a framework which provides a nice API for writing web components, but it still requires a runtime + polyfills. And while they intend that the runtime & polyfills reduce to zero (as browser support increases) — which is admirable — version 2 introduced a number of… um… breaking changes. True story.


I love the feeling of knowing that the code I’ve written can easily be re-used. It helps me sleep at night. Svelte is a tool that provides that feeling when writing visual components for the web. Having gone through the full process of writing, testing, documenting and publishing a Svelte component, I’m quite happy to recommend it to others.

So check out Svelte and vote for my PR to improve their webpack loader.

Thanks to Rich Harris and the Svelte contributors for writing such a performant and forward-looking tool!

And if you work for a large company, I’d love to hear how you are addressing the endless-framework problem.