Paul:
Hi there and welcome to PodRocket. I'm your host Paul, and today we're joined with Mike Harrington. Mike is a senior developer relations over at Ionic, and we're going to be talking about Ionic a little bit, and we're going to be getting more specifically into Stencil.js and talking about the great things that it can do for us in the web world.
Welcome to the podcast, Mike.

Mike Harrington:
Yeah, thanks for having me.

Paul:
You're a longtime Ionic-er, right?

Mike Harrington:
I feel like it's the term, the for-lifers.

Paul:
The for-lifer. Okay.

Mike Harrington:
Yeah. Yeah. I will be here for life. Yeah, I've been at Ionic for eight years. I joined 2014. We were just starting to release our first version of the framework. It was like 12 people at the time. I joined in and I was like, "This is my first startup. Let's see what goes on with tech world. I've never done this before," and I feel like I've made a big impact over these past eight years and I still enjoy what I get to do.

Paul:
When you first joined Ionic, you said it was like [inaudible 00:02:03] in the second version, so was there a different version of the product and company when you first joined?

Mike Harrington:
Maybe not a different version, but different rendition because the company had been around for a year before that building drag-and-drop interface tools and, after a little while, they were like, "Man, we're building tools for things that aren't that great. We could totally do a better job at it," and so we started building out our main product that still exists today, the Ionic framework, and we were just like, "Oh, this is becoming our big thing. Let's discontinue all the other stuff and just focus solely on this product because that's where we're going to be able to grow as a company."

Paul:
It was really a natural, like, "This is what's working. Let's make it work more."

Mike Harrington:
Yeah.

Paul:
Just for the folks who are listening who aren't familiar, what does Ionic do?

Mike Harrington:
Ionic is a platform for building cross-platform apps. You can use HTML, CSS and JavaScript, build a app for iOS, Android or for the web, whether that be PWA or just a traditional website, and you still get to have access to things like file system, Bluetooth, camera, standard, rich device APIs all through JavaScript and get to reuse all your existing web skills, framework knowledge and the sense of list of dependencies that could exist in npm or whatnot.

Paul:
We can use rich device APIs. We can use whatever we want. You can make it... I shouldn't... Not whatever you want. You can use a large variety, a large swath of things that you folks make available through paradigms that everybody's used to. You all must be really good at the web. You really understand the web. Ionic is like you speak Web. You guys, just like how Dory speaks whale, you speak web.

Mike Harrington:
I feel like we got a good hold on web fundamentals, CSS. We know all the weird hidden details that most devs won't know and shouldn't need to know, but, as framework developers and UI developers, somehow we need to know that box-shadows are terrible for performance, and so we don't use box-shadows.

Paul:
It's almost like niche knowledge that you're gathering, guys, and that must make you a really good partner to step into this conversation about Stencil.js because we're getting this talk about Web Components which are like we're new. I'm still discovering how to use Web Components because I feel like that's not super user handy yet. If I want to build out an app, I'd still reach for your traditional tools. Yeah, let's maybe start with just what is a Web Component and why would a developer want to use it given that there's murky areas out there right now and we're learning them?

Mike Harrington:
Yeah. Well, I mean let's start with the real basic example of a component that exists in the web right now, and that's like an input tag. An input tag has multiple parts inside of it. They have a part that you can type in. They have a part that you can use called placeholder. There is a caret position that you can control and that you can interact with. All these are parts of an input that you never have to think about. You can style it, you can select certain attributes of it, and that is essentially what a Web Component is, a bit of custom UI or elements that you can isolate to a single tag, have it be hidden from the users, creating almost like a private component API, and then your users can use that component without having to understand the internal knowledge of how does it handle setting the border radius on itself. It knows how to do that all internally and you, as the user, you just drop that tag into your webpage, your framework app or WordPress widget and it still works.

Paul:
Would calling this a top-level framework list React component for people coming from that world be a fair comparison?

Mike Harrington:
The terminology that most people try to use is a leaf component. It should be this own thing that is self-contained, doesn't need to talk to other parts of the app. It could be very isolated, and it just knows I have a property or an attribute that I have exposed and that, anytime value gets set on that, I know what to do with it. I can react to those changes. Outside of having the framework tell me how to re-render, this Web Component knows what to do and knows how to re-render.

Paul:
Do you think putting the onus of responsibilities such as rendering, such as border radius, such as things you might take for granted that, when I slap an input button on a page, does that create a barrier of entry to the Web Component world where it's like you should have some sort of mid-tier fundamental basis of knowledge before you set forth creating modular things that other people might use?

