CodePen Blog
428: Billing

Rachel and Chris on the show this week to discuss a series of big changes over the last, say, six months or so with our billing system. We’ve essentially re-written this thing several times, and obviously this is the best time. Having three plans, two payment providers, teams, and fifteen years of history is a lot to manage.

An important aspect of the journey was getting the billing information into a single table in our database, and relying more on dynamic calls out to the payment providers when needed rather than trying to keep too much data in sync.

Of course we wanted to clean up the codebase and get payment APIs ported over to our latest system, but the biggest need this was all satisfying was UX. We wanted a proper pricing page, better pages for people to manage their billing, and really easy upgrade modals inside our 2.0 editor.

The good news is, it all worked.

Time Jumps
* 00:00:20 Who’s excited to hear about billing?
* 00:01:24 Being able to upgrade in the new editor
* 00:02:28 Keeping data in sync with payment processors
* 00:08:50 How we plan to use new APIs in payments
* 00:11:47 Changes we’ve made to our payment modals
* 00:18:18 Keeping support for Paypal
* 00:22:17 CodePen’s pricing page
* 00:29:18 Keeping things simple for upgrade suggestions
* 00:39:20 What’s left for pricing and teams pages

Image generator studio

Output of this code

CodePen Blog
Chris’ Corner: The Edge, Man

Ryan Mulligan’s article Transition to the Other Wide with Container Query Units is some solid CSS catnip for me. Just this base thought is fun to think about: how do you move an element from flush-left to flush-right when the size of the container and element are both unknown (which is typical). https://blog.codepen.io/wp-content/uploads/2026/06/edge-to-edge-1024x292.png It’s like you want to have left: 0; as a starting state and right: 0; as an ending state, but as those a different properties, you cannot animate between them. You could have left: 0; as the starting state (or nothing, as that’s default) and left: 100%; as the ending state, but that’s not “flush right”, it’s “align the left edge of the element with the right edge of the container”, which isn’t quite right. A good fix for this is to make left: 100%; translate: -100% 0; the ending state! Kind of a classic. The -100% of the translate refers to the width of the element, so it sucks it back to the left “one element’s worth”, which ends up with flush-right alignment. Cool.

That solution is maybe a little funky though. Personally, I don’t love how there is a use of two “100%” values that just-so-happen to mean different things, and they are sitting right next to each other. Ryan presents a bit of a better solution in making the container a literal container with container-type: inline-size; so you can use container units inside, then moving the element with translate: calc(100cqi - 100%);. The different units there, and the single declaration, do feel better to me.

That’s kinda where Ryan stopped, but he did mention View Transitions at the top of the post, and that’s interesting to me because of how I opened the 2nd paragraph above. View Transitions don’t really care how you move something from one state to another, it just looks at the before and after states and tweens. So we really could do left: 0; and right: 0; as the two states and let the movement happen between them. But now we’re talking JavaScript of course, so we’ve got to use JavaScript events. Tradeoffs all around!

While I was playing with it I put all three ideas into a Pen, because, uhh, duh.

CodePen Embed Fallback

While that kinda stuff is a little cutting edge, it’s not nearly as much as the rest of these HOT LINKS I’ve saved for you.

There is a thing called Scroll-Triggered Animations now. Scroll-Driven Animations are already very cool, but those attach a timeline to scrolling position in one way or another. With the “Triggered” varietal, the animation can keep a duration-based timeline, but just be kicked off when a particularly element becomes visible (which itself has lots of control points). I like looking at really dumb easy implementations to get it, so I made my own “Wave at the Bottom” demo. Bramus’ Fly-In Text should make the point strongly as well.

CodePen Embed Fallback CSS Grid Lanes “are here” as they say. They work in Safari and are flagged in both Safari and Firefox. This is the thing that’s basically “masonry” layout. Nice simple (yet powerful) final API. And you can use it pretty easily now, because the fallback is still just a grid layout. I used it on a redesign of my personal site.
https://blog.codepen.io/wp-content/uploads/2026/06/Screenshot-2026-06-11-at-1.41.02-PM-1024x627.png Safari with Grid Lanes on the Left, Firefox without on the right. Whatever.
Perhaps you’ve heard of customizeable menus now. They are absolutely awesome. You have full CSS control. And for the most part, all of you fine sensible people will do sensible and tasteful things with it. But as it’s an interactive element, it absolutely begs to be messed with, so we’re seeing wild experiments like Chris Bolson doing a 3D globe selector fo[...]

