CodePen Radio

Alex and Chris talk about how the 2.0 Editor supports packages from npm. The trick is both simple and complex. The idea is simple. We detect the packages you want to use, list them in an (editable) package.json file, then turn that into a <script type="importmap"> in your HTML files that import those packages from esm.sh. Complex in that, well, all those steps are fairly difficult to get right, handle all edge cases, and do extremely quickly. All of which the CodePen Compiler does. Time Jumps

Stephen & Chris look at the UI of the 2.0 Editor and show all the control you have over what you're looking at. Way more control than the Classic editor! We share some of the thinking behind it. Don't miss the Omnibar! Time Jumps Links Circle Round Story Pirates Podcast Who Moved My Cheese? The freeCodeCamp Podcast

With CodePen 2.0, we've got a new word we're using: Blocks. A way to think about Blocks is anything that processes code. They are added as steps to the CodePen Compiler as needed. For example, TypeScript is a block, because it processes files in the TypeScript syntax into JavaScript files. But something like Lodash is not a block. Lodash is a package from npm (which we also handle, but that's a topic for another podcast). Lodash doesn't process code, it's just a library that is linked up or bundled. Time Jumps

CodePen 2.0 was the most ambitious project that we've ever taken on in our lives. Why would we do such a thing? Chris and Alex explain the thinking behind it. We've been around a long time, know what our customers want, and are developers ourselves, so we know how this industry moves. We thought we could serve both in a powerful and flexible way, taking us into the future. Time Jumps

Chris Coyier and Stephen Shaw discuss the transition from CodeMirror 5 to CodeMirror 6, highlighting the significant improvements in accessibility, performance, and user experience. They delve into architectural changes, integration with modern JavaScript frameworks such as Next.js, and the new theming options available in the editor. Time Jumps

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. <iframe allow="...">). CodePen was calculating the appropriate values inside an iframe for a nested iframe. That must have been a security issue of sorts, as now those values need to be present on the outside iframe as well. We documented all this in a blog post so hopefully we could get some attention from Chrome on this, and for other browser makers as well since it affects all of us. And I posted it on the ol' social media: Huge thanks to Bramus Van Damme who saw this, triaged it at Chrome, and had a resolution within a day: I think the patch is a great change so hats off to everyone involved for getting it done so quickly. It's already in Canary and don't really know when it'll get the stable but that sure will be good. It follows how Safari is doing things where values that aren't understood are just ignored (which we think is fine and inline with how HTML normally works). Fortunately we were able to mitigate the problem a little until then. For most Embedded Pens, a <script> is loaded on the page embedding it, and we dynamically create the <iframe> for you. This is just nice as it makes making an accessible fallback easier and gives you access to API-ish features for the embeds. We were able to augment that script to do a little browser user-agent sniffing and apply the correct set of allow attributes on the iframe, as to avoid those JavaScript errors we were seeing. But there's the rub: we'd rather not do any user-agent sniffing at all. If we could just put all the possible allow attributes we want on there, and not be terribly concerned if any particular browser didn't support any particular value, that would be ideal. We just can't have the scary console errors, out of concern for our users who may not understand them. Where we're at in the saga now is that: We're waiting for the change to Chrome to get to stable. We're hoping Safari stays the way it is. OH HI FIREFOX. On that last point, if we put all the allow attributes we would want to on an <iframe> in Firefox, we also get console-bombed. This time not with red-errors but with yellow-warnings. So yes, hi Firefox, if you could also not display these warnings (unless a reporting URL is set up) that would be great. We'd be one less website out there relying on user-agent sniffing.

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. Time Jumps

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! Time Jumps

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. Time Jumps

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. Links Timeline – Chris Coyier 115: Adam Argyle on Cracking the 2025 Web Dev Interview | Front-End Fire Time Jumps

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!). Time Jumps

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. Jump Links

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. Time Jumps