Mike Harrington:
I would say so. It's part of the reasons why I think Web Components aren't so ubiquitous. There's a lot of little caveats about it that make them very challenging to get started with if you're used to coming from Angular, Vue, React. Going in and diving into Web Components right away, you're going to need to know a lot of niche knowledge on how, for instance, if you set a property on something that doesn't automatically get reflected to the attribute in a vanilla Web Component which is completely different from, say, if you set a prop on a React component, it's automatically tracking that between an input value and then the prop value.

Paul:
There are two different objects to the dom and how they're being handled under the hood.

Mike Harrington:
Rich Harris actually had a really great blog post about Web Components and some of the little things that you don't know. It's a little older by now, but definitely something worth checking out.

Paul:
Rich Harris, and did you say that was a blog post?

Mike Harrington:
Yeah.

Paul:
We have other episodes on Web Components as well. If you're a listener and you want to learn more about it, I know we have at least one or two other more on the PodRocket podcast, go check out one of those episodes, for sure. This leads me into our next segment here, Mike, which is we've established that Web Components can maybe be a little unruly. You need to check yourself when you're stepping into that space. We brought you on to talk about Stencil.js because a viewer literally asked about it. Does Stencil in any way in your mind make that barrier to entry easier, lower?

Mike Harrington:
I would say it makes it easier, but also there are trade-offs to things. With Stencil, just like for... It's like an elevator pitch. It is a compiler for working with Web Components, and being a compiler is a super important aspect of it in that we know everything about your component at author time, so that way, when we go ahead and we run our build, we can generate optimized versions of what that will look like in a vanilla Web Component so we can handle the rendering, we can handle updating the props and attributes, and we can manage all of the finer details of that component while giving you, in my opinion, a simplified API that you can use to compose that component using familiar APIs from Angular, React and Vue.

Paul:
It's like an API to build Web Components that feels more familiar?

Mike Harrington:
If you're used to working with React, we're based on JSX as our templating tooling, and that should be something that you as a React developer can look at it and be like, "All right, I know what's going on here." We have concepts of internal state that feel similar to something like setState or, in Vue, refs. We have a component and decorators that feel very familiar for folks from Angular which allow you to set the tag name where you can locate the styles and CSS assets and more decorators that exist throughout the entire component that really make the plumbing work much simpler to get started with.

Paul:
If I wanted to try a hello-world of using Stencil, what would that look like? Is it a library that I import? Because you mentioned compiling and that's an important piece to recognize about the responsibilities of Stencil, so where does that fit into the development pipeline?

Mike Harrington:
The way we think about it is it sits just next to what would be your main app. The easiest way to get started with it would just be to run npm init stencil, and then you'd be able to get the components started with all the configuration all done for you and wired up, but if you want to integrate it with an existing system, you might want to look at things like a monorepo where the app can sit in a similar situation next to the components and then you're just importing them and letting the monorepo manage, pointing it to the right place. It's not another library that you could just drop into your existing tooling. There is some work to get started with it which, again, it's another barrier and trade-off that teams should consider and should be aware of up front.

Paul:
When you mentioned specifically like, okay, you want to build it at this step, do you think... I'm just wondering, if building it before we maybe do our regular build, is that a point you want to drive home because, if I'm thinking a typical monorepo setup, should I specifically be remembering I got to go into that pipeline, I got to make sure that this is being built beforehand, it's a dependency and it's just an extra thing we got to check in this process?

Mike Harrington:
The way that I see it, an ideal situation is that there is a components team that is working internally and they are just developing those components, and then you have your E-commerce team that's building your storefront, and maybe you have a marketing team that is building some other assets. It's more of a design systems approach where there is a core library that gets distributed to every other team, and it is just an implicit dependency that gets pulled in. Monorepos at that point are just a way to do that, but you could still do that with publishing it to a private npm or to public npm and being able to pull that down every single time.

Paul:
Right on, so it really depends, and it's malleable. I think one thing to note here is, too, you're emphasizing that this boils down to a bigger design question, but how are you organizing the teams and the way that our pipeline of production flows, the way we do our sprints because maybe this lends itself really well to having component library? Like you said, ideally, there'd be another team that's giving it as a product to the builders.

Mike Harrington:
That is a conversation that teams should have before just adopting any technology. It's like what's our overall flow going to look like? Especially with Stencil, being that it sits at a unique cross-section of how components can get added to your app, you need to be able to talk to different folks in your organization and make that decision on whether or not this is something that should be adopted or what needs do those other folks in your organization have and how can we accommodate them.

