Jack Franklin is working on Chrome DevTools as a Frontend Engineer at Google. He joins the show to talk about his article, "Why I don't miss React: a story about using the platform". He explains why he wrote his article and about his experience working with ChromeDevTools. Additionally, he dives into the advantages of Web components and its difference from React. He tackles all of the key points of his article. 

Welcome to another episode of React Roundup. I am your host today, Paige Niedringhaus, and I am joined by my esteemed panelists, Jack Harrington

 

Hey there!

 

and TJ Vantolle.

 

Hey everybody.

 

And our special guest today is Jack Franklin. Welcome, Jack.

 

Hey, thanks for having me.

 

Absolutely. So for listeners who have been listening for a while, Jack is actually a returning React Roundup guest. But Jack, maybe you could tell us a little bit about yourself for those who are new to the podcast and what we're going to be talking about today.

 

Yeah, sure. So my name's Jack. I've been doing web development and front-end-y things for coming on to 10 years or so now. Worked at a bunch of places, and most recently, I've been working at Google, where I work on the Chrome Dev Tools team. So I can't really avoid front-end development from both sides now, because obviously I do it day to day. Because a lot of people don't realize Chrome Dev Tools is a front-end application. It's all HTML, CSS, and, well, JavaScript slash TypeScript. So. Yeah, I spend my days building a tool to debug front ends. And then when I can't do that, I then debug my front end using the tool that I'm building to debug front ends. It gets very confusing very quickly. Uh, but

 

Yes, it's very

 

yeah,

 

meta.

 

yes. Uh, and if you break your own dev tools locally, you can't then debug. Why? Because you've broken dev tools. So it's a bit of a challenge, but, uh, yeah, I've been doing front end. Worked across a bunch of different frameworks have blogged and written about it for a while and yeah, just always find it. sort of plenty of interesting topics to talk about in the front end world.

 

So I think that the article that we recently contacted you about today is one that will be controversial to our listening audience. And it is actually about moving away from React. So maybe you could give us a high level summary of what you wrote and why you feel this way now.

 

Yeah, sure. So if we do link to the blog post, you'll see there's a bunch of caveats in the blog post, which I will repeat a little because half of the internet didn't read those and got very upset with me very quickly.

 

Ha ha ha!

 

No

 

Heheheheh...

 

I know, I couldn't believe it. What a surprise. So this really was a blog post, very much my opinion of an experience I had. The company I worked at before I joined the DevTools team was a React-based company. I spent a lot of time sort of leading React. front-end development there, and enjoyed working with React. And actually felt when I left and I knew that DevTools wasn't React-based that I would miss React. And I would find it very tricky to build this sort of big, complicated user interface without React and that that learning curve would be difficult for me. And really the blog post is just, is talks about how I found it, I found it pleasantly surprising and far less painful than I thought I would. And on reflection, looking back, I think, some of the things we're doing in the React world are making things sometimes more complicated. And really by picking any framework to control your rendering, you are putting a sort of layer between you and the browser. Now, regardless of if that's React, Angular, Vue, this could be any particular framework. Again, a lot of people took this blog post as a real hate on React. Really, it was just observing my experience of going from working with an abstraction like React onto getting something closer to the... one of a better phrase, the platform, which I'm going to use a lot. I don't really love it as a phrase. It's a bit cringy, but

 

metal. Some

 

the

 

people

 

metal,

 

call it, yeah.

 

that's even worse.

 

But

 

Yeah.

 

it's so not the metal. I mean,

 

No.

 

the browser

 

It's

 

itself

 

pretty far

 

has these

 

from the metal.

 

crazy level of abstractions of the DOM and everything else. I mean, you know. Yeah.

 

Exactly. Yeah. So, really the post-it is we on DevTools today, today I now work with custom elements, that sort of native ones built into the browser and a little library called litHTML, which is kind of a little templating thing. It will look very similar to JSX, that sort of approach. And that's all we use. And I really thought I would miss some of the things that React does for you, but it turns out that to be honest, I haven't at all. And that's not necessarily... That doesn't mean that React is a bad choice, but it means that maybe it wasn't as necessary a choice as I thought it might've been prior to sort of getting more familiar with this world where we have far fewer third-party dependencies and we really write a lot of it in-house ourselves.

 

It's sort of interesting because I feel like we went through a phase in the React world where there was a real push to try to make React and web components or just more platform features work better together. And there was a real push to try to make that happen. And I feel like we've almost backed off that a little bit. Like we were almost like resigned to our fate

 

Ha ha!

 

in a sense that like, like, ah, that's all right. We've been building React apps this way for a while. So. It's interesting to hear just a example of somebody that does give it up. And because it's, I think for a lot of us React is sort of your, almost like your expected baseline. It's just how you start building a new project, right? You don't think too much of it. Maybe you use something like Svelte or Vue or something, but very few people start a new web app by being like, oh, well, let me just create my index that HTML and start right just like randomly using some of the web.

 

Hehehe

 

some of the web fundamentals.

 

Yeah, sorry, I didn't know who was saying.

 

Yeah. Yeah.

 

I would agree. I think what I tried to get across in the blog post is I think a lot of people, as you say, the baseline or their go-to is React. And again, here for most of this conversation, for me, you could swap React out with big popular JavaScript framework.

 

Yeah.

 

And what I try to get across is, sure, there are projects where that makes sense. It is also... Unsurprising and not a criticism for people to pick a thing that they are familiar with and have worked with because they are likely more productive. And we'll be able to feel more enjoyment out of working with it. I think we've all had the experience of you, you try to use a new technology, whether it's a language framework, whatever it may be. And you end up like you want to learn it, but then you go so much slower because you don't know how it works. And you sort of bash your head against, against the desk. So I completely understand why people have their sort of, if you like, favorites and pick them over and over again. But what I was trying to get across in the post is that now and then I think it's good to step back and really consider for a given project, is this still the right choice? And what was interesting as well is from the sort of the Twitter replies I got around the time, some of them had rude words in, but some of them

 

