AMA with

CodePen Team

CodePen is a playground for the front end web

Hosted by

Alex Vazquez's photoTim Sabat's photoChris Coyier's photo

29th March 2017, 4:00 pm

This AMA is over!

Thank the host

What's the technology stack of CodePen?

I can speak to the back-end stack. We're mostly a rails app and we've picked off services as required. Here's a breakdown.


Our rails server is the largest part of the stack. Although we are using React for new front-end dev, the majority of our dev is done with server-rendered templates. Here are some stats:

| Name                 |  Lines |   LOC | Classes | Methods | M/C | LOC/M |
| Controllers          |  11934 |  9282 |     200 |    1376 |   6 |     4 |
| Helpers              |   1406 |  1138 |       0 |     197 |   0 |     3 |
| Models               |   5855 |  4515 |     119 |     696 |   5 |     4 |
| Mailers              |    701 |   581 |      16 |      61 |   3 |     7 |
| Javascripts          | 226460 |134085 |       0 |   13209 |   0 |     8 |
| Libraries            |     52 |    38 |       2 |       4 |   2 |     7 |
| Concern specs        |    246 |   176 |       2 |       1 |   0 |   174 |
| Controller specs     |   3806 |  3116 |       0 |      36 |   0 |    84 |
| Helper specs         |    160 |   108 |       1 |       0 |   0 |     0 |
| Lib specs            |   1657 |  1331 |       0 |      10 |   0 |   131 |
| Mailer specs         |    186 |   157 |       0 |       0 |   0 |     0 |
| Model specs          |   2694 |  2064 |       0 |      11 |   0 |   185 |
| Policy specs         |    244 |   198 |       0 |       1 |   0 |   196 |
| Serializer specs     |     99 |    94 |       0 |       1 |   0 |    92 |
| Service specs        |  12231 |  9460 |       8 |     172 |  21 |    53 |
| Total                | 267731 |166343 |     348 |   15775 |  45 |     8 |
  Code LOC: 149639     Test LOC: 16704     Code to Test Ratio: 1:0.1


We have a number of services that do various things. Here's a quick rundown:

  • spawner (rails): starts/stops docker containers for Projects.
  • spawner_router (nginx): knows which project container is running on which node.
  • async (sidekiq): queueing services for screenshots, emails, spam, indexing, lots of other stuff.
  • preview (nginx): nginx-only service for rending projects from editor and various views like debug, deployed.
  • preview_cname (nginx): nginx-only service for rending CNAME'd projects.
  • pen_preprocessor_ruby (padrino): coordinates Pen preprocessing. Delegates lambda calls for different preprocesor types.
  • pen_slim (sinatra): does preprocessing for Slim (is on its own because is insecure, so on lockdown)
  • pen_haml (sinatra): does preprocessing for HAML (is on its own because is insecure, so on lockdown)
  • pen_preprocessor_node (express): preprocessor rendering for node services too slow to run in Lambda.
  • screenshot (express): takes screenshots of Pens.
  • fluentd (fluentd): log capture from Projects, forwards to rails > front-end via long-polling


  • docker-swarm: all services (except for Project gulp containers) are deployed via Swarm.
  • swarm-classic: projects are launched into a classic swarm to avoid Swarm Mode (new-style swarm) limitations.
  • rds: RDS MYSQL and we're moving to Aruoura
  • redis: Elasticache via AWS
  • phusion passenger: webserver, cause this has lots of tuning options

other stuff

I'm sure I'm forgetting stuff here. AMA! :)

I remember Chris saying this in a podcast:

"All the work you do will be in the open. In the future you won’t have a CV — people will just Google you."

Do you see CodePen becoming that? a must have portfolio for Frontend engineers?

Doesn't that seem like already the case? I can't imagine hiring someone, especially to work on the web, where you don't look around pretty widely and closely about who they are on the web. If I can see how you write words, how you write code, how you communicate with people, the stuff you produce... that's powerful. If that's out there and available for me to see, that's leg up on someone else where I can see nothing.

One of the things that prevents CV's and resumes from going away is how big companies hire.

When CodePen hired programmers we looked at some of our favourite people on CodePen.

When I worked at a large company recruiters brought people into the company and passed them off to the technical people to interview.

Until we've overcome the problem with non technical people approving engineers we won't be able to fully replace the resume or CV.

  • What were some of the roadblocks while growing CodePen community and how did you overcome them?
  • What are some super important insights that the team has gained while running CodePen?
  • In your opinion what makes people come back to a community based website everyday? Any specific strategy that has worked well for CodePen?

