September 18, 2017
  • All

The end of Framework Churn

Max Lynch


Framework Churn: that breakneck pace of creation and abandonment that plagues the JavaScript community. Here one day, out the next. Hot today, obsolete in a year. Number one loved on the Hacker News frontpage, now number one hated on the Hacker News comments.

Framework Churn is something every one of us deals with in the JavaScript community. How do we know that big investment we’re making in Tool/Framework X is going to be relevant in a year, five years, twenty years? It’s at the point now that many are afraid to pick anything for fear it’ll be irrelevant long before the life of the product built with it.

At Ionic, we’ve seen churn first-hand. At first, Angular 1 seemed to be the end-all in JavaScript land, and we focused all of our energy on it. That period of relative simplicity didn’t last long, though, and soon there was a proliferation of new frameworks and tools that came and went. Suddenly, choosing Ionic meant betting on a frontend framework in a world that couldn’t stick with one for more than a year.

It was exhausting, and like many, we knew we had to break out of the cycle.

What causes Framework Churn?

To finally solve Framework Churn, we need to understand what a modern frontend framework is and why it causes lock-in and subsequent violent churn as it fades from the developer toolbox.

At the core, a frontend framework provides a component model that specifies how custom elements work and how they interact with each other, along with tools for templating, component loading, and more. Some frameworks are more “batteries-included” and come with utilities such as routers and animations, and while these utilities make it harder to leave a framework, their potential for lock-in is emergent from the component model.

The component model becomes the language of the framework. It’s the way components expect to be initialized, created, updated, rendered, destroyed, and how they communicate with each other. Generally, components built in one framework will not work in another framework due to the systems the framework provides to make the components run.

Thus, Framework Churn is due to incompatible component models that create interfaces that can’t be interchanged, and exacerbated by the rapid pace of innovation and powerful marketing forces in the JavaScript ecosystem.

Ending Framework Churn

To end Framework Churn once and for all, we need a way to create components that speak a language every developer and framework can understand. A component language that can be standardized but is also compatible with existing framework component languages.

Thankfully, there’s an answer: Web Components. Web Components are a modern web API spec with native browser support already in Chrome and Safari (and iOS!), with native support behind a flag for Firefox. For browsers without native support, a very solid and small (12kb) polyfill makes it seamless to use components.

At the core of the Web Components spec is something called Custom Elements. A Custom Element is just what it sounds like: a custom HTML tag that runs JavaScript that you specify. No more need for Angular Directives, or React Components, etc. Custom Elements are the holy grail of custom components: natively supported custom JavaScript browser elements that work like any other HTML tag.

It just so happens that these Custom Elements are the key to ending Framework Churn.

What about Framework X?

The best part about Web Components is they work just like any other HTML tag. This means that they are compatible with all major frameworks (*).

For example, once Ionic 4 is ready, the new Ionic Web Components will work in Angular just as well as they will in Vue and React (*). One major benefit, is that they will also work without any framework at all, making it possible to use the components directly for rapid development and even for integration into existing jQuery codebases!

This means Ionic will continue to support Angular but will also be able to support any other framework, making Ionic future-proof and ending framework churn for the project.

  • Right now React core has some issues with web components that can be worked around. However, Preact fixes them and we hope this is a short-lived issue

Using Web Components Today

Web Components are ready to be used today, and require nothing more than some JavaScript and a browser. You can write Custom Elements today using APIs provided natively in the browser (and supported with a polyfill).

Chances are, though, you’re going to want features you’ve gotten to know and love from Frameworks, like templating, efficient DOM updates, reactive databinding, and more. Tools like Polymer, SkateJS, Svelte, and Stencil bring those features to Web Components but without the need for a heavy, prescriptive framework.

Shameless Plug: Stencil

That last project, Stencil, is a project we’ve created at Ionic that will be the foundation of Ionic 4 and beyond as we port all of the Ionic components to standards-compliant Web Components.

Stencil is a compiler that generates plain web components for you, but with many features and a syntax you expect out of traditional frameworks. Things like using TypeScript, Virtual DOM for fast rendering, optimized async rendering similar to React Fiber, JSX for easy templating/UI, reactive data binding, and more.

Stencil creates Web Components with framework features as if you wrote them in yourself, but in a way that adds minimal abstractions that feel more like “TypeScript with WebComponents” than a full-fledged framework.

Stencil is new; we only recently announced the project at the Polymer Summit (watch the talk here). However, as Stencil will be a big part of Ionic 4, we are dog fooding the project heavily and development is progressing rapidly.

We don’t really see Stencil as another framework nor is adoption of it a major goal. It’s a tool that can help some used to framework syntax get into web components but we’re more excited about what it outputs: custom elements.


We believe 2017 is the year that web developers finally start to use Web Components in larger numbers. It’s going to take some time to reach mainstream usage, but the benefits are real and native support is improving rapidly. In fact, we’re betting everything on it.

For businesses, Web Components provide much needed API stability that traditional frameworks have failed to provide. A component built with web-standard Web Components will work without modification for decades. Not only will it run, but developers will know how to maintain it because it’s the web standard. Such stability is unheard of in JavaScript land today.

For Ionic, Web Components mean that picking Ionic isn’t making a bet on Angular. Rather, it’s making a bet on the web and the shared language of Web Components. We want Ionic to be the “UI layer for the web” and the only way for us to achieve that is to move to standards that will work everywhere and be stable for decades.

The era of Framework churn is coming to an end, and now we can all go back to working on what makes our apps unique instead of spending precious time, energy, and money jumping to something new every year.

I’m sure that’s welcome news to many that are exhausted with JavaScript churn and ready to get back to work.

Max Lynch