@chriscoyier
Chris is a web designer and developer. He created CSS-Tricks, a website all about building websites. Going strong for nearly 10 years, it’s a community with a blog, forum, almanac, and video screencast.
He is also the co-founder of CodePen, a playground for front-end web development. CodePen is a code editor for HTML, CSS, and JavaScript right in the browser. It’s also a community. People share what they make, write and comment about code, collect favorites, follow each other, and more. It’s a social network for front end designers and developers.
Chris is the co-host of a podcast called ShopTalk, a show about (you guessed it), building websites. Modelled after CarTalk, the show features call-in questions and industry guests. It’s going on 230 episodes!
Chris has also spoken at events all over the world and authored two books: Pratical SVG and Digging Into WordPress. The web is Chris’ life and career focus. The web is an incredible, inspiring, and empowering place and helping people know it better is good for everyone.
Nothing here yet.
No blogs yet.
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.
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: https://blog.codepen.io/documentation/faq/how-are-picked-pens-chosen/ Plus a couple of podcasts on the issue: https://blog.codepen.io/2015/09/29/059-picks/ https://blog.codepen.io/2016/06/07/093-picks2/
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: https://blog.codepen.io/documentation/api/prefill/ and RSS feeds are essentially an XML API: https://blog.codepen.io/documentation/api/rss-feeds/ 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.
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: https://blog.codepen.io/projects/using-babel-codepen-project/
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.
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.
Probably. 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.