Scaling Components Across Multiple Frameworks

Hello everyone, my name is Adam Bradley, and I'm the Director of Open-source Technology at Ionic, and today I'm excited to talk with you about something that we've been working on that has helped us scale our UI library to many different frameworks.

So this is a React conference, and in order to scale your components to different projects, the answer is, well, you just use React.

So, alright, thank you for attending. Now that we know how to make components work across every single one of your web apps, across your entire organization, because as we all know, for the last 30 years, every single web app has only used React. So thank you for attending.

Alright, so I know I didn't fool anyone there. There might be this assumption that an organization is only on one tech, but what you see here is really closer to reality, especially as time goes on and tech changes. This talk is more for developers that are building components within organizations that fit within this category.

The reality is that many large organizations use many different frameworks and libraries and even different versions of these frameworks. Organizations are made up of numerous departments, and within each department, you can come across many different software teams. These teams handle a wide range of anything from content websites, web apps for both mobile and desktop, native apps for iOS and Android, and it goes on and on. And usually, each team gets to choose the framework that they'd like to work with.

So, while teams are choosing the software that works best for them, we very quickly run into some issues managing components with a consistent look and feel. And because different projects are started at different times by different developers using different frameworks, we often run into a lot of problems. It's common, but more of a requirement, really, that an organization creates a design system, basically being able to have a consistent look and feel between all of their web assets and software.

And here are some of the most well-known and widely used design systems. The most notable, I think, would have to be Google's Material Design. But those were just some of notable design systems that look great. The list goes on and on. While not all of us may have some cool fancy name for our UI libraries, or at least not yet, many have the same goals, and that's a consistent look and providing a well-documented UI library for various teams, both inside and outside of your organizations, to be able to use. And something that we've heard devs say many times is that they've created a design system and just expected other teams to start adopting it. But they quickly hit this wall, because other teams simply aren't using the same framework.

So if you want your component library to be used by different teams, then it's best to follow their framework's best practices and guidelines. This means you should be able to provide them components that already work in their framework. And a common theme is to use CSS-only libraries. And then each framework builds a layer on top of that common CSS library. This includes libraries similar to something like Twitter Bootstrap, but rather a custom CSS library for organizations. Now challenges with using CSS libraries within JavaScript frameworks is that the moment that the HTML structure changes or a CSS class change, basically all of those implementations no longer work. And there's this large risk here with trying to depend on a certain version of CSS libraries. This is where the idea of Stencil was first introduced.

And before I get too far, I really want to say that Stencil is not attempting to replace frameworks, or even act like a framework. React and all the others do an excellent job already. Instead, Stencil is a tool to help build components that work naturally in each of the different frameworks. It's to help developers create components that need to work in as many disconnected projects as they can. And to do this, it uses a common component model that all frameworks are built on top of.

So the big question is, but how could that even work? How can one component work in all of the frameworks? So for a component to work everywhere, then at some level there has to be a common layer that each framework interacts with. And no surprise here, the common layer is the DOM, the document-object model. This is the guts to how web pages and webex actually render and update our browsers.

React, Angular, Vue, all of them interact with HTML elements and text nodes to render their components. The part that's often missed is that all these frameworks render apps in our browsers because of the highly standardized document-object model, which is being used by billions of devices as we speak. And I can't even begin to imagine how many times the DOM has rendered a document since the beginning of this slide. Each framework stands on top of this common API, and the cool thing is the DOM can also be extended at the lowest level, which allows us to create components that can be used in each of these frameworks. This brings us to the custom element spec. It's a standardized API that's already built directly into today's browsers. And actually, it's been available without polyfills for a few years now. The ability to have a common low-level component starts with a custom element spec, and it's quite powerful in its ability to execute custom JavaScript for individual components within the DOM. The moment that a defined custom element hits the DOM, whether it's from document.createElement, innerHTML, using React Angular review, or whatever, when that element hits the DOM, the browser will execute the custom element's JavaScript. With that ability alone, Stencil is able to tap into the idea of generating a generic component that can work in all frameworks. And yes, despite a lot of the confusion out there, React can work great with custom elements. The part of passing data to these elements, like passing arrays or objects, is where Stencil Compiler is able to auto-generate the bindings for that, to help solve that problem. And no, I'm not even coming close to saying this is a replacement for React. But rather, I'd like to show how we've been able to build a React component UI library that can also be used in Angular in view, or with no framework at all, by using a common component, and the Stencil Compiler.

