There was a day not long ago where a Google Chrome browser update left any page with a CodePen Embed on it throwing a whole big pile of red JavaScript errors in the console. Not ideal, obviously.

The change was related to how the browser handles allow attributes on iframes (i.e. ). CodePen was calculating the appropriate values inside an iframe for a <em>nested</em> iframe. That must have been a security issue of sorts, as now those values need to be present on the <em>outside</em> iframe as well.</p>

Shaw and Chris are on the show to talk about the thinking and challenges behind upgrading these rather important bits of technology in our stack. We definitely think of React version upgrades and Next.js version upgrades as different things. Sometimes they are prerequisites. The Next.js ones are a bit more important as 1) the docs for the most recent version tend to be the best and 2) it involves server side code which is important for security reasons. Never has any of it been trivially easy.

Robert and Chris hop on the show to talk about choices we've had to make around Babel.

Probably the best way to use Babel is to just use the @babel/preset-env plugin so you get modern JavaScript features processed down to a level of browser support you find comfortable. But Babel supports all sorts of plugins, and in our Classic Editor, all you do is select "Babel" from a dropdown menu and that's it. You don't see the config nor can you change it, and that config we use does not use preset env.

So we're in an interesting position with the 2.0 editor. We want to give new Pens, which do support editable configs, a good modern config, and we want all converted Classic Pens a config that doesn't break anything. There is some ultra-old cruft in that old config, and supporting all of it felt kinda silly. We could support a "legacy" Babel block that does support all of it, but so far, we've decided to just provide a config that handles the vast majority of old stuff, while using the same Babel block that everyone will get on day one.

We're still in the midst of working on our conversion code an verifying the output of loads of Classic Pens, so we'll see how it goes!

Rachel and Chris jump on the show to talk about a bit of client-side technology we use: Apollo. We use it because we have a GraphQL API and Apollo helps us write queries and mutations that go through that API. It slots in quite nicely with our React front-end, providing hooks we use to do the data work we need to do when we need to do it. Plus we get typed data all the way through.

Chris gets to learn that the Apollo Cache isn't some bonus feature that just helps makes things faster, but an inevitable and deeply integrated feature into how this whole thing works.

We're over 13 years old as a company now. We decide that we're not a startup anymore (we're a "small business" with big dreams) but we are still indie. We've seen trends come and go. We just do what we do, knowing the tradeoffs, and plan to keep getting better as long as we can.

Or just "Embeds" as we more frequently refer to them as. Stephen and Chris talk about the fairly meaty project which was re-writing our Embeds for a CodePen 2.0 world. No longer can we assume Pens are just one HTML, CSS, and JavaScript "file", so they needed a bit of a redesign, but doing as little as possible so that existing Embed Themes still work. This was plenty tricky as it was a re-write from Rails to Next.js, with everything needing to be Server-Side Rendered and as lightweight as possible (thank urql!).

Alex and Chris hop on the show to talk about a bit of technology that Alex calls "The 2nd best technological choice he's ever made." That technology is called Tree-sitter. It's a code parsing tool for building ASTs (Abstract Syntax Trees) out of code. GitHub uses it to power search and "go to" functionality. The creators now work on Zen, where a code parser is paramount. We use it to understand an entire Pen very quickly so we can understand how it all links together (among other things) and make a plan for how to process the Pen (a "build plan"). It's fast, accurate, forgiving, and extensible. Just a heck of a learning curve.

Chris & Marie jump on the podcast to talk about just how drastically customer support has changed over the last few years. We still exclusively do customer support over email. Incoming email from real customers who need a hand with something where they type out that email in plain languages themselves are few and far between. Instead we get an onslaught of noise from users that don't exist about Pens and situations that don't exist. The influence of agentic AI is massive here, some of it with nefarious intent and some not. All of it needs work to mitigate.

Chris and Stephen talk about how we use a Cloudflare Worker & HTMLRewriter to inject a very special

Chris and Stephen hop on the podcast to discuss the concept of a proxy. Possibly the most "gray hat" thing that CodePen does. We use a third-party analytics tool called Fullres. We could just put a link to the