JAXenter: Web Components are reusable elements for the web but they are still rather new. What is different about this new approach to web design, compared to other concepts?

Gil Fink: The Web Components standard isn’t new at all. The standard’s first drafts popped out around four years ago and are still in development. On the other hand, a new standard version was published in 2017 which changes some of the previous APIs and concepts. With the arrival of Micro Frontends concepts, the Web Components standard is getting much more attention lately as a way to share components between the micro-apps. 

With the help of the Web Components standard, we can create independent and encapsulated web components which can be reused across any web app any web library and any web framework. This can help us avoid the coupling to one specific library or framework (such as Angular or React) and publish our component to be used in our company or as open source. This ability is one of the strengths of using the standard.

JAXenter: How mature is the new standard? Are there still limitations to the adoption of Web Components?

Gil Fink: The standard is still in development and some parts are still working drafts. On the other hands, most of the browsers already implemented most of the standard and you can look at the table in webcomponents.org to see the browser support. If you want to be on the safe side, you can always add a Polyfill, which is a small piece of code that mimics the standard APIs and helps with browsers that don’t support the standard. You can find one of those known Polyfills here.

JAXenter: What is the biggest problem when working with Web Components?

Gil Fink: The biggest problem when working with Web Components, in my opinion, is our expectations from the standard. Let me explain what I mean. As developers, we are used to libraries and frameworks that give us out-of-the-box features such as data binding, lazy loading or performance. When you start working with Web Components standard you are supposed to craft all this magic with your bare hands.

For some developers, this sounds appealing. For others like me, it is super cool because the responsibility to create the component and all its features fall only into our hands. This is one of the reasons why developers still avoid the standard and prefer to jump into libraries and frameworks that abstract things away.

JAXenter: How does Stencil help with that?

Gil Fink: Stencil is a Web Components compiler. You write your components using Stencil syntax and it will compile and generate standard-compliant web components. Stencil includes built-in features such as reactivity, lazy loading, data binding and more. It does that by adding a small footprint code (around 6kb) to your components collection which includes the entire Stencil features. Stencil code is created using TypeScript and JSX which makes it opinionated but if you come from Angular or React background you will feel very comfortable with it.

JAXenter: Stencil was developed by the Ionic team. From your experience, is there any visible influence or similarity between the tools?

Gil Fink: As was stated in the question, Stencil is developed by the Ionic team. It was developed as an inner tool which the Ionic team used to create the new version of Ionic core. That means that the next version of Ionic core is generated by the Stencil compiler and will be standard-compliant Web Components. 

JAXenter: Does Stencil build truly vanilla web components or is it rather opinionated?

Gil Fink: The generated Stencil code is truly vanilla web components but it is also opinionated. Since the code that is written in Stencil is written in TypeScript and JSX, the compiled code is generated by both languages and therefore it is dependent on how they generate the code.  

If you want to know more about Web Components and Stencil, join me in my iJS session.