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.
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.
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!
— Justin willis (@Justinwillis96) September 15, 2017
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
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 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 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.