Now, relative to a full framework like Angular, React, or Vue, Stencil has very little run time. This is quite similar to Svelte, where components are generated by a compiler and only with the code that they need. And Stencil is also similar to Preact in that it heavily relies on existing web APIs already within the browser. However, one of the largest differences is how... The largest difference from a traditional framework is letting the browser actually notify when an element has been added to the DOM or when an attribute has changed. Now, Stencil components will extend the DOM's HTML element. And because of that, we're able to take advantage of existing APIs baked directly into the browser. And probably the most useful one here would be the ConnectedCallback method. With these features alone, Stencil components are able to manage themselves and really act as their own self-contained application. Beyond that, we've purposely restricted our components to only work with APIs provided by the browser. So to circle back to the original reason why we created Stencil, it was so we could maintain one core version of Ionic while also shipping Ionic React, Angular in View, and whatever comes next. Ionic is a mobile focus UI library for the web. But I don't really want to focus too much on Ionic too much here.

Rather, I want to review our requirements we have as maintainers of the library. It has over 100 components, and we face many of the same challenges as any other team out there. The fact is, frameworks, libraries, and best practices continue to change underneath us. However, the components themselves have stayed relatively the same. Sure, we update the design, we fix bugs, we handle issues, but that alone shouldn't require constant rewrites of each component.

If there's one thing I really want to make clear is that Stencil is a build time tool. It's a tool to help us generate and maintain reusable components. The problem Stencil is solving for Ionic is allowing our components to work in many of today's frameworks, but without having to maintain multiple libraries and different code bases for each of the frameworks. And an added benefit here is that we can also easily adjust to tomorrow's frameworks, or when one of the frameworks has a major break and change. And we can do this all without having to rewrite the component yet again.

A big challenge is that each framework handles assigning and reading properties differently. So while it's extremely well documented on how to assign a property to a React component, the internals of how that work under the hood is completely different to how it works under the hood for Angular and Vue. This is where Stencyl steps in to generate these framework bindings from a common component model. So let's dive into some code and create a progress bar component using the standard component model, and then we'll generate that into the different bindings for each of the different frameworks and show how to use that in each of the different frameworks.

Okay, so let's dive into some code and create a simple progress circle component. So here we're setting the custom element tag name, inlining this style, since this is a simple example, but usually you'd import a CSS file instead. And this component has three properties, size, stroke, and percent, and they act as both properties and attributes on the HTML element. And lastly, we have a familiar render function that returns JSX. Now, I'd love to use a standard templating language here, but the problem is that there's no such thing as a standard templating language, at least there isn't yet. And if we use another custom templating language, we're back to using just another framework. So today, the closest thing we have to standard would have to be JSX, and I think many of you would probably agree. So what we get is a self-contained custom element. Within the Dev Inspector, you can see that it changes around its attributes, and because it changes those values, the render function will execute again. And the same goes for editing the elements' properties. So this component works independently of any app structure and handles itself. This is the part that's really powerful, because now we can wrap this custom element with framework bindings and ship a framework-specific version of this component. But while also not having to maintain an additional code base for every single framework. And this is an example of the stencil config file, where we're able to have the compiler generate numerous output targets. In our case, we're having it generate source TypeScript files in the package's directory for all of React, Angular, and Vue outputs. But it's also generating just vanilla custom elements, and it's creating README markdown files.

So the left side shows the internal auto-generated component, and the right side shows the result of that component and how a React developer would use it. They would import and use these components no differently than any other React component. So for example, the JSX tag name is in Pascal case, which is just the expected norm for it to use with React components. Whereas a React developer, I'm sorry, with an Angular developer, they'll expect these component tags to be dashcased.

With Ionic Angular, we quickly realized that we needed to provide our users with Angular components and not custom elements. This is how Angular developers would import Ionic and use it in their template. It doesn't matter that the components are actually using component custom elements. To Angular developers, they're using Ionic no differently than the rest of their libraries. This includes inputs, form controls, host listeners, and all the other Angular APIs. And I'm not trying to convince everyone to hand-code custom elements instead of React or Angular, but I certainly can show how that custom element spec has been extremely powerful for Stencil to build framework bindings so that we can ship Ionic in each of the frameworks.

