A CodePen Interview with Chris Coyier

One of my favorite sites has recently become CodePen. CodePen is an incredible showcase of what developers can do with CSS, JavaScript, and HTML; thousands of developers have shown pride in their work with each pen. I wanted to interview Chris Coyier about CodePen: how it came about, what impresses him about the site, and where it will go in the future. Enjoy!

You've created a number of sites within the past few years: Digging Into WordPress, Script & Style, Are My Sites Up, and more. How did the idea of CodePen come about?

The original idea was to make CodePen in such a way that anyone could install it. I was planning to put it on CSS-Tricks to show off demos. The kind of demos that I've been building for years on CSS-Tricks are best viewed in a way where you can see the result AND the code at the same time. This type of view was pioneered by sites like JSFiddle. I wanted to have that on my own site so I could have complete control over it. And hopefully, make it better all around.

One unique aspect of CodePen, as compared to popular sites like JSFiddle, is that CodePen focuses a bit more on the result (its display and functionality) and not just the code. Was that a conscious decision at the outset or did CodePen simply evolve that way?

The thinking was: how do you find the coolest things people are building with this tool every day? Search Twitter? Analytics? Look through every one? There is no great way unless you build a great way. That became clear very early on - we want to showcase the best work being done. We do that by literally showing you the results in little miniature iframes. In that way it's like Dribbble. You can always come back and find impressive new work waiting for you on the homepage.

What client-side technical challenges were did you come across while developing CodePen?

Tons. The demos are all shown in iframes and those iframes are on a different domain to prevent cross site scripting problems. Anyone who has worked with iframes a lot knows how challenging that can be. Performance is always challenging. Especially in our unique situation where the simple act of typing is triggering loads of requests - keeping the live preview up to date. We're also prone to huge traffic spikes when demos that people build go viral. Luckily we have a smart team on the job that are great at server stuff as well as web development. I'd consider the entire UI quite challenging as well. There is a lot going on in a little space.

Demo previews on the homepage deactivate after a given duration of time. How was that accomplished?

It's just the demos that have animations that we stop. We found Javascript and CSS animations could really spike your CPU and slow down a person's whole computer, so we decided it would best to only run them for a few seconds. To stop the CSS animations we listen to animation events and cancel the next animation if the time's expired. For Javascript animations we wrapped the native functions setInterval and setTimeout with our own. Just like the CSS events, once the time's expired we ignore calls to setTimeout and setInterval. There is also a lot of code we just straight up strip because it would be obnoxious to leak through the iframe - like alerts and geolocation for example. We do this to keep any page on the site that displays a grid of Pens fast. As fast as we can, anyway. Nine iframes of anything on a page will never be blazingly fast.

What are your favorite pens to date?

We actually have a feature on CodePen to mark your favorites. You can "love" them (apply a little heart), but it goes a step beyond that into what we call "Grinch Stole Christmas" style hearting. You can grow the heart three times. It will still only apply a single heart to the pen - but it allows you to remember Pens in different ways. For instance, you can view Pens that I've given three hearts to ("alpha"). I use this for Pens that had some special meaning for me.

I'm also particularly fascinated by the work of Tim Holman, Hakim El Hattab, and Justin Windle. All three of them work at the same place in New York and all three do some really crazy progressive stuff with CSS and JavaScript.

What feature enhancements can users expect to see on CodePen in the future?

We have a list as long as I am tall of things we want to add and improve on CodePen. Our big push right now is to get out "PRO" features. This is what is going to make CodePen into a business which is a priority right now. There are a good 8-10 features that we hope make this upgrade pretty compelling. One of which is "Collab" mode. You can literally pair program with someone and both be writing code at the same time. Kinda like a Google Doc but for code. This is going to be a great way to think something out with another developer whether they are across the globe or even in the same room as you.

What's the technical process of live-updating the display pane upon changes to the HTML, CSS, and JavaScript?

First, we wait for kind of a "stop typing" event. Essentially no new keys have been pressed in a few seconds. Then we grab the values from each of the three areas: HTML, CSS, and JavaScript. If each of these are "raw" (no preprocessor being used), we can literally just concatenate them into a document and update the iframe with this new document. That all happens on the client (no round trip to our servers) so it's extra fast. If there are preprocessors selected, for example Sass, it has to send the CSS block to our server, we process it, and send back CSS. Then again the document is constructed and the iframe updated.

As you can imagine there are loads and loads of these preprocessor requests happening concurrently. We have servers dedicated to just to this task. Having separate servers just for this is also good for security. Preprocessing languages like HAML allow you to run Ruby code which is a pretty dangerous thing to allow people to do!

From a technical standpoint, what would surprise people about CodePen?

I've seen a couple articles in the last few months that are like "Build a site like CodePen in just a few lines of code!" They aren't bad articles, really, it's just funny. You can replicate the very basic technology of some textareas that compile into an iframe fairly easily. But that's a small part of the whole of something like CodePen. You have to think about speed, security, user interface, user experience, and advanced features. Not to mention more abstract stuff like marketing and community.

People might be surprised at the servers we're running on. We're on AWS and have our services spread out across a number of servers. Even individual services are load balanced across several. It's not cheap!

If you could go back and change one aspect or decision you made while creating CodePen, what would it be?

We're so early in development that I don't feel like we're "stuck" with anything that has really harmed us. I can give you a good example of something like that though. When we launched we had a concept of "versions" in CodePen. You'd have URL's like /xxxxxx/1/ and /xxxxxx/2/, etc. Every time you hit save, you'd get a new version. We thought this would be super great. You'd have access the progression of your work and be able to go back to any particular point.

Turns out, versions hurt more than they helped. Very few people saw any benefit to having old versions. We had tons of complex code both front end and back to deal with versions. It required us to save a lot more data. The worst thing was sharing. People would copy the URL out of the browser URL bar and share it. Then they would change something or fix a bug, but that URL they were sharing wouldn't have that fix.

We ripped out versions. Nobody even seemed to notice. Our code got simpler. Our data storage went down. Sharing got easier. I'd call that a win.

What browser issues did you encounter when creating CodePen?

Plenty. We were originally going to try and get IE 8+ going, but essentially just gave up. I can't even remember all the problems but it was a lot of UI stuff. Web developers are our target audience who don't do a heck of a lot of browsing in old browsers like that. We want you to be able to test things you build in CodePen in old browsers, but you can do that through our "Full" view easily without any CodePen UI. So, we just ditched IE 8 support and exactly zero people have cared.

One thing that is a continus PITA is keyboard shortcuts. We really need all our shortcuts tied to modifier keys since the core of the app is writing code (keys need to type, not do shortcuts). The basic pain is that every single modifier key has quirks and cross platform inconsistencies. We've settled on the Command (mac) Control (pc) thing as the lesser of evils - but it has it's share of problems. For instance Safari on Mac won't let go of control of Command-1/2/3 so our code expansion triggers don't work there.

Can you share any surprising statistics with regard to CodePen usage?

We share a number of statistics publicly. Growth has been great. I like that Number of Pens created is always much higher than users even when factoring in anonymous users. That means repeat usage is high and that's what we like to see. We have some fun features planned that will make statistics even more interesting. We have a lot of good data about how popular certain preprocessors are, for example. Look for stuff like that coming to the blog.

What's Chris Coyier's next project?

Nothing to share there, really. For the first time in a while I'm happy with how simple my life is professionally. I write at CSS-Tricks, I design for CodePen, and I podcast at ShopTalk. That's it!