Chris and Stephen talk about how we use a Cloudflare Worker & HTMLRewriter to inject a very special <script> tag into the previews of the Pens you work on. This script has a lot of important jobs so it's presence is crucial, and getting it in there reliably can is a bit of a challenge. Time Jumps

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 <script> necessary to make that work directly to fullres.com, but being an analytics tool, it's blocked by a ton of ad blocking browsers and browser extensions. We made the conscious choice to have that <script> point to a codepen.io URL instead (a proxy) so that we get (much) more accurate usage data on the app. Since there is nothing tracked that is an anonymity concern, and we do nothing with the data other than help inform ourselves on how to make a better app, we wear this gray hat. If you'd still like to block these requests, the path would be https://codepen.io/stats/fr/* Time Jumps

Robert and Chris jump on to talk about our little CDN project. Maybe that's not the right term, but we struggled with naming it. Truth be told, it's the /public/ folder in our monorepo, where the purpose is getting files to the world wide internet at URLs that anyone can access. Our favicon is a good example, where many of our sites need access to that, but we only want it once in our repo (but we have actually lots of use-cases.) There are several complications along the way. One is that we need to fingerprint these files so we can cache-bust them when needed. We also need to be able to import the URLs in other parts of the repo, so we need manifest files that contain those URLs in multiple formats. Plus many of the files have their own build process, they aren't just entirely static files. In the end, building our own thing was probably the right move. The files go to Cloudflare R2, which, I suppose, is the CDN part. Time Jumps

Marie and Chris jump on to discuss some of the trends of what people are building on CodePen here, approximately halfway through 2025. New CSS! Custom @functions (just landed) if() function clip-path & shape() corner-shape and the superellipse Scrolling stuff The attr() power up Hot Styles Liquid glass (Jhey's demo, Spark) Hard glitch (CRT-like effect with VFX-JS, Glitchy button hover effect with VFX-JS, ❍ Cinematic Glitch Slideshow) Holographics (CSS Holographic Masks) Grainy textures (Grainy distorted interactive 1 gradient blobs) Innovative blurs (wavy wobbly lava orb, Bubbles Background Animation) New color spaces (OKLCH Swatch Example, CSS Color Functions, CSS oklch Gradation) Hot Pens Petr Knoll’s Glass Button (From February, well ahead of liquid glass) Mike Bespalov’s Monospace ASCII art generator (known to be “vibe coded”) Adam Kuhn’s Severance Lumon Macrodata Refinement Steve Gardner’s “Who Needs Shaders” Time Jumps

Alex & Chris get into a fairly recent technological change at CodePen where we ditched our Elasticsearch implementation for just using our own Postgres database for search. Sometimes choices like this are more about team expertise, dev environment practicalities, and complexity tradeoffs. We found this change to be much better for us, which matters! For the most part search is better and faster. Postgres is not nearly as fancy and capable as Elasticsearch, but we werent taking advantage of what Elasticsearch had to offer anyway. For the power users out there: it's true that we've lost the ability to do in-code search for now. But it's temporary and will be coming back in time. Time Jumps

Stephen and Chris hop on to talk about how we're saving everyone from crashed browser tabs in CodePen's 2.0 editor. One simple: Executing JavaScript can cause a browser tab to entirely lock up, preventing you from doing anything, like potentially saving your work. It can even crash other same-domain tabs. But not on our watch! CodePen is now using a "heartbeat" technique to report up from the preview iframe to the parent page, and if we don't hear the heartbeat, we can rip out the iframe and stop the crash. But it was very tricky to get working and not too jumpy. Fortunately, we got it all working, because our previous technique of instrumenting your JavaScript wasn't going to scale well to the 2.0 editor. Time Jumps

Chris & Rachel hop on the show to talk about the expanded privacy (access) model in the 2.0 editor (in Private Beta as we speak). Private Pens have always been a big deal, but as private as they are, if someone has the URL, they have the URL, and it doesn't always feel very private. There are two new levels of privacy in the 2.0 editor: password protected and collaborators only. Passwords are an obvious choice we probably should have done long ago. With it, both the Pen in the editor itself, as well as the potentially deployed site are password protected. Our new permissions model is intertwined in this. Now you can invite others directly to be a fellow Editor or simply a Viewer to an otherwise private Pen. If you set the privacy level to "collaborators only", that's the most private a Pen can possibly be. Time Jumps