I'm

 

were

 

sorry.

 

interesting

 

Yeah.

 

because they... they sort of said, oh, well, custom elements can't do this. Or I looked at custom elements five years ago and it wasn't very nice. And I was like, yeah, sure. But they've really changed a lot and they've come a long way. So I think a lot of people's idea of what they are is not really accurate. I think you can, you can, people would be pleasantly surprised by how much you can achieve if you were to pick them up now for a little side project.

 

And I think folks are, well, one of the big deals about web components was not being able to be server-side rendered. And I think I just saw something around lit recently where lit was actually, there was some sort of sauce on top of lit to like do SSR. So maybe that

 

Oh, nice.

 

is not an issue anymore or

 

So you get the

 

potentially.

 

SEO benefits that people are always after with server-side rendering.

 

Yes. Arguably, yes, but yeah.

 

Yeah, I think it is coming. I think it's further behind than the things are in the React and such world. I think there's also a few proposals to the web specification. You're going to push my knowledge. I think it might be called declarative shadow DOM. Maybe a thing that is needed to really enable it. And so it is, yeah, that is one case. Someone says, well, you can't reliably serve side render them now. So yeah, probably you can't, or you can, but you're going to have to accept it's an experimental thing that Lit is doing. But really, I think this is the benefit of web components is that they're baked into the browser. You don't have to ship any code to your users to enable their basic functionality. But the downside of that, if you want to call it a downside, is that

 

Hahaha.

 

they are baked into the browser. So people are understandably cautious about adding things that are baked into the language and the sort of the browser, because backwards compatibility is really important. I think we've seen... What was the controversy? Was it called smoosh gate

 

Yes,

 

or something where

 

smooshgate.

 

Thanks for watching!

 

a new method was added to JavaScript's API, but it clashed with Moo tools? It was

 

Mm-hmm.

 

something

 

Yep.

 

like that. And so they

 

Oh,

 

renamed it

 

okay.

 

to

 

Includes.

 

avoid it. And so backwards compatibility is incredibly important for good reason on the web. That kind of necessitates that things move maybe slightly more slower or with a bit more caution. Whereas if you're working, yeah, if I'm the React team, we really can do whatever we want to explore Surfside Red Ring because the consequences aren't quite as high as building this thing into the browser that ends up being the wrong thing.

 

So I did look it up. It is declarative shadow DOM. So your memory is correct.

 

Nice.

 

Hehehe

 

Woo!

 

Looks like it's still like sort of an experimental feature, but it is like a actual proposal. So hopefully that'll start moving in the right direction. I did want to ask though, we should probably back up for a second for people, because I'm sure we have listeners that have never even tried custom elements before,

 

Mm-hmm.

 

aren't really familiar with what Lit does. Maybe you could start by just explaining people. And keeping in mind, we have a React audience. If you were building custom elements like components, what is that, maybe not getting into the syntax or stuff, but what does that feel like? What does that involve doing? How do you go about starting doing that sort of thing?

 

Yeah, sure. So I would say to people who used React when there were class-based components, pre-functional components, I cannot remember the version number, but I think if you start building a custom element now, you will feel like you're slightly back in the class who extends React component sort of syntax. Similarly to how we used to have component did mount or component will mount, whichever one

 

Mm-hmm.

 

it is. In WebCommerce land, there's connected callback. which is for when the component is connected to the DOM. So put into the DOM. I can't remember the name, but I think it might be disconnected, callback, but there is a similar one for that kind of thing. And you can write code that says, that lets you know when particular attributes changed, much like I think React class components had a similar method for that, but the names are all escaping me. I think the thing that would be most different is out of the box, you don't have any form of JSX type syntax or HTML generation. So that's where, utility libraries such as lit HTML can come in. They just make it easier to use like JavaScript template strings to output HTML. And of course by default, React does all its stuff with re-rendering automatically when state changes, use effects and that kind of thing. You don't get any of that out of the box. A component, a custom element will not automatically rerun any code at any given point. You have to tell it what to do, when to do it. For some people that's a downside because you end up writing more code. Very subjective for me, I actually like that. I like having complete control over when my component does what and sort of managing that directly myself. It does look a little bit more boilerplaty though than say a React component where a lot of that is abstracted away from you under the framework.

 

And it looks just like essentially an extension of the set of tags that we currently have. You know, there's video, there's audio, there's image, there's div, there's all that. Right. You register one of these custom elements and then essentially you look at the HTML and it's just, you know, company dash, you know, header or whatever,

 

Hehehe

 

you know,

 

Yeah.

 

and that's, and that's literally the tag and you can give it custom attributes and there's custom properties and you can talk to it. And then there's this really cool shadow DOM thing that allows it to essentially be like completely self-contained, have his own CSS and everything. It's really cool.

 

Yeah, that's what's really nice about it, is if you use the shadow DOM, any styles you put into there will never leak out of that shadow DOM, so they can never impact anything else in the page. So a lot of libraries achieve this, a lot of them will do it by generating hashes next to the CSS selectors, whereas with the shadow DOM you don't have any of that build step or anything, because it's just you put div, and only the divs in that shadow DOM are styled by that CSS. Similarly, that will mean that... native browser events that you dispatch within that component by default are kept within that Shadow DOM as well, although you can configure that so the events bubble out, which is often useful if you want other elements higher up the tree to hear about them. But yeah, once you've defined it, the only rule is the name has to have a dash in it, which is how it knows it's not a built-in HTML element. It knows it's one that you've defined. And then you're kind of aware you just use them.

 