Now we talk a lot about JavaScript patterns in each component model, but honestly I think the most challenging part about a component is its styling. Just like having to find a common denominator for the component model, we also need to land on a styling that works everywhere, too. Luckily, the web standards has us covered here again, and shocker, it's something called CSS.

Now from what I've seen out in the wild, there's this love it or hate it aspect of Shadow DOM. I think the big discussion is that Shadow DOM is great for some things, but it's not the end-all solution for every single component problem. And in my experience, Shadow DOM has been great for Ionic especially since many apps depend on it and develop against our API. At the same time, we're constantly making improvements and changes to Ionic, but avoiding large, breaking changes in HTML structure and CSS classes. This is a challenge Ionic has since we're used by so many external projects.

A stand-alone app, on the other hand, that isn't sharing components doesn't have the same use-case as something like your design system. Think of the past major version updates for a CSS library. If the HTML structure ever changed or CSS class name changed, then its framework implementations often broke. Between Ionic v4 and v5, there was a major design update to closely follow material design in iOS. What I'm proud of here is how the many components had a major rewrite at all levels. But the user wrote these components in their apps no differently between v4 and v5. There wasn't specific HTML or CSS classes that they needed to change.

And stencil output targets go beyond just framework bindings. Using the same idea, the compiler can take information from each component and build various outputs. For example, it can auto-generate documentation and component data. It can also create components that can be pre-rendered on Node.js. The compiler is able to apply heavy optimizations after static analysis. And it does this by TypeScript walking the AST of each component. Every bit of metadata is then used to customize the run time and allow the run time to only use what it needs. And not only is it able to apply optimizations, we can use that information to auto-generate docs. The source of Stencil components uses TypeScript, and under the hood, TypeScript has many great features, one of them being custom transformers. In the before custom transform, we're able to gather useful metadata about each component. In the after transform, we can take that metadata and apply some optimizations to both our run time and user components. And there's no shortage of great doc-site generators. First one that comes to mind is DocuSource. With Stencil, we can generate a json file that includes metadata about every component in the library. This includes documentation for props, attributes, events, listeners, CSS variables, and many more.

So you're free to take this auto-generated data and plug it into any system, or you can just have Stencil auto-generate readme files, which work great inside of GitHub or npm. So to close this all out, you really cannot go wrong with choosing React. It's an excellent choice for app development. But what Stencil is solving is a little bit different. With Ionic, we wanted to maintain one code base, but work everywhere and be able to adjust quickly. If you have a project that has a similar use case, then a project like Stencil may be something to take a look into further. I want to thank you for your time, thank you for having me, I had a blast. Hopefully you try out Stencil and let us know how it goes. Thank you.

So let's see, we have asked our audience, what is your experience with web components? And 45% of them is the winner. They have said heard of them, but haven't tried. But do want to. And the runner up with 20% tried them and planning on using them in production. What do you think of these results? I think that's pretty positive. That's actually a lot higher than I thought it'd be. So that's cool, that's cool to see that people are kind of seeing the value of it and things like that. So I think that's a good, positive feedback. Yeah, that's always nice to hear that you made an effort to build something and people want to use it, of course. Yeah, right. Yeah, I know. But this is pretty cool because, you know, traditionally React and web components are usually, you know, button heads. And however it played out, you know, how a certain dev rel has happened for the two of them, it's been interesting. But what I tried to do in the talk was kind of, like, see past all that and try to just lay out, like, how it's been useful for us and how we use it and things like that. So hopefully people can also kind of see, like, how our use case helped us out and it might be able to help out their use case, too.

