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.

Conclusion

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.

Signup for the Ionic Newsletter to get the latest news and updates!

  • Tom McLellan

    Congrats Max & Team on taking a lead with this vision and making it real with Ionic 4! After moving a large code base from Ionic 1 to 2, I’m excited to see how we can adopt Ionic 4 and possibly Stencil, and how it will all tie together. Great to see the Stencil Hacker News app at https://hnpwa.com/ – impressive to see load times under 2 seconds!

    • yesimahuman

      Glad to hear that. We want to make sure we never have to have users do such a massive migration as 1 to 2 was. That’s incredibly disruptive and distracts from the cool stuff we want to build on top of Ionic.

      • Tom McLellan

        I’m curious to see how you prioritize between Ionic UI Kit (“being a UI layer for the web”) and Ionic V4 Framework as a “Code Once & Deploy to PWA Hosting & App Stores” solution. Beyond the UI kit, Ionic has been incredibly useful as a consolidating framework (and dev community) on top of Angular & Cordova.

        With Stencil as a web component generator, I’m assuming Ionic will be an end-developer framework (for PWA + Cordova apps with navigation, routing, starter apps, CLI, etc, presumably still using Angular) and also become a web component UI kit for other frameworks (Vue, React, Angular 1, etc).

        Thanks for being so open while making these changes. Excited to see it all unfold with Ionic 4!

  • a n onymous

    Please provide an alternative to JSX for templating.

    https://github.com/ionic-team/stencil/issues/94

    • yesimahuman

      Yes, we’d like to support that in the future. Of course, you can just use our plain web components and use this template system on your own!

  • disqus_NrkWMn1KOM

    What am I missing? A new Framework to solve the problem of too many Frameworks?

    • http://blog.khophi.co Nkansah Rexford
      • Thomas Opiolka

        it is a good joke but doesn’t fit the situation because they remove frameworks not adding them

        • http://blog.khophi.co Nkansah Rexford

          The principle still remains. No framework is added with the intention to be an ‘addition’. They all start as a ‘solution’ to remove multiple frameworks and streamline others.

          The result is history.

          • http://sampathloku.blogspot.com/ Sampath Lokuge

            Nothing lasts forever. So if you want a library to last forever, technology is not the space for you -John Papa

          • yesimahuman

            Except web standards last a whole lot longer than anything else we’ve seen in the frontend world! šŸ˜€

          • http://sampathloku.blogspot.com/ Sampath Lokuge

            Yep šŸ˜€

          • Junk

            You’re missing some real reality. Frameworks are typically independent efforts by small groups of developers who are sponsored by a company. For example, Angular has a core team employed by Google and React has a core team employed by Facebook. As open source projects they can be debated, forked, and developed collaboratively with the larger community, but frameworks are nevertheless in many ways more proprietary than open. Their roadmaps and APIs are influenced by the community, but final architectural control belongs to the core team. Frameworks are not standards. A standard is something created by a standards organization, in which multiple companies and independent engineers participate in a structured and usually semi-democratic process where standardizing what has consensus is the core mission. Today’s web developers seem oblivious to how important this nuance is and how important it is that the web platform is not owned by ANYONE. Frameworks play an important role, but web platform is not made up of frameworks, it’s made up of standards. The standards both enable and motivate the frameworks. And the standards, specifically because they ARE standards, have stability, reach, and longevity frameworks will likely never have. Stencil and svelte are tools to help developer productivity when implementing using web component standards, they are NOT frameworks. Nor are frameworks standards–although some frameworks do experiment with things that may someday become standards (see the extensible web manifesto). Stencil introduces some fragmentation in the sense that there are other tools that do similar things (e.g. svelte), but it’s the type of fragmentation that is needed to experiment with different approaches and serve different user preferences and use cases.

    • yesimahuman

      The point is that even if you use something like SkateJS, or Stencil, the output is plain web components that can be used interchangeably and with or without frameworks. It’s a fundamentally different situation than traditional frameworks that required themselves to host the components.

      For example, a bootstrap UI library using Web Components will work nearly everywhere and there’s little to no need to maintain specific framework bindings. I know I use React Bootstrap and it’s frustrating that it only has, say, 80% of the features of bootstrap core. ng-bootstrap might have a different set of those features but still only 80%. I think that’s unfortunate.

      We don’t really care if you want to use Stencil or not, but if you write vanilla web components that’s awesome and they will work everywhere.

  • http://blog.khophi.co Nkansah Rexford
    • Lanre HNiCs

      Lol I really love this…..

    • Lee

      Exactly why Stencil is awesome. It’s not creating a new framework or standard. It’s allowing developers to use an existing standard (that’s been around for 3 years) before it’s available in every browser. Similar to what Babel and Typescript do for ES6.

      https://www.w3.org/standards/techs/components#w3c_all

  • http://www.technbuzz.com/ Samiullah Khan

    So I was comfortable that Ionic 2 job will only need an angular guy but now I’ll see job listing as Ionic React or Ionic Vue. You people are creating framework churn not ending the churn. Now I am will need to learn React as well as Vue to hunt for Ionic job or I want to stay with Ionic Hybrid mobile development.

    • yesimahuman

      We definitely understand the conern here. The way we look at it is that Ionic UI skills will now transfer across the entire web development industry. It might mean that some jobs require Ionic with Vue skills, but we think that’s a better position than teams not able to use Ionic because they don’t use Angular.

      Think about it like this: this helps multiply and expand the investment you’ve already made in Ionic, making Ionic skills more valuable and the hiring market larger!

      • Junk

        I think it’s worth noting here that at the bottom this is pretty similar to previous generations of UI tools like Bootstrap. Back then, few people would have agreed that for a web application you’d base your ENTIRE tech stack on Bootstrap–Bootstrap was only for the design system. You’d probably also use a JavaScript application framework of some kind as well, not to mention the server side tech stack. Granted, it was a different time: there’ve been many positive evolutions since. But aside from companies like Google, different products done by different teams at different times within a company probably don’t have time to re-implement a design system’s worth of accessible and high performance UI components just to get decent branded functionality out the door. So despite the improved technology, IMO it’s still appropriate to draw a line between front end web application architecture and UX design system widget libraries as separate concerns. You shouldn’t be forced to choose between the several bad options you’re left with when you couple to a specific application framework. I gather that the React ecosystem feels this isn’t really a problem, that you should view all your UI code as highly disposable, but in 20 years I have rarely seen gains made when you throw away that much at the same time because there’s simply never enough resources or expertise to do MORE when starting from scratch than you had encoded in your previous efforts.

    • Xavier Lozinguez

      The point is that you can build Ionic using whichever framework you want. Even mixing frameworks so it satisfies whichever dev desires… And React and Vue people will be able to access the Ionic sweetness šŸ™‚

  • dgregd

    1. So Stencil is a new framework but it compiles down to a library with Web Components API. So devs will use that standard W3 API to work with Stencil components. Because of W3 API standardization process, the Web Components API should be pretty stable over the next few years.

    2. Currently it is hard to mix React and Angular components in one app. However a web component is similar to a HTML tag and therefore it will be easy to mix Web Components in one app. Stencil is one of a first frameworks which compiles to Web Components.

    3. Front End Devs will still need a high level framework like Angular to orchestrate Web Components interactions and manage app data flow.

    Now everything depends on quality of Ionic 4 / Stencil components. And I can not wait to try Ionic 4.

    • yesimahuman

      Yep, great analysis. To answer each:

      1. Correct, though we consider it more of a compiler than a framework. The core idea is that what it creates are just plain web components

      2. Correct. We are also considering a way to just generate component code for you, in that sense it’ll treat Stencil as a library and you maintain the component yourself. A unique ability of our compiler approach.

      3. Yes, but a few things. 1) you could use Stencil and get all of that, 2) there are more libraries now in “vanilla JS” land for things like templating and data binding, such that you could just use these components like you would with a jQuery app if you really wanted to, and replace those framework features with small libraries.

      4. You can see that now: https://corehacker-10883.firebaseapp.com/

      The performance isn’t even in the same league. We went from not being competitive in PWA land to being one of the fastest options, with the bonus of giving you a reusable UI kit! I’m proud of the team for doing a complete 180.

  • Jeffrey Chen

    This makes me confused. I was learning angular , typescript and suddenly these are not required. So, what is required for developing in ionic v4.

    • yustein

      I second this question. There needs to be a plain info text about what is required for ionic v4. Iā€™m tired of waiting for new things that will end the cycle of new things, which of course never ends.

      • yesimahuman

        See my reply above, thanks!

        • yustein

          Thanks!

    • yesimahuman

      You’ll use Angular and Typscript exactly like today. The only difference is most of the ionic components used in your templates will be web components, but they will use the identical or nearly identical tag name, like . You won’t notice a difference except your apps will be faster and smaller.

      This means that Ionic could be used in other frameworks for teams not using Angular, or as I’m suggesting here, with no traditional framework at all, only using web components with some additional optional library code.

      The reason you’d do this is for performance reasons. We’ve found that moving to web components enables Ionic apps to be considerably faster at load time and with much better lazy loading. This is crucial for Progressive Web Apps and modern mobile web apps.

      Happy to answer any other questions. The point of v4 is that some stuff is changing under the hood but ionic-Angular will stay nearly the same.

  • Guilherme Rosa

    Let me see if I understand:

    1. Ionic is using Stencil to build all Ionic v4 Web Components. Therefore, the code WE use has NO dependency on Stencil as Ionic v4 is 100% Web Components.

    2. We can then choose to use Stencil together with Ionic v4 to build 100% Web Component based Web Apps.

    3. We can also choose to completely not use Stencil and use Framework X or no framework at all.

    Questions:

    1. Will using Ionic v4 automatically provide the polyfill for Web Components in older browsers? Is this something we can choose to drop in case we don’t need to support older browsers?

    2. Since Ionic v4 is 100% Web Components, we no longer need to be married to Typescript to use it, correct? I assume if we choose to use Stencil, than Typescript is again required.

    3. Being Web Components only, I also assume Ionic v4 will no longer provide any hooks for Routing, Store, etc… If we want those things, pick Framework X or Stencil. Correct?

    • yesimahuman

      1. Correct, it’s all vanilla WC’s you’d be using. There is some loading code we do use for lazy loading but there are no external deps

      2. Correct, that’s totally optional and we don’t care if you’d rather use Polymer or something else as Ionic components will work just the same!

      3. Yep! WC’s bring back the potential to just write html again with a script tag and no framework at all and still get rich JS components

      And the q’s

      1. Yep! If it’s not needed the client won’t get the polyfill. You don’t need to do anything.

      2. Correct. You can use plain JS w/ Ionic web components if you like. Stencil does use TS so if you want to adopt that you need to use TS.

      3. That’s a good question. We do have an example router component for Stencil but it’s really just for web component apps. We’re trying to figure out what helper code you’d need to use something like that, but it might be the case that it Just Works as long as you’re willing to write some JavaScript to handle events and such. In other words, some WC’s don’t make a lot of sense without some javascript running in your app to interact with them (like a store or fetch component). Examples: https://stenciljs.com/docs/routing https://github.com/Fdom92/stencil-fetch/blob/master/src/components/st-fetch/st-fetch.tsx

  • Chris

    Thank you for your courage to make this tough decisions following the Web Components vision. I understand the neet for progessive web apps. I hope that the use case of the classical cordova app that works offline as well (yes this is still in many areas necessary) will still be supported and there will still be some Web Components clue code in Ionic 4 to be able to do a mobile app with cordova as well.
    Is there any roadmap for Ionic 4 or can you give an idea when there will be the first Ionic 4 version provided for early adopters?

    • yesimahuman

      Yes, Cordova/Native apps are still a primary focus for us! What’s good for PWAs is good for Cordova, and you should expect much snappier boot time and much better lazy loading with Ionic 4 for cordova apps. That’s still our bread and butter šŸž

      • http://sampathloku.blogspot.com/ Sampath Lokuge

        Awesome šŸ™‚

      • Chris

        @yesimahuman:disqus Thank you for your commitment to cordova / native apps šŸ™‚

        Is there a rough idea you can give to the time horizon for Ionic 4 (no official announcement just a rough estimation as an orientation 2-3 months, one year etc.) or is it really too early to say anything?

  • Olivier Eeckhoutte

    I love your ambition guys. Good luck in your mission and change the world šŸ˜€ ! Big fan

  • Marcus

    This sounds very exciting! I support any step that doesn’t make you bound to a specific framework. I have one question though. Even in Angular 4/Ionic 3 I’ve had plenty of performance issues when dealing with a large amount of components. The, very successful, solution to this has been to use ChangeDetectionStrategy.OnPush. Is this completely obsolete with web components, or how would one go about writing web components with similar performance gain?

  • Vinicius Alves Fonseca

    WTF. I’m migrating to React Native

    • http://sampathloku.blogspot.com/ Sampath Lokuge

      You’re trying to go wrong path. Trend is for PWA and mobile webs. But you? šŸ™ https://codefluegel.com/en/progressive-web-apps-trend-oder-zukunft/

    • dgregd

      Not all people are happy with React Native https://news.ycombinator.com/item?id=15293573

    • Lee

      Cool, and when you do, Ionic will follow you there when version 4 comes out. The question isn’t about which Ionic. It’s which framework, React or Angular? And which mobile delivery technique, React Native or Cordova. Ionic is just a UI – Bootstrap for mobile. They just sit on top of Angular because it was the best framework hands down when Ionic came out. Now that there are some other good contenders like RN, they’re becoming more agnostic.

      • Vinicius Alves Fonseca

        Nope. it isn’t about web framework. It’s about whether you will make a webview app, which has poor answer time to touches and scrolling and delayed UI responses, or a native app which uses software suited for the system where it runs and provides a rich library of design guidelines and native UI widgets that responds very well to user touches. There are no components in the web that fully mimics or overcome native components when it comes to performance and user experience. User experience is the answer, period.

        • yesimahuman

          A large number of companies and developers are very happy with the performance and user experience of their Ionic apps. Plus, now Ionic devs can move beyond the app store and target more platforms with the same code base. The web constantly improves and gets better, and is standardized and the most widely known technology stack, and Ionic lives and breathes it. These benefits are compelling for a lot of teams.

          We are fans of RN but we are proud to be web-first.

        • Junk

          I’m gonna guess you’re a pretty young person. I don’t think you’re getting the point here. Ionic wasn’t just for building mobile apps, and it used WebViews for a lot of things. It’s always been web first–so why in the world were you using Ionic and why is this the last straw for you? If you never cared about making web apps in order to take advantage of the fact that more people have web compatible devices than have specific types of phones, you should have moved to a tool that only output native iOS and Android code long ago.

  • OneFlip

    Many things to say to shower the Ionic Team with praise for their contribution to Web technology, but there’s one thing they will continue to need and which we wish them with: More staying power to you guys!

  • Brandon Baum

    If I tried to build my own version of React, I would probably end up with something similar to Stencil.

  • disqus_UueZQydIyU

    This sounds nice but what’s the difference between a web component and adding a plug-in via JavaScript? Thanks!

    • yesimahuman

      The big difference is that the browser automatically runs your Web Component JS when it finds a tag. That means you can literally just write HTML, and if your component is registered, the browser will load and run it natively. Imagine all those tags in Angular and React templates, your web components seamlessly run and take properties just the same.

  • cocowalla

    I *strongly* dislike the complexity of Angular. The possibility to use
    Vue – or indeed just about *anything* other than Angular – with Ionic,
    would be a wonderful, wonderful thing!

  • Avichay Eyal
  • Avichay Eyal

    Could you please explain if I am missing something: This post is about the “churn” of frameworks, taking under the definition of “framework” libraries like vue and react (which are focused on components, not web authoring in general).
    Assuming react is a framework, for the sake of keeping the conversation going, it’s syntax and usage is the overhead (as claimed in the post, a framework is needed to provide component model and a way to deal with custom elements, and since web-components are here, it’s is simply redundant).
    While claiming that, stencil provides a very similar approach as react does: it has pretty much the same syntax and concept (states, props, jsx), only this time it “compiles” to actual web-components (as opposed to virtual dom). The whole point of web-components is to provide all of the above WITHOUT the overhead of ANY library. web components provides natively a lifecycle, component state, and (very easy to use) templating options, making react redundant (im putting aside the virtual dom performance advantages). It’s all in the browser, zero libraries to use.
    The only major feature that native web components lack is automatic (or easy) data binding and auto rendering system.
    Now let’s take a look at stencil. The usage and development concepts looks (way too much) similar to react’s way (which at this point is redundant). React-like wrapper of… native behavior that doesn’t require a library in the first place? If stencil would want to provide a rich lifecycle, reactive changes (a.k.a. bindings), it could do it much simpler (like polymer does). What is the advantage of using the jsx overhead when you have es6 enhanced string literals right there in the browser? What is the advantage of the separation between “props” and “states” (natively exists in web-components: Object properties vs. DOM attributes)?
    If providing an imperative code style instead of the native declarative one is the point, than maybe jsx could be the solution, but there is absolutely no need for a whole library to do that, you could do it in 3 lines of code base-class with a render function that spits out compiled jsx.

    I’m sorry, but I just don’t get it.

    Churn of frameworks + Hey this is a new framework?
    React/Vue are redundant because of webcomponents, but stencil is… the same!

    Polymer, Skate, X-TAG are wrapper libraries to author web-components that simply wraps the native implementation in a simpler (or not, it’s opinionated) way. They also deal with the missing pieces in web-components: Auto update, too simple lifecycle, data-binding.

    slim.js is also (just another one) alternative, only with a slightly different approach in attempt to make development easier.

    But all of these are NOT frameworks, and just barely you could call them libraries, as they just add a very thin layer of functionality.

    Stencil doesn’t bring anything new to the table. Sorry.

    Please correct me where i’m wrong.

  • Chael Gutierrez

    Does this mean ? AngularJS will now have support again? When will this big change come?

  • Torah Bright

    Thank you so much for the greate article! I have noted all your points because I always seek the latest trends and innovations. It is important to know. I’ll keep it in mind. I would like to share the interesting information I’ve found here: https://mlsdev.com/blog/mobile-app-development-trends-for-2018