I'll give my input only on what insights we've gleaned while running CodePen. Two things.

  1. Find the minimum amount of process that works to coordinate your team and formalize it. We were pretty ad hoc when we added people to the team and it felt inefficient. We've come up with processes we follow when doing our work and it's helped how we communicate. Everyone understands how we decide what to do and when we do it. Add the fewest number of steps you can. Team happiness is still the most important thing.
  2. There are great ideas and there are great ideas the team can accomplish. We hold back on adding features until we feel we can give them the love they deserve. For example we've wanted an API for a long time, so have our users but we've never had the time to support it. Five years in we can finally start discussing adding an API to CodePen.

One reason to come back often is that featured work (Pens, Posts, Collections, and Projects) are sprinkled out continuously pretty much all day every day.

Hi team,

Will CodePen release developer APIs for creating/editing/deleting pens from different applications?

We've just started discussing an API. We've held back on supporting an API for a long time because we wanted to continue building out CodePen itself.

Now that we've built a lot of our favorite features supporting an API is very high on the list. I'd love to have it for some open source ideas I have. Really hoping we can start work on it soon.

Yep. Seems likely. An API is another one of those "you have to support this forever" things, so it better make sense from a business perspective. I'm just as excited about having a full suite of read APIs as write ones.

I should say though that we already offer a number of things that are API-like. For example, you can already programmatically pre-fill a new Pen: and RSS feeds are essentially an XML API:

It's fairly common, when people ask us for API access, for us to ask what the use-case is, and to have it already be covered by something we have.

Alex (cofounder) had a super cool idea to create a sync tool that could watch directories and update pens/projects on a schedule. We've also thought about making a binary that'd submit changes as a build step for editors like Sublime that allow after-save actions. We'd also like to create an API one day. We're open to ideas/suggestions. Everything's on the table.

Is sass/scss dead?!


Not only do we use it to build CodePen, it's far and away the most popularly used CSS preprocessors on CodePen.

Personally, while I like the idea of preprocessing in general, and see value in all the choices, Sass still seems to me like the best choice.

What is next for CodePen?

Perhaps you've seen that CodePen Projects is out:

The release of that coincided with a major backend project, the rewrite our payment and signup system. Both of these were huge, long, demanding projects. For our own sake, we're going to be mixing it up with smaller, quicker-to-release stuff that we've been banking up and are sure people can use.

We're also trying to stay focused on "high impact" work. It's so easy to get sidetracked on a little project that ultimately has little impact on the business or our user base. We're right on the cusp of profitability and we want to get firmly into that territory by working on things that have the best chance of getting us there.

On a related note, we have a podcast were we talk about a lot of this behind-the-scenes stuff called CodePen Radio:

Are there any easter eggs, or hidden details built into CodePen that aren't normally visible but are able to be found if you know where to look?

There's probably more than I can even remember. The cheekiest ones are definitely math-related and built into the console.

There are a lot of code scratchpads online, but only one community like CodePen. It's amazing you have been able to build (and maintain) such a large and varied community. So I'm wondering in addition to meetups, podcast, and blog posts, what strategies have helped you build the community to what it is today?

Have you guys realised that CodePen has the potential to compete with GitHub and GitLab in future? Is this your vision?

Nah I don't think CodePen is aiming to become your version control management software. Not that there isn't some crossover, or that it's impossible.

We hope it's just more fun to keep your front end code on CodePen, because you get to see the output right next to the code. That's a fundamental CodePen thing.

It's more likely that there is better integration between CodePen and version control and project management software like GitHub and GitLab. It's your code, after all. We'd like to make it as painless as possible to move that code around wherever you'd like.

I LOVE CodePen, awesome Job!!

My question is: How you guys keep the CodePen CSS organized?

I wrote about that once:

It hasn't changed too much. SCSS. Autoprefixer. Rails Asset Pipeline.

One thing that's changed since I wrote that is that more people are writing CSS around CodePen. I think the system has scaled fairly well. We try to name things intelligently, but don't stick to a particular strict naming convention. We try and not nest too much. We try to use handy Sass abstractions when they make the code easier instead of harder.

Our brand new Project Editor is in React and it even has (gasp) a sprinkling of inline styles.

I don't forsee any dramatic new changes in how we do CSS coming soon.

One thing I do see changing is possibly changing how we compile in development. I could see us switching to an all-Webpack thing and changing deployment commensurately. We used to have a Guard-based file watcher thingy so we could get live reload going on development, but that's kinda deteriorated and I, for one, really want my hot reloading back ;)

I know you went through your first round of hiring a year or two ago. Would you like to keep hiring in the future? Is there an ideal size you'd like CodePen to be (in terms of employee count)? I'm curious if you want to keep it small, or if you'd be open to mega-corp world dominance (in the social-platform-and-playground-for-front-end-web-tech space).

I'd love to grow! Doubling sure would be nice. Not just for the sake of growth, but because we have lots of ideas that patiently waiting around for someone to work on them. Ideas don't do much good sitting as a Trello card. I'd like to get to our ideas sooner than later so people can use them and we can figure out if they are worth pursuing more or not.