So if you're using something like lit HTML or some other non framework type of approach, how easy or difficult is it to get some of the benefits that react kind of bakes in like you know easy type script integrations or all the code transformations that it will do to bundle stuff up and get it ready for production, the minifying and transpiling and this, that and the other. Was that a lot of config work that you had to do on your end to deal with that?

 

Um, no, not really. I would say again, you're probably asking someone who definitely has some bias here, but, but, um,

 

I'm

 

it,

 

sorry.

 

it was fairly straightforward. And if anything compared to the last time I had to fight as sort of big webpack config, I know the world has moved on and we have other tools now, but that's sort of my lasting memory of, of react. Uh, I think it is slightly more straightforward because much more of the code that you've written is just regular old JavaScript or TypeScript. that the browser is going to run. You haven't got that sort of extra JSX syntax, for example, that that needs to be converted so the browser can understand it. The only thing you have to do if you're using TypeScript is run something that will just strip out the type information, but other than that, the code that runs in the browser will look almost identical by the types to the code that you have in your editor. And for me, that's one of the big wins is if you... pop open DevTools and you inspect your code, you can see what it is because it looks very similar to your answer. I know we have source maps and these are solved problems, but source maps can be fiddly. They're never always exactly perfect. And so sometimes it's nice to have that one-to-one mapping. I think as well, if people kind of want a sort of gateway into components, I think that lit is a really good little library for getting started. That this can get confusing because there's lit and there's lit HTML.

 

stencil

 

Yeah, I'm less familiar with stencil, but we've got litHTML is purely the templating parts where you put like HTML within template strings and it generates DOM for you. Lit does a little more. It provides you something that looks a lot like React components, but under the hood, it's all generating web components. So as such, its file size is much smaller because it's leaning on the browser a bit more.

 

I'm curious if it says you spent some time in this ecosystem. I think my, my honest biggest concern with sort of diving heaven head into this would be the greater ecosystem of sort of help support other frameworks and libraries. So meaning that if I run into a react problem and I had to Google or stack overflow, there's a very good chance I'm going to find somebody

 

Hahaha

 

to help me with my problem, a library that solves my problem. My problem actually might be that I find too much, right? Like I find

 

Yeah.

 

like conflicting things or whatever. And I always worry with some of these other technologies. Like it's one thing if you're doing your own personal thing and then whatever. But if I'm building something for like a company that I want to last for a while, like looking on Stack Overflow, there's very few questions for lit, lit HTML. right now. Like I'm curious what your sense is on the greater ecosystem of that. Like, are you able to find help with questions? Is there starting to become an ecosystem of different tools for people working in this environment, blog posts? I'm just curious what your take is on that.

 

I think there is an ecosystem, but it is smaller than that of something like React because of, you know, React is more popular and in this current form has been around for much longer comparatively, if you compare it to Lit. With no data to back me up, anecdotally, it feels like the sort of community is growing over time. You kind of see more people talking about it, more conference talks popping up about components. more companies talking about design systems that they've decided to build using web components rather than React or Angular for whatever it may be, largely because a web component can be dumped into any code base and will work. You don't need to bring in the big framework alongside it. So I think it's moving in the right direction, but it is smaller. But then what I would say as well is, at least in my experience, the surface area of what... Lit provides is much smaller than that of React. And what that means, I think, is there are fewer chances for you to get... Confuse is a bad word, but there are fewer things that maybe need to be Googled. That's not to say that

 

Thanks for watching!

 

Lit

 

Yep.

 

is going to be a completely smooth ride and everything is

 

I'm

 

perfect

 

gonna

 

and

 

go.

 

you'll never have any confusion or questions over it. But I was looking at the React docs the other day and I found the page of React hooks. And sure,

 

Ha!

 

again... biased,

 

Hehehehe

 

I'm

 

but

 

sorry.

 

there is a huge list of hooks, and there's just a huge amount there. And you have to understand the difference between use effect and use layout effect. And you have to understand why you would need to use a reference sometimes if you don't want to trigger a re-render. And these are things that, sure, you can invest in and you can understand them. They are also things that may well cause a bug. I remember teaching people React, and I would teach the use effect infinite loop bug. where you update something

 

Mm-hmm

 

that triggers the effect and then you crash the browser. And sure, it's a contrived example, but it happens, I have seen it happen in production websites. I have shipped that bug to production

 

Hahaha

 

myself.

 

Ha ha ha.

 

And I think sometimes with web components, it comes back to what I was talking about earlier where you control the full life cycle. You're not changing data and that is then triggering your framework to do something on your behalf. With components, you are... in full control of that. So I think sometimes you can get yourself into fewer kind of sort of situations where you are going to hit issues because you're maybe slightly holding the framework wrong because you've misunderstood something.

 

So is this something that you use in your day job? Is this, is dev tools using web components?

 

Yes, so not all of it, because it's a very old large code base, but we introduced Web Components about two and a half years ago or so. And since then, there isn't a concerted effort to migrate every piece of UI to components. We'd be doing that for years and we'd never ship any features because we were just migrating. But a lot of the newer parts of DevTools are backed with components. So there's the recorder panel which launched. I can't remember when, last 12 months or so, that's entirely web components, as is the

 

So neat.

 

performance insights panel, which is a new experimental panel, that's all web components, and large parts of other parts of DevTools are as well. So yeah, this stuff is being shipped like every day, into DevTools every day. We're writing it every day. The releases aren't quite daily. But also, I can dig out a link for your show notes, but people don't realize a lot of Chrome DevTools is open source. So if people are interested and want to see sort of what this looks like, in actuality, you can literally go and look at some of the code. So we can put a couple of links in that there are, there will be some slight, uh, dev tools, specific things in there, which will make it look a little bit different to sort of your average web component, but I think broadly you can see how the patterns start to start to apply.

 

So you said that web components started to get integrated about two and a half years ago. So before that happened, was the team evaluating different potential options instead of web tools? Or sorry, web components, were they thinking about using any of the frameworks like Vue or Svelte or anything like that? Or was it really kind of vanilla JavaScript or something more along those lines?

 

