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 has helped us scale our UI library to many different frameworks. This is a React conference, and in order to scale your components to different projects, the answer is, well, you just use React.
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.
2. Challenges with Different Frameworks
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.
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.
3. Working with Multiple Frameworks
For a component to work in all frameworks, there needs to be a common layer that each framework interacts with, which is the DOM. The highly standardized document-object model is used by React, Angular, Vue, and other frameworks. The custom element spec allows the creation of components that can be used in different frameworks. Stencil, a low-level compiler, enables the generation of generic components that work across frameworks, including React. Stencil has minimal runtime and relies on existing web APIs within the browser, such as the ConnectedCallback method. By restricting components to browser-provided APIs, Stencil enables the creation of self-contained applications. The goal of Stencil is to maintain one core version of Ionic while supporting multiple frameworks.
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.
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.
4. Maintaining Reusable Components with Stencil
Stencil is a build time tool that helps generate and maintain reusable components. It allows components to work in different frameworks without maintaining multiple libraries and code bases. Stencil generates framework bindings from a common component model, enabling the creation of self-contained custom elements. These elements can be wrapped with framework bindings to create framework-specific versions without the need for additional code bases.
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.
5. Component Usage and Framework Bindings
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. With Ionic Angular, we provide Angular components and not custom elements. Angular developers import Ionic and use it in their template just like any other library. The custom element spec has been extremely powerful for Stencil to build framework bindings and ship Ionic in each of the frameworks.
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.
6. Component Styling and Optimization
The most challenging part about a component is its styling. Shadow DOM has been great for Ionic, but there are constant improvements and changes to avoid breaking changes. Between Ionic v4 and v5, there was a major design update. Stencil can generate various outputs and apply heavy optimizations. TypeScript is used to gather metadata and apply optimizations. With Stencil, a json file can be generated that includes metadata about every component in the library.
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.
7. Closing Remarks
You cannot go wrong with choosing React. It's an excellent choice for app development. Stencil solves the problem of maintaining one code base while working everywhere. If you have a similar use case, Stencil may be worth exploring.
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.
8. Web Components Survey Results
The audience survey results show that 45% of them have heard of web components but haven't tried them yet, while 20% have tried them and plan to use them in production. This positive feedback indicates that people are recognizing the value of web components. Despite the historical tension between React and web components, the speaker aims to highlight the usefulness of web components in their talk and how they can benefit different use cases.
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.
Using Stencil for Different Use Cases
For a company doing React development with a self-contained web app, going all in on React is an easy choice. However, if you're creating a UI library or a design system with shared components, Stencil is a better fit as it allows for future-proofing and versioning. Stencil is particularly useful for large organizations and for scenarios involving micro front-ends. It enables the building of logic in different frameworks while maintaining consistent components. The next question is about the compatibility of Ionic and other web component-based frameworks in a micro front-end architecture where each integrated front-end app uses a different version of Ionic. The speaker acknowledges that this can be an issue due to the global nature of Custom Elements.
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.
Clashes and Framework-specific Binding
There can be clashes if there are numerous versions of Ionic in an app, but the most recent one will be used. While there may be concerns with custom elements, it is not a Stencil problem but rather a platform problem. The future with Stencil may still require framework-specific binding steps. Ionic initially considered being all Web Components but realized the importance of framework-specific features and decided to support them based on the needs and preferences of each framework.
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.
Benefits of Custom Elements and Stencil
A custom element is just a div with callbacks that can be hooked into any framework. Stencil allows adjustment to framework improvements and changes without altering components. Ionic developers can maintain their components without making any changes for years.
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.