r countries and Temani Afif turning a select into a shooting range.

But there is more newness afoot here. Brecht De Ruyte explains we’ve got now too. The UX of this used to uhhhh kinda suck turds, but Brecht’s demos are proving that they can be pretty great now.

CodePen Embed Fallback

Plus! Safari now supports customizable selects too, so hooray for that.

CSS having @function now is pretty cutting edge. It unlocks some new syntax and ideas, with has its ups and downs as far as DX. But people are really putting it to work in cool ways.

Sindre Sorhus has “a collection of useful CSS custom functions” (see them directly here). Mostly one liners! Makes me think how we might need to start tree shaking CSS.

CodePen Blog
429: Why CodePen Rebuilt Its Realtime Service

We’ve had realtime features on CodePen for ages. Back when it was pretty damn hard. Our Collab Mode is an obvious one, where users can code together. (This “just works” in the 2.0 editor, it’s not called anything special.) That and Professor Mode used to have realtime chat (until we pulled it because very few people used it). We went through iterations of this including our own implementations and using services like PubNub.

Code collaboration in realtime is particularly difficult. We used FirePad/FireBase for a while for this, and honestly that was a nice abstraction. Increasing the difficulty though, we need to layer on additional needs like syncing settings, presence, and just arbitrary message delivery (e.g. “a new build is ready!”). We used Ably for much of this for quite a while.

These days, our whole realtime system integrates with our caching layer, goes over the network using standard web sockets to our beefy Go servers, and is integrated with CRDTs/Y.js to keep everybody looking at the same thing. Plenty of open source software at work, but no more third-party services. This means lower operating costs and a simpler architecture. The cost is that problems are, well, our problems.

Time Jumps
* 00:00:07 Why did CodePen rebuild it’s realtime service?
* 00:03:11 People take realtime for granted in 2026
* 00:04:56 What tech did we use in the past to do realtime?
* 00:13:01 What did Ably used to provide?
* 00:16:36 What we ended up doing
* 00:26:27 What are the issues with doing realtime yourself?
* 00:32:59 What would we do differently?

Color Converter · HEX · RGB · HSL · CMYK

CodePen Blog
Chris’ Corner: Makin’ Stuff

The most fun websites to build are websites that interact with outside sources. A user is an outside source! I’m obviously a bit partial to a website that asks a user to build stuff. That’s fun. But any outside source can be fun. Accepting uploads and doing something weird or useful with the data. Or using a third-party API for interesting data.

There is something magically fun about a weather app, for instance. You’re designing the site, but it’s designed around data you don’t control. Your job is to present the weather in a pleasing and useful way. That’s difficult to do even when you’re essentially copying patterns that already exist for it, and extra difficult to do something novel that could attract actual customers.

I’ve seen a college program that has students literally build a weather app. That’s a great project if you ask me. It involves an outside source of data, so you learn how to do that and make it efficient and resilient and respect bandwidth and limits and all that. The students also learn that websites are both front-end and back-end, and neither can fully compensate for weaknesses in the other.

A weather site is a pretty saturated space. But I believe in you, you can do it! There are other opportunities out there, though. Perhaps after you’ve got your feet wet with interacting with outside sources, something else will click for you that feels more personal.

I was thinking about this after reading Terence Eden’s Are there any open APIs left?. It was very interesting to me as I was vaguely under the impression that most of the really interesting cool open APIs didn’t really exist anymore. And, to be clear, “API” meaning general data access from some third-party source. A classic is that GitHub offers REST and GraphQL APIs for your use. Could you build something interesting with access to GitHub data? Or, perhaps a better question is could you build something interesting with access to GitHub data and whatever other outside source you can think of. Terence’s blog post lists some APIs still going strong.

Speaking of outside sources, let me leave you with a somewhat random collection of links to tools and ideas that maybe-just-maybe could be alchemized into an interesting website.

* Defuddle — “Get the main content of any page as Markdown.”
* Curate your own newspaper with RSS by Molly White
* Introducing the <geolocationHTML element on the Chrome blog
* A Gentle Introduction to CRDTs — “CRDTs are needed in situations where you want multiple processes to modify the same state without coordinating their writes to that state.”

🤔

Have you tried using this code?