Yes, good question. So prior, like when DevTools first came around, what, 10 plus years ago, way before my time on the team, there was effectively a custom UI layer built in DevTools, which are called widgets. And that's what a lot of DevTools still uses. We did spend some time evaluating different options. I think the tricky thing with DevTools is the way we thought about it is, you know, if we rerun 10 years, and you had to pick the most popular front-end framework 10 years ago to back the future of building DevTools, then today I'd be talking about having to maintain a code base using Knockout.js,

 

Okay, query.

 

jQuery, Backbone.

 

Oh, knockout!

 

Knock.

 

Yeah!

 

Backbone.

 

Maybe,

 

Good

 

maybe

 

start.

 

backbone. Yeah,

 

Backbone?

 

I

 

Oh,

 

have to look

 

I'm not sure

 

when

 

on my

 

backbone

 

timelines.

 

don't

 

comes

 

get

 

out.

 

too crazy,

 

Yeah.

 

you've back

 

Don't

 

bowed.

 

quote me. Don't hold me to those dates. But as an example, and again, that's not to knock any of those tools. particularly jQuery, I think that's a very harsh time and it's

 

Oh yeah.

 

still incredibly useful. But now if a developer joined our team now, I'm saying, oh, we use Backbone. That would be an issue. That would also, talking about documentation and community, there is no Backbone.js community now, or certainly a very small one at best. And so really, I think for us, avoiding adding dependencies that could become unmaintained or severely out of date is sort of one of the ways we think about it. And for that custom elements became a kind of very obvious choice. Or to put it another way, to pick something other than that, like a React or a Vue, or lots of people think it has to be Angular because of the Google connection. Can we come up with a really compelling reason to add one of those compared to web components and keeping our stack a bit leaner? And the honest answer for us was we couldn't come up with like a really compelling reason to add that extra maintenance burden and literal bundle weight to DevTools and all the rest of it. And it just, it just didn't make sense for us.

 

So just because I wanted to fact check our timelines here. So jQuery's initial release 2006. So it is now, it's been now about 17 years old.

 

Wait, wait,

 

Wow.

 

2006, really?

 

Initial release

 

I mean,

 

Hmph.

 

2006.

 

I would have thought like 2001, honestly. Okay.

 

Backbone, backbone 2010 and Knockout also 2010.

 

All right, I was in the right

 

Oh,

 

ballpark

 

so those

 

then

 

were

 

I was.

 

the hot frameworks.

 

There you go.

 

So yeah, those are, because if their initial releases were 2010, I imagine by like 2012, 2013, they were the hot things. So yeah,

 

Yeah, yeah,

 

you're pretty spot on.

 

nice.

 

I'm out.

 

Ha ha ha 

 

Gosh. Okay, so one thing that I wanna hear more about is you talk about using the platform.

 

Yeah.

 

As a React developer, as a Svelte developer, as a person who likes frameworks in general, what are some of the things that I just don't know the platform is even capable of in today's platform world? Because I'm sure there's a lot probably that I just. I know how I used to have to access it. I know what packages I need to pull in from NPM. So what am I missing? What do I need to go and explore more about now?

 

Yeah, I think there are sort of two, two sort of categories of things. We could answer that question. I think the first is things that have been built into the platform for forever. That for whatever reason, frameworks typically don't make use of. And the prime example there, I think is the event system that's baked into the browser. So we are, when

 

Hmm...

 

you, when a user clicks on a button, you get an event. But, um, and I didn't know until I joined Google and someone actually showed me. You can make any class be able to dispatch and listen to events by having it extend a built-in class called EventTarget. And now what that gives you is any class, and WebComponents extends that as well, by the way, is able to dispatch events. And so this was really surprising to me because I'd come from a React background where the pattern is you pass in a prop called like onFooChange equals brace this.onFooChange

 

Mm-hmm.

 

then you do at click equals on foo change, click that, it fires the prop which pass it up. Then if that callback function is changing a bunch, you might have to wrap it and use callback or use memo or both or neither or who knows. And you have this whole kind of bunch of code that in the browser lamp, we can just do this dot dispatch event foo and then in its parent, we can listen for that event that's built in. And that does exactly the same thing. There is far less code attached and it's more efficient because you're not passing down a callback function. that may change on every render and therefore trigger any form of re-rendering. So I've been like that I'm sure there are reasons, right? And as the people who make React, et cetera, are very smart people, and there will be reasons. But I've been very surprised with how far you can get with built-in browser events. And I don't think enough people take advantage of that, which is just baked in this event system which comes into the browser for you for free and is very good. and reliable and obviously pretty robust by this point in time.

 

Yeah, we always tend to go straight to NPM. It's like, Hey, if I need something, I'm just like, boom, NPM.

 

Right,

 

And you're like,

 

left

 

Yeah.

 

pad.

 

okay,

 

Yeah,

 

right.

 

yeah.

 

And, you know, but there's just so much you can do. Like I remember I was working with the audio API and I mean, I guess I would kind of normally think, Oh, wow. I'll just go to, you know, NPM for that. That's not something that would be built in the browser, but it turns out there's this crazy, huge audio API built right into the browser and it's cross browser and it's fantastic. And you don't need anything. It's just, it's just the error. And because of TypeScript, I mean, honestly, oh my God, there's a libdom TS file that has like every binding for everything that's in the browser. It's enormous.

 

Yeah,

 

Yeah.

 

I think that's a really good example of people just don't know what's built in. I think there is some form of messaging that the web platform needs to get better at to sort of broadcast these changes. I think I tend to see what happens in JavaScript land with proposals to the ECMAScript spec, but broadly I think a lot of people who don't mess around on Twitter for half the day or I think it's just very

 

Hahaha.

 