Who are your top 5 favorite CodePen users? 😃

These are some of my favorites. Our:

  • 1st
  • 100th
  • 1,000th
  • 100,000th
  • 1,000,000th

But for reals, any user who is encouraging to other user is my absolute favorite. I also like stumbling upon seemingly unknown users who have been busily experimenting with things and building along a theme. Always a pleasure to shine a light on those folks.

What's the growth rate of CodePen pro user base every year?

Geez betty, this our first date. I think we should get to know one another first... :)

How about new user counts? You can't sell all your drama in your first book. You have to leave something for the second.



Do you see CodePen Projects becoming a "complete" hosting solution for production level front-end projects?

If yes, a CLI to sync your local projects would be super 💯. Thoughts?

We sure hope so. We're just getting started with CodePen Projects. What you see today is the foundation of Projects. We may not create an official CodePen CLI but if we created an API making an open source CLI would be very simple.

Will CodePen be more than just front end playground in future? If yes, how soon? If no, why not?

One should be able to create Java, Python, RoR, etc pens/projects on CodePen.

We've always been focused on the front end of the web because it's what we know and love. Focusing on just front end languages allows our small team to create a quality product. There is still a lot left to accomplish to support frontend technology on the web.

Backend languages bring unique security problems we'd have to tackle to properly support them. We just released CodePen projects that use Docker containers to run code securely. We could use this tech to support backend languages in the future.

We can't say no forever to backend languages but it'll be a while before we add them to CodePen.

I think it would be super cool, but it would be a massive project with huge hurdles and unknown challenges. Like Alex said, it's certainly not right around the corner for us.

To me it feels like a big risky gamble. The kind of thing you take a huge pile of funding to do. You hope you can pull it off in a way that catches on, and if not, oh well, you just lost some rich people's money. I like the idea of moving a little slower and releasing things we know we can do well and that people want and making a healthy (if smaller) business out of it.

Whose idea it was to create CodePen? And how did you get this idea?

CodePen was supposed to be a weekend project.

Chris always wanted something like Jsfiddle/JsBin but with a simple way to see what everyone else was doing. He was making lots of examples on his site CSS-Tricks and he wanted something better.

He asked Tim and I to help him work on it. We did and we never stopped working on it because it kept getting more interesting.

Five years in and our weekend project isn't done. Quite a bit of scope creep if you ask me.

Just like that. I wanted a version of an online code editor that I had more control over at first. Then short after, it was clear adding social features and community stuff was going to be a lot of fun and a good direction for us to go.

How close are CodePen and CSS-tricks? are these two separate projects or does the team get to work together?

We're going steady. Sometimes we hold hands.

They are totally separate businesses. It's just me that works on both. I take every opportunity to cross-promote! CodePen was created to make CSS-Tricks better, originally.

And, of course, there are friendships across all the related businesses.

How do featured pens work?

Although we take it seriously, there's no secret sauce here. We pick pens/projects/posts/collections as they come in, based on what's looking good that day. Sometimes we'll go with a theme (like on international panda day - thanks Marie!) like so:


We have a few trusted non-employees who have picking capabilities turned on. Picks are added to a queue and are rolled out every 20 minutes. I can be bribed to pick you pen with thai food gift certificates.

Technologically, there is a little button we press when looking at any given Pen and it goes into a queue that puts new stuff out every few minutes. That way there is a steady stream and everybody gets an equal amount of time on the homepage if they are picked.

We have docs on how things get picked as well:

Plus a couple of podcasts on the issue:

There are a million different frameworks, preprocessors etc etc out there. CodePen makes a (small but growing) subset of these available to users either by default or as options. How do you decide which tools make the cut?

There isn't an algorithm that decides what preprocessors make it into CodePen (I wish there was!). It's based on popularity and how many requests we get for the tech.

If we get enough requests for a preprocessor over Twitter/Facebook and email we'll add it to our list. Lots of times the team itself wants a preprocessor to be added. Every vote counts so we'd love to hear from you if you see something you'd like us to add.

One thing we always consider is the fact that we'll have to support the thing forever. So we have to make the call on if the thing seems like something worth supporting forever.

We should be clear though: there are LOTS of things you can use on CodePen that don't require us to specifically allow it. Anything that is front-end only will work fine. You can link up any JavaScript file you want. You can link up any CSS file you want. You don't need special permission for that, and that covers a huge amount of possibilities, and more all the time, as browsers grow more and more powerful.

This can be tough to communicate. One UI struggle we're facing right now is our little "Quick Add" dropdown menu. It's got popular JavaScript libraries in it, and was originally an attempt to make adding them to Pens quicker. But it works against us. Too many people think those are the ONLY libraries we support. Actually, you can just start typing into one of those External Assets inputs and it will autofill from 1000's of libraries for you.

