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, and… and…”.

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)?