easy to not see what's happening or what is changing. And then in particular, I think you see like Chrome has added support for feature X and say, oh cool, but until it's in everything else, I can't use that. But then it goes into everything else, but we just miss that that has happened. And suddenly this whole feature that you'd written off as like Chrome only two years ago is now no longer Chrome only and could be relied on. So the example I use in the blog post is building a form. So I reached for, I think there's a popular route, was it called Formic? There might be one called Formic.

 

Mm-hmm.

 

Yeah, yeah,

 

Yep.

 

formic.

 

And again, I'm not gonna, this is not to criticize Formic, but that was always how I would build forms. But I decided to just try and build it natively. And HTML validation, let me do sort of basic, minimum, maximum length required, ensure it's a number, kind of stuff like that. Sure, it can't do everything. And if you have really complex set of requirements, you're probably gonna need to write some code. but I just, I didn't need to. There's then an API called form data, which again has been in the browser for a long time now, which you can just give it a form and it will give you effectively an object with all the names of the inputs and the values of those inputs. So you don't need to keep every single one in state and always update the state or anything like that. You can just grab it. And then when you use HTML validation, you say it's a required field, the browser will pop up saying you haven't entered a value into this required field. Or it has kind of a default message that it shows. Sometimes you want to customize that message or how it looks. I then learned there is also now a constraint validation API. So you do have some ability to customize the validation messages that are shown by the browser to the user. So we can achieve all of that without having to add one library from npm at all. And

 

amazing.

 

sometimes you are going to

 

Yeah.

 

need a library from npm because you have a more complicated set of requirements. So again, I'm not. A lot of people took this blog post to mean like never rely on any dependency, but that wasn't what I was trying to say. It was trying to say like the barrier to adding a dependency is perhaps could be higher than we maybe think it is at the moment. I think forms are a really good example of that.

 

It's funny, this conversation is reminding me. So back in 2014, I wrote an article that was several years before yours, but I wrote, why web components aren't ready for production yet?

 

Ahahaha!

 

And

 

Ha ha!

 

I think the same people who reached out to you on Twitter were also talking to me back then

 

Hahaha.

 

because, as you can imagine, I heard some opinions based off that.

 

Yeah.

 

But

 

Yeah.

 

my argument at the time... was that the biggest problem was that polyfilling web components was just awful. And so I was like, we have to wait until this is like natively in all the browsers we have

 

Yeah.

 

to support. And back then there were more browsers and I was like, you can't like if you're shipping production enterprise apps, you can't be using this, right? You can't be toying with this. Just wait a few years. But it's funny because web the web world moves kind of slow, right? It's not like. the, they appeared in there slowly, but as years go by, it's like, Oh, if you're not actively in that world and thinking about it, you're not thinking about, Oh, Hey, some of these cheap features are shipping and it is

 

Mm-hmm.

 

appearing in all these browsers. Cause it's, it's not like you necessarily get notifications of like, Oh, that last browser I was waiting for

 

Yeah.

 

has it.

 

Woo!

 

And, and like all my users are there. Right. So like, even I, like, I lose track of like, beyond the basics of like, when you mentioned declarative shadow dumb, I'd never heard that phrase before. in my life, right? So, but it's, and now it's back there, but I'm gonna forget about it immediately after this because it's not in any browser. So I can't

 

Hahaha

 

actually use it. So when it becomes usable in 2026 or whatever, like it's gonna

 

I've

 

take

 

completely

 

me a few

 

forgotten.

 

years. It'll take me a few years to remember that and to actually start using it. So it's just sort of funny how that all works.

 

Yeah, the hope is by that point, you will see a conference talk or a blog post or something on it

 

Yeah.

 

when the time comes. But it's tricky as well because people will write when it's in Chrome. I actually have no idea if it's in Chrome, the declarative shadow DOM or not. I couldn't tell you which browser it is or isn't in. But some people now will write blog posts about it because they're excited about it and they want to draw people's attention to it. And that's exciting. But then you see it and you think, ah, it's crime only. And that kind of... then the next few times it pops up, you'll be like, oh, but it's probably still Chrome only. So then you've

 

Mm-hmm.

 

got this sort of delayed effect until you think, oh, maybe now I should check it because, yeah, it's 2026. And maybe it is now in every browser. And so, yeah, there's something there in terms of how we can do a better job of communicating when features go from experimental to stable, but only in Chrome or only in BrowserX to, hey, you can actually properly use this now. reliably across all your browsers.

 

Yeah,

 

I don't quite

 

I ran

 

know

 

into

 

what

 

this

 

that looks like.

 

same thing with container queries, because

 

Mm-hmm.

 

I'm stoked about container queries. I'm just over the moon about

 

Yep.

 

the potential there. And a lot of folks are like, yeah, this is great, good. And then about half of the audience was like, 74% can I use is not enough. And I'm like, but there's a polyfill. It works. And they're like, no, no, no. Can't do it. I'm like,

 

Yeah.

 

are you kidding me?

 

I feel

 

So.

 

like that's, that's the story of CSS Houdini too. They've been talking about it for so long. There's so many cool examples of it. If you have a browser that supports it, but it's still, it still hasn't gotten that first-class support everywhere. And until it does, everybody's going to be afraid to use it in production for that very reason.

 

Yeah, I feel like I need a notification system. Here's my next product idea. Like after a feature has reached like, I don't know, what is the minimum barrier now? What's our last holdout? Like been in iOS Safari for like two releases, like two yearly releases. I don't know what the barrier is, but some is like, this feature is now ready for like your enterprise production app, go nuts, here's what this feature is. That's

 

probably

 

the service

 

Safari.

 

I need to exist.

 

IE is gone, so probably Safari is the next

 

Oh yeah,

 

oldest held out.

 

IE is now just Chrome.

 

Hehehehe

 