Yeah, well, talking about use cases, that's a nice bridge to our first question, actually. The question is from Frazili Shchalkov. And the question is, do you think it's still valuable to use stencil in the use case where a company's only using one framework, so probably React in our context, for all of their front-end projects? Can you give an example that proves why it's still valuable? Yeah, that's a tough one to answer because that's, like, trying to, you know, predict the future of what framework will be around for the next 20 years or something like that. And so I think if this was 2012, we'd all be saying, well, Angler.js is the way to do things. That's the best framework that everyone's using. My entire company uses Angler.js, so let's go all in on it and let's do everything with that. But as you know, times change, and React came out and Vue came out, and none of it got spelt, so it's difficult to predict the future, which is a lot of why we created Stencil for ourselves was that Ionic needed to keep adjusting. You know, and I guess I go over this again and again inside of the presentation. So because we had to keep adjusting, we needed to go to the lowest level of a element, you know, and that's just a custom element. And so through that, we're able to adjust for the future, you know, and able to adjust things like that. So for a company that is only doing React development, like if you're doing just a Web app, you know, with three other developers, and this is a self-contained Web app, and it's not sharing any of the components with any other Web app, things like that, then I think it's an easy choice to go with all in on React, because it's really not the same use case of what Stencil's trying to solve, whereas if you're trying to create a UI library, a design system that this Web app's going to use, the one that the marketing team, you know, in Europe is using, the one that the sales team in America is using, if there's all this shared components, that's where Stencil's a better use-fit for that, because then it's more future-proof in that you can adjust, like all these different components can stay to a certain version. There really is no version when it comes down to it. The compiler has a version, and a compiler can do different things, but for the most part, those components aren't versioned, and that's a good thing, because you don't know if they're using Backbone and they're stuck on Backbone, or if they could be using the latest React 25 or something like that. It's a tough one to answer, and I think it really comes down to your use case and how you're going to be doing your components. In our case, if it's something like a design system, then a design system for a large organization, then I think Stencil is a good choice for that. Yeah. I think that kind of tears it down for me. I was talking to Adam a little bit before, and the use case where I was trying to sell it to the company I was working at at the time is that we were working with a lot of micro front-ends. So it's one big web app with micro front-ends. They all used React. The whole team used React. But we don't know if we still are going to do that in five years, right? So maybe in five years you want to create one of these micro front-ends in Svelte or whatever new fancy framework comes out by that time. Then it would be really easy because they just have to build the logic, but all the front-ends, like the components, are there. And that's what I think really is the power that people can use Stencil for by being kind of future proofing themselves. Yep, exactly. Yeah. Awesome. The next question is from Zandro. Does Ionic or any other web component-based framework work in a micro front-end? When each integrated front-end app uses a different version of Ionic, the web components are global so they may overwrite each other. Yes, that is an issue with Custom Elements is that window.defineCustomElement is a global.

So Ion-button is there's only one Ion-button that can be registered to that window. So yes, that is an issue. If you had an app that had numerous versions of Ionic, that's where there would be a clash. I will say that I think it's the last one wins, so you could have a couple of them register. The last one is going to be the winner, or maybe it's the first one. I forget. Either way, there's not going to be an error. It's going to use the most recent one.

One thing we do specific with Ionic is put a lot of time and effort into making sure that we're just fixing bugs, we're improving things like that, we're improving the design. But the API itself, the properties, attributes, things like that, aren't changing. So speaking for Ionic, you know, I think that would be safe. There's always, you know, the challenge of breaking versions between the different things like that. But, yeah, I think that's a valid concern with custom elements and what things could happen. But also, you know, you don't really want to have many of the same design systems, many different versions of the same design system running on the same webpage. Hopefully not, but I guess once your company and thus your project grows and you have overlap of teams and the team members leaving, extra team members coming, then it can get tedious to maintain, I guess. Yeah. Yeah. And I do know that they are addressing this in the standards, but it's just nothing that's used today. Okay. So we'll have to wait for that problem to be fixed. But that's not a Stencil problem. That's a platform problem.

Next question is from Alex. Is there a future with Stencil where we don't need to have the framework-specific binding steps? Web Components seem so promising as a write-once-use-everywhere solution for our components, but it still seems like we have ways to go before it's really easy to get going with them, specifically talking about the page with React.

No, I do think it's going to be a ways yet until you can go without them. One thing that we did start with Ionic Angular when we first started this project around 2017 was that it could be all Web Components. It wasn't even going to have the Angular bindings. And we started with that during development, and we quickly realized that people are going to be expecting the output decorators and input decorators and having NG model work and all the Angularism things to actually work as they expect. And so that's where we kind of decided we can't just go all in on Web Components entirely because people still want to use Angular how they want to use Angular. So it kind of comes down to each of the frameworks and how much they are willing to adopt it.

Luckily, a custom element is really just an element. It's just a div that has callbacks for the most part. And so we can hook into any framework because they're all using the same DOM. So, yeah, I do think there's going to be a ways yet. But that's kind of the point of Stencil was that we can adjust to all of this. So like as Angular keeps improving or Angular keeps reducing sort of their footprint of what they're using, what they're not using, we can just keep adjusting the compiler. And then for us as Ionic developers, we're not having to change your components at all. We're still just maintaining the same one four years ago.