Paul:
If we want to step into the features of Stencil really quick just to give people bird's eye view if they want to get excited and actually search it off after we finish talking about it, what's a feature that you might find a typical developer coming in and say, "Oh, wow, that's like neat that I don't have to deal with that in the Web Component space, Stencil translates it in this easy to use way"?

Mike Harrington:
I think one feature is this app prop decorator. We have decorators built into the entirety of Stencil that, for prop, you can set a value and then an internal name like @Prop, first name, camelCase, and then that gets translated to first hyphen name, and then there's also a class property of first camelCase name where, as values get set, it is updating the attribute, the hyphenated version, and also updating the class property version as well it keeps those two in sync and lets you be able to just, "Hey, I don't care if it gets set on the element or if it gets set on the class. I just need to know that, whatever the value of this is, do something with it internally, render it inside of a tag, do something to it," and it keeps that in sync and makes sure that it is the right value all the time no matter where you read it from.

Paul:
This is powerful because it's blurring the lines between the two different paradigms that you'd find between the props and the classes and it's like, "Okay, I'm taking care of you. We're going to wrap this up into one nice API where everything feels unilaterally accessible with the same pattern."

Mike Harrington:
You don't even worry too much about attributes versus props. It's all the same thing. You just access it and, yeah, peace of mind.

Paul:
That's huge when you're developing. I mean there's a lack of peace of mind when you're writing things. You got 10,000 ideas ping-ponging around, so peace of mind is a very valuable asset in organization especially when it comes for free like that. It's always nice.

Mike Harrington:
A really cool part of it, too, is that it is immutable internally. If you have a prop and, for some reason, inside of a component method you decide to try to mutate it or change its value, it'll spit out a warning and then an actual runtime error saying, "Hey, props should only be changed from outside of the component. Don't do that," and you'll get all the linting errors, all of the static analysis and saying, "Don't do that. It's a bad thing to do," and you know it beforehand because we're a compiler and we can analyze the component and give you that detailed feedback.

Paul:
It sounds like it must do some sort of tracing about where did this value originally come from? I don't care if it looks like this. Where did the information come from?

Mike Harrington:
It's a very sophisticated build system built on top of TypeScript. All of the APIs inside of it are just transforms that happen and, because it's all TypeScript and we can have certain controls over what APIs you are using, we can get all that type information and feed it into TypeScript's diagnostics and then have that detailed reporting back to the user or your editor.

Paul:
You're realistically using the power of TypeScript to fuel your entire orchestration. I mean that's huge. TypeScript is tried and true. Everybody loves TypeScript. What about wrappers, Mike? What is a wrapper component? I've never heard of this in the space. Why do I want it?

Mike Harrington:
Without sounding like I'm picking on React, React is one of the few frameworks that doesn't support Web Components out of the box, and that's because of how React has synthetic events and it also doesn't differentiate between a prop and an attribute. There needs to be some massaging to get the Web Component to work in a React context. We, as part of the build process, have this concept called output targets or wrapper components where you can take the Web Component and then create a higher level proxy to that component, and it'll set up when, say, I have an event called onValueChanged or value change. It'll go ahead and, in the React context, create OnValueChanged and then it will make sure that that is a valid React prop and, when that prop gets called, it'll tell it to emit the underlying event in the Web Component realm.
We do this for Angular, React and Vue because React doesn't support Web Components that well. Angular can, but it doesn't understand it needs to help to provide, type the information to the Angular compiler. Vue also needs some help to be able to expose those components to something like their dev tools and their compiler as well.

Paul:
It's almost like you're saying, "Hey, framework, this component is going to exist here. We're going to shove it, so just trust us it's going to happen," and then they're like, "Okay. Hands off. They're going to take care of it." That's what you mean by proxy, right?

Mike Harrington:
Right. It's going to sit in there, and it's like the Vue component that you end up using is almost like a meaningless component. It's a functional component in the sense that it's just going to return something else. It's more just about the orchestration of how the component should sit in the framework context and then how should it handle the communication between events, props down to the original Web Component.

Paul:
There's a lot of gluing layers that this proxy needs to do as well.

Mike Harrington:
Unfortunately, it is one of the downsides to it, but the benefit is that, if you are someone who's creating a design systems, your teams can use those components and feel like they are just working with a React component or an Angular component. They don't actually need to care that it's a Web Component under the hood, which it might sound like a very superficial thing in some cases, but developers really love using components and APIs that feel at home to their framework of choice. Once you add something in there that doesn't feel framework native, they feel like, "I don't like this that much."

Paul:
The wrapper components, is that specific to Stencil? Is that a feature of Stencil in the compilation process?