Any memorable or inspiring moment that you can share with us when you were building CodePen in the initial phrase.

Thanks for AMA.

Haha, I remember sitting in a meeting with the CEO of SurveyMonkey, where we worked while starting CodePen. He's showing us graphs of SurveyMonkey making millions and I'm sharing a graph of TWO PRO SIGNUPS in a single day with Alex.

Who had the idea was it to make IDE like? Give him a raise. I love it.!

Done. 💰

How I should start a successful frontend project ?

There are some amazing examples being created on CodePen as projects. Look at the examples here You'll find lots of inspiration.

I would take these steps:

  1. Come up with an idea you want to see as a website. Anything that you'll be happy working on.
  2. Write out the steps it'll take you to build the site with as much detail as possible.
  3. Work on every step until you're satisfied it's complete.
  4. Enjoy your success!

Any planned support for Elm (and/or other languages that render to JS)?

How is CodePen different from jsfiddle?

Can you add a new editor layout in which all panels are in columns, like

We haven't really considered that. Have you seen all the other layouts we offer for a Pen? Check out this screenshot layouts.

This is a good example of a feature we could easily get sidetracked with. I'm not necessarily opposed to it, but as far as I know, this is the only time it's ever been asked for. As a tiny team we gotta pick what we work on carefully.

I think if we did something like this, it would be tied into a mini-sprint where we're focused on changing some editor UI stuff, and adding this isn't a weird detour. So: maybe!

Will there be any visual design improvements coming in the near future? Maybe this year?


Although "improvements" is subjective to any particular user. I'm definitely a fan of changes that are objectively better in some form. Better business. Users measurably completing goals. Easier code maintenance. Better performance. I'm happy to endure Twitter whining for objective wins.

I only whine on Twitter so that is perfect.

you will integrate Elm in the future?

If anything it would happen in the Project Editor. From what little I know, it requires .elm files, which doesn't really make sense in the Pen Editor. What would be awesome to see is a GitHub repo of a project that you'd like to be able to work with on CodePen.

What are the weapons of choice for codepen team? 🤓 What hardware does the team use?

We're all on macs. Except Alex. He's on an ubuntu machine. So his bluetooth does not work.

How long did it take for CodePen to come up with the first revenue channel?

We launched CodePen in June 2012, and PRO plans in December 2012, so about 6 months.

Today, our revenue channels are mostly PRO plans, but sprinkled with our job board, advertising and sponsorship, and merch sales.

What UI kits do you or do you often see people use in codepen for testing or prototyping? I am a web developer and recently interested in UI/UX but I always get stuck in design stuff! Thanks

Now that ESModules are actually being implemented in browsers, are their any planned features for CodePen that would make writing/consuming modules easier in Pens?

We don't have any planned features at the moment. But officially supported JavaScript is very high on our list. We'd love to hear what you have in mind.

If they are being implemented in browser, that's great for usage on CodePen, because it means we (and you) don't have to do any special processing to make them work.

As it stands, as far as I know, people are largely using Webpack for compiling that import syntax and we do support Babel/Webpack processing:

Any suggestion to build a startup in early stage ?

Find people you want to work with. If the thing is successful, you're in it for the long-haul. Better enjoy their company, otherwise it will be a long series of awkward silences.

In Angularjs How to over the issue of Picking the CDN library files... If I get it wrong it shows the injector module Error....

Is it possible to get a remote job as a junior front-end developer without any formal education or previous exprience if I have decent working portfolio(Pet Projects)?

Great team! nice job!! all the best

Can the codepen project (your new cool feature) compete after the beta release?

Hi.. I'm Ravikumar I'm a Front-end Developer but now I like learn Back end ..But I feel really difficult to learn .. How I can overcome thanks

Build something small with a backend language. When you succeed with that move onto a bigger challenge. Repeat until you're a full back end developer. If you code a frontend project you have the skills for many backend languages. I recommend Ruby. It's a sweet language.

I'd guess I'm semi-qualified to answer this. I've done back-end development almost exclusively throughout my career. I can change the background of your web page via css, which sums up my front-end experience. :)

I think this skill is just like any other: through constant practice you can become proficient. I'd say that if you were able to navigate the rigours of front-end-dev, you'll be fine working on back-end projects.

Pick a language, read a fundamental book, then start working on a real-world problem. Don't just do the Hello World examples. Create a back-end API for your todo front-end. Create a blogging platform from scratch. Then move on from there. What you'll find is that if you're solving a business problem you care about, you'll be better at solving it. Find a person you can work with who'll push you. Do a little project together.

Also, don't get too hung up on deployment or anything deeper than the web app itself. Use Heroku or Elastic Beanstalk to get your code running. I have friends who run very successful businesses with very little knowledge of how their stuff is deployed.

Just keep practicing.