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

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!

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.

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.

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.

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.