Mike Harrington:
Yeah, I would say is a feature of Stencil. There are other frameworks. Lit also has that as well, but ours are something that you just set up in your config and then, as you go through and you run your Stencil build, it'll automatically generate that for you. Without you having to do anything, it'll just handle it.

Paul:
If I'm using Stencil, I want to write my first Web Component today, what am I going to write it in? Is this like JavaScript and HTML? I've never written in a Web Component, Mike.

Mike Harrington:
This is going to be all in... Well, it's called TSX. It's a TypeScript JSX, so you're going to be using JSX, you're going to be using classes, and you are going to be authoring it out like it's an old pre-Hooks React component with your JSX, your render, but you're also going to be having these directives to handle the higher level orchestration. It's not going to be HTML until you get to the time when you need to consume that component. If you know a little bit of React, you can get up and start up and running rather quickly.

Paul:
Because you're already using TSX.

Mike Harrington:
Yeah.

Paul:
What do you think about TSX versus TypeScript and native technologies in general?

Mike Harrington:
I was not a fan originally.

Paul:
Was?

Mike Harrington:
Yeah, I was not. I didn't think, because it's not technically HTML, and not to say I'm a purist, but it felt very far removed and there was a lot of different context changes that you needed to make to be able to like, "Okay. Well, now I got to remember add the curly braces to be able to do a map and be able to iterate over it." Now, I mean, I don't care too much. It's just a way to get things done. There's other problems I'd rather have arguments about, and JSX or TSX is just... It is what it is. I'll get over it.

Paul:
I think it's just worth noting it in the show because you yourself we're talking about a pretty well-developed, well-thought-out technology here, which is Stencil, the bleeding edge of web development, and I think it's worth noting that, even somebody like yourself, there still qualms with TSX, and it gets the job done. I think a lot of people are in a similar boat where they're like, "It's fine," but it's something to be said like it's not perfect and don't treat it as such maybe if you're using it.

Mike Harrington:
Because I jump around between React, Vue, Angular, Solid, all of these different approaches, they're all generally doing the same thing, it's just one happened to be painted blue, one happened to be painted pink, one happened to be painted yellow. It's all doing the same thing under the hood, just different approaches to doing it.

Paul:
Is Stencil going to be continuously released through Ionic? Is it released through its own separate project?

Mike Harrington:
Yeah. Actually, internally, it's two different teams. Stencil is just another project that we build, and we have one dedicated dev team for it. We on the Ionic framework side are just probably one of the bigger consumers of it. Obviously, we originally built it for ourselves, but we now have it picking input from various different teams and community members, so it's on its own release schedule, it's on its own cadence. They have syncs every now and then just to make sure features are going to work together, but it is its own thing with its own thriving community as well.

Paul:
Do you see any non-Stencil exciting things coming out from Ionic in Q2?

Mike Harrington:
We're doing a lot of work with our next major version of Ionic. It'll be a V7. It's going to be coming out at some point in maybe second quarter, but don't quote me on that. Dates are a very hard thing to pinpoint, but, yeah, we got our V7 which will include a new, upgraded version to Stencil 3. We also have a bunch working on our native technology side of the house where it's going to be easier to add a native control into an existing native app and then have a web version of that be rendered. We have this thing called Micro Frontends for Mobile which you can go ahead and just pop in a little what we call portal into your app and it will load up a whole web storefront or web UI in an existing native app, so a lot of cool things happening.

Paul:
Well, that's going to need to be something we'll have you on in the podcast for the future. If people want to hear about that, let us know. That sounds wild because mobile development is always different from web development. They're always on this path to convergence, and I'm like, "Are they going to be the same?" Not that they ever will be, but-

Mike Harrington:
Soon.

Paul:
Mike says, "Soon." I like that. I like the sound of that one.
Mike, where can people find you if they want to listen to you on Twitter or medium? Do you go on Twitter? Are you a Twitterer?

Mike Harrington:
I still have Twitter. I'm not leaving just yet, but I'm also not doing so much on there anymore just because it's so exhausting, but also Mastodon isn't that great or as great as people say it, it's not for me, but you can find me on there. I will post, MHarrington, like the real, original first initial, last name, and that's basically my handle everywhere.

Paul:
Well, Mike, thank you for your time and coming on and talking about Stencil. I certainly learned a little bit about the complexities of Web Components, and maybe they're a little less scary now for people who want to go check them out because having a opinionated framework to lead you through discovering how they're built is a great way to learn Web Components as well. Yeah, thank you for your time and see you around.

Mike Harrington:
Yeah. Thanks for having me.