Yeah, you could like poll can I use.com on a sort of 24 hour basis

 

Right.

 

or something. That's

 

Yeah,

 

kind

 

I just

 

of what

 

need

 

you

 

like

 

need.

 

a, a, a, can I use subscription? Yeah.

 

See ya.

 

Yeah. Yeah. Yeah. We should, we should talk to them about that.

 

Yeah. Can I, can

 

Yeah.

 

I use pro?

 

Yeah,

 

There you go,

 

Exactly.

 

money

 

I'd

 

making.

 

pay for

 

There

 

that,

 

you go.

 

you know? Pay for dumber things, blame me.

 

Yeah.

 

Well, is there anything that you think that we haven't touched on, Jack, about React, about using web components, about custom elements, or anything else that you'd give advice on or want to talk about in regards to this?

 

No, I think maybe a good place to finish it off is talking about the cost of third party dependencies and we mentioned earlier that the bar, people's bar to when we use a custom bring in a third party dependency or not. Because I think that that's a large part of the blog post that I think is interesting and also isn't specifically about React or any particular dependency. It's just sort of a general... kind of rule of thumb that I've been trying to stick with, which I think is helpful to think about, or at least interesting to kind of push some perspectives on.

 

Yeah,

 

Um.

 

absolutely. I mean, the thing that immediately comes to mind when I think about third party dependencies is the JavaScript bundle size, because it's always gonna bring in more code into your project. And then the second thing that comes to mind, because it seems like it's been happening more and more lately, is that you're opening yourself up to potentially malicious code. So maybe you

 

Hmm.

 

could dive a little bit more into those, into what else we need to consider, really.

 

Yeah, so I think I thought about the cost in my blog post. I think I listed three. So bundle size, as you said, I think that's the most obvious and one most people think about. I didn't actually list malicious code, but I had one called risk of unmaintained code, which I think we could kind of bucket into the same thing. And then you've

 

Yep.

 

also got breaking changes and upgrades

 

Mmm.

 

as well as the sort of final ones. Those are the three that I pulled out. Jeremy Keefer wrote a good blog post on this and I just quote him here, every dependency you add to a project is one more potential single point of failure, which I think is completely true. And again, the narrative here isn't so you should never use a third party dependency. That's not. But what we're saying here is there is a decent cost to a dependency and that dependency you're bringing in is going to solve a problem for you. Is that problem that it's solving worth the cost of you bringing it in? So a good example is on DevTools, I've talked about how we try and minimize dependencies that we have from third parties for this reason. We use a code mirror for all the syntax highlighting, code editing stuff that's

 

Mm-hmm,

 

in DevTools.

 

yeah.

 

That is a big dependency. I don't know

 

Hmm.

 

the actual size of it on disk, but that's a lot of code, that's a lot of features. And if that were to suddenly go away, that's quite a big job. What do we do with that? That's quite an issue for us. At the same time, directing X people from the DevTools team to build a code editor into DevTools with all those features, all the syntax highlighting, whatever else it does, about a million things that we rely on. The amount of time and energy it would take for us to build that ourselves is huge. And so therefore, sure, there is a risk to using CodeMirror. Hypothetically, it could disappear or it becomes unmaintained. But that is... worth taking because else it would take us years probably to build what it gives us. So therefore that is a worthwhile trade-off. I should be clear as well, I'm very much hypothetically here. I'm not saying that I have any reason to suspect CodeMirror disappears or becomes unmaintained,

 

Hahaha

 

but that's kind of

 

I'm sorry.

 

like where we're getting at. But if CodeMirror just did one tiny bit of functionality for us that maybe we could build in a few weeks, we might decide that it wasn't worth the risk and we would then build it ourselves. So it's just this constant trade-off that I think people should think about. I think one of the issues we had in the past is that when like NPM and webpack became prevalent for front-end code, they really hid away the details of what code you're adding to your bundle.

 

Yeah.

 

Like you just did NPM install foo, require foo.

 

Yeah.

 

Great. It works. Brilliant. For some projects where you don't care about bundle size, side projects, internal apps, whatever. Great. But they hid those details away, and people didn't realize really the impact we were having on the final website that you were shipping. Another thing we do on DevTools, which could be a whole other episode because that also made the internet very angry, I wrote a blog post about how we check our node modules folder into Git. So it's in the Git history.

 

Really?

 

Wow.

 

Yeah, so there's another blog post on my site about this. So I'll sort of steer away from the controversy that people found about that.

 

Yeah

 

The reason we do that is primarily security because it means we don't have to run npm install at any point during the, like on our CI bots and that kind of thing. But what's really interesting is when you start committing your node modules into Git, you really realize when you've installed something that is very heavy and has a lot of

 

Yeah.

 

files or a lot of code

 

Thanks for

 

because

 

watching!

 

you literally see it in the diff. Yeah, people thought that blog post on node modules was telling everyone to commit their node modules to Git. That wasn't the case at all. But there is something interesting about when you start, when you actually add those dependencies to node modules and you then have to commit them into your Git repository, it kind of makes you more aware of what you're adding and the amount of code sometimes that you are now committing to in some ways maintaining, or at least sort of having in your code base. And so I think, you know, if we could rewind, npm and webpack did amazing things for the web community. And, you know, that was largely very much positive things, but... I think the layer of sort of hiding away what actually happens when you add a dependency to your project made people not think about it as much. It made it like so easy to add that we didn't think about the potential downsides further down the road.

 

Yeah, I added in the show notes just on a related topic, a site called Custom Elements Everywhere, which tracks how custom elements are supported in the different big frameworks. And a lot of them do a great job with them. But React in particular is pretty bad, actually, in their custom elements support. But it's good to know if you want to use a combo of React and custom elements.

 

Well, actually that leads me to, I think my last question for other Jack. Um,

 

Hehehehe

 

if people, like if a React developer wanted to start tinkering with this stuff today, what is your recommended path to like get going? Should you try to integrate some of this into your React stuff? Do you think a clean break is good? And then also like, are there any like tutorials or just, should you just check out the docs, what sort of recommendations do you have there for starting stuff?

 

I think if you want a gradual path into it, I think LIT is the best way to go. Now, you don't have to. There are other frameworks that you can use. I'm more familiar with LIT than others. But they have very good tutorials on their website that will teach you a bit about custom elements and teach you what LIT is adding on top of that. Also, I think if you use the build tool, is it Vite or Vite? Vite, I think.

 

Vite.

 

I think it's Veed.

 

Vite.

 

Vite.

 

It's the French pronunciation

 

It's the French,

 

Yeah.

 

of

 

right?

 

Vite.

 

Yeah, so it's Vite. If you

 

Yes.

 

use VEAT and you create a new project, they have a template for LIT with TypeScript, I think, baked in.

 

Thanks.

 

If you

 

Cool.

 

just want to get up and running in that sense, that is probably the easiest way to go. But what's nice, of course, is the components that LIT generates are custom elements, so you can then pick them up. You can render them in React, although React support for custom elements isn't... the best always. You can easily have like render a div and use a reference to then hook into that div and dump your lit element within there. That will work. You can use Web Components with any other framework, again, checking the support that that framework has. I think otherwise, if you really wanted to go, okay, what is just in the browser and what do I get for free? Then I think the MDM docs for custom elements are probably the best place to start. They're also guaranteed to be up to date as well because Many years ago, there was a custom elements experimental spec called the v0 spec. This is very confusing. It was in Chrome for a while. It was never, ever intended to be the spec that made it across all browsers. It was solely experimental. It was always planned to be removed. But I think some of the messaging at the time led people to believe that that was going to be around forever. So there was some frustration there. But anyway, you just have to be a little careful if you are searching for custom elements. sort of info or blog post that you find relatively recent blog posts that aren't using this old now removed and defunct spec. So if you start with MDN, you'll see what the new spec looks like and that is a good starting point.

 

Excellent.

 

So before I jump

 

Awesome.

 

into pics, I mean, what are our action items for any listener to be, Hey, before you jump into NPM, go check in MDN, you know, to go and see if there are things that in the browser that you can just use. Cause I mean, wow, there's a huge platform there.

 

Yeah, I would say so. I think at least, at the very least, it's worth a look at first, even if you then ultimately decide that you need this third party thing to solve your problem. That's fine. But I think it's worth having a look and consider what you maybe might not need a dependency for.

 

Yeah, knowledge is power.

 

There

 

Yeah.

 

you go.

 

Well, awesome. Well, if anybody wants to get in touch with you, Jack, what's the best way to reach you?

 

Oh, I was going to say my Twitter name, but I'm not really on Twitter anymore. Um, I'm on, uh, what is it? It's it's indyweb.social slash at Jack F. Uh, I will, I guess

 

Okay.

 

we can chuck a link in the slow. It's not as easy as saying I'm Jack Franklin on Twitter as it, but, uh, I'm not really using Twitter

 

Yeah.

 

as much anymore. So, um, I'll paste a link in so we can put it in the show notes.

 

Perfect. Then we will do that. Alright, so let's move into the portion of the show where we talk about picks. These are, as long time listeners know, a lot of shows, a lot of kitchen gadgets, and a lot of just other stuff that we think you guys will like. So, Jack, would you like to start us off with a pick for today?

 

Sure.

 

Sure.

 

Oh no, wrong jack.

 

What?

 

Oh,

 

Sorry.

 

that's

 

Oh, wow.

 

great.

 

Here we go. That's, we were, we were waiting

 

Amazing.

 

for that, you know? Yes.

 

It's

 

No,

 

amazing

 

no, no,

 

it's

 

please.

 

taken this long to happen.

 

It

 

Please,

 

really

 

areas.

 

is. It really is.

 

go on. I'll let I won't be you know, you can't have the guests go first. So other Jack, please go for it.

 

No problem. My pick is a Discord service. Only Discord. I mean, there is a website, but there's just Discord really called Mid Journey. And what Mid Journey does is it you give it any prompt and it gives you an AI image. It gives you actually four of them. You can pick variations, you get new variations. It is hilarious and awesome and super powerful. And I think you get first 25 images for free and then you get after that, you have to subscribe, but it's great if you want to go and play around with image AI. I think it's just fascinating and amazing.

 

Sorry, I couldn't get off mute there. Very good, good pic. I know that you shared this either on Twitter or in another Discord message, but it is a very cool site. I looked at it and boy, the art that can be generated without people is

 

Hahaha.

 

amazing,

 

Yeah.

 

truly.

 

Yeah.

 

All right, TJ, what do you got for us?

 

So I'm gonna pick Bokksu, Bokksu snack box. This is something that Paige and I are both familiar with because it was our holiday gift from Blues. And it is a box that you get in the mail with snacks from Japan, basically. It's got, I don't know, what'd you say, like 10, 15 different things in a box.

 

Mm-hmm.

 

Some of them are snacky things, some are more deserty. There's some teas in there, but it's intended to be authentic snacks. But very random snacks is I think the bigger part of it because Japan is a weird place and they come up with some interesting stuff. So

 

Ha

 

you

 

ha ha.

 

could just think of it as just a box of some really random food. And if you're the sort of person that's into experimenting with that sort of stuff, it can be a lot of fun. So I enjoyed the one we got. So I actually ordered another one, which

 

Hehehe

 

I can see my wife rolling her eyes at me because it's...

 

Ha ha!

 

It's a it's it's less her thing, but I've had a lot of fun with it. Kids have had a lot of fun.

 

That was money TJ need to spend. Ho ho ho ho!

 

Yeah, exactly. So it's boxu

 

Nice.

 

Bay B. Earth B. OK, K.S. You boxu.

 

Oh, okay.

 

Nice. Yeah, I can second that. It was very fun. And I think maybe what part of what they do is they kind of pick a theme. So the theme box that we got was around a particular type of milk that's produced in Japan from, you know, very happy cows that are raised in great green fields and whatever. But it was really fun. It was fun to try all the new stuff. So good one. Jack, Other Jack, would you like to give us your pick?

 

Yeah, I'm going to be really nerdy and recommend a YouTube video on keyboards. Uh, so there's this YouTube I found called Ben, Ben Vallock, who doesn't have, he's only got 30 odd thousand subscribers. I'm really, I'm really into keyboards as in like typing on not musical. And, uh, he did this video on a keyboard where it's only got 34 keys. Now, if you think there are 26 letters, so that only leaves you eight more keys, if you look

 

Mm-hmm.

 

down at your keyboard, if you're using a normal keyboard, there are many more than 34 keys. Anyway, I have since

 

Yeah.

 

got my hands on one of these keyboards and have been trying it out and it's been a lot of fun. The theory is fewer keys means your hands and fingers move less far. There's less kind of awkward

 

Mm-hmm.

 

combos and it comes with software that you can program all sorts of fancy combinations on. I just think it's, I I'm always interested in improving like the ergonomics and that side of things that I've been really enjoying playing with

 

So

 

it.

 

it was like a cording keyboard? Is that the idea?

 

Yeah, you can do so uses software called QMK. And, but you can do things like when I tap this button, it's the letter J, but when I hold it, it's the command key, or you can have tap is J double tap is something else hold is something else. It's got multiple layers on it. So you know, on a regular keyboard, if you hit shift, you're effectively in a second layer where all the letters are uppercase, but you can do that.

 

Mm-hmm.

 

And then you can have any letter. So for example, all my punctuation, so like brackets, braces, they're not on. the key, I have to hit a second layer to go into that key. So for some people, this sounds horrendous. And

 

Yeah, I'm gonna put myself in that

 

I

 

category.

 

think other

 

That

 

Jack

 

Hehehehe...

 

sounds

 

might

 

horrendous

 

be in

 

to

 

that

 

me.

 

gap. And that's

 

J

 

fine. That's fine.

 

Hehehehe...

 

is

 

Hehehehe...

 

also command, I can't even.

 

Yeah,

 

But okay,

 

well, I don't actually

 

you

 

have

 

do

 

that.

 

you. Yeah.

 

That's not for me. But yeah, I've been really enjoying it and have enjoyed it. It's also a really tiny little keyboard. So I tend

 

Yes,

 

to travel

 

I can

 

and

 

imagine.

 

spend time in other offices. So it's nice to be able to have a little keyboard. I can just. pack away in a small little box and take with me. Yeah, that's my pick.

 

Nice. That sounds very interesting. I'm going to look forward to seeing that video.

 

Yeah, I can type it like one word per minute, but you know,

 

Woo,

 

it looks cool.

 

Hehehehe

 

yeah baby.

 

but it's only got 34 keys.

 

Yeah.

 

Cool. So my pick for today is going to be a series that I have recently been rewatching to get up to speed for the third season and it's called Mythic Quest and it's on Apple TV. Jack has given me the thumbs

 

Oh yeah,

 

up.

 

this is good stuff.

 

Yeah, so it's a really interesting look at, if you've watched Silicon Valley, it's a little bit like that, but think. game, video game development studio instead of just tech startup in general. Uh, and Ubisoft is the video game studio that is helping to produce this. So in, in each episode, there's cut scenes that they put together and there's probably all kinds of storylines that are actually informing how this is actually being made, but it's just bonkers. The characters are crazy, the creative director and the lead tech. person are always at odds with each other, executive producers in there trying to keep the money flowing and everybody on time and on budget and it's really funny. So if you have an Apple TV subscription or you like to see these kind of sitcoms and you like It's Always Sunny in Philadelphia because that's one of, I think that at least two of the writers are also writers for this show,

 

Mm.

 

then you should definitely give it a watch. It's really enjoyable. I think it's a lot of fun. And I wonder if having never worked in a video game studio, if this is really what it's like. And I have a feeling that it probably is.

 

It's HR violations Palooza in that place.

 

Peace.

 

Oh yeah,

 

Oh my god.

 

all the time.

 

Oh, geez.

 

I have not watched this,

 

Yeah.

 

but I love Silicon Valley. And so this will be, yeah, this will be being watched. But I think for Silicon Valley, didn't they basically talk to loads of prominent startups and got all their disaster stories and they formed a lot of the plots. So it'd be very, I wouldn't be surprised if very similar thing is happening here. Like you tell us anonymously horror stories

 

Hehehehehehe

 

and we'll like wind them in. So yeah, yeah. Cause

 

Yeah.

 

my wife saw some of Silicon Valley and she was like, this is far too far fetched. I was like, it's not,

 

Oh no,

 

it's

 

And

 

this...

 

really

 

you're

 

not.

 

like, no,

 

It's

 

it's

 

so

 

not.

 

If

 

not

 

Yeah,

 

anything,

 

far

 

yeah,

 

fetched.

 

no, yeah.

 

they're downplaying what you're

 

Yeah.

 

seeing.

 

right.

 

If anything,

 

Yeah.

 

yeah.

 

Yeah, so Mythic Quest Raven's Banquet is what you're looking for on Apple TV.

 

I will say season three has gotten a little bit more maudlin.

 

Mmm.

 

It's definitely not as comedy based as it was, but it's still good.

 

Nice. All right. Well, Jack Franklin, thank you so much for joining us today. It's been a

 

No

 

pleasure.

 

worries, thanks so much for having me. Good to chat to you all.

 

All right, well we will see you all next week on React Roundup. Thanks for listening.

 

See you then.