The
All the can't-miss links.

Delivered straight to your email each week. Go Sign Up.

Add the feed to your favorite RSS reader and never miss a thing.

Sponsor a week and reach a large audience of designers and developers.

This week: iOS-inspired Notifications, an Elastic Accordion Gallery, and an accent-color Playground

A portfolio site without JavaScript

CSS artist Ben Evans shares a trading card game inspired portfolio site, fully illustrated and animated with CSS. Shuffle through Ben's cards for a look at his greatest hits!

Impossible Waterfall Illusion

Josetxu's pure CSS illustration, inspired by M. C. Escher's Waterfall, is a wonder to behold. Zoom around the scene to see every detail, including a mini-sculpture on the grounds.

CodePen Radio #391: Early TypeScript at CodePen

Chris, Robert, and Stephen are on to chat about our early days of using TypeScript as a team. "Where would we use TypeScript? What blockers were there? What does it actually help with? The implementation hasn’t been trivial, so has it been worth it? Will it be worth it?"

Imagine a world where your CSV importer says yes, instead of error: mismatch.

Flatfile is a platform to help you build and scale data exchange experiences in Typescript.

iOS Notifications

"A notifications component, inspired by iOS. Stackable, space-efficient notifications with a glossy background and slick animation. Highly customizable - control the max number of notifications, timeout, overlap, animation duration and more." From Yoav Kadosh.

100000 lines

Ivan Bogachev shares an animated photo gallery crafted with "two canvases, old trusty line-drawing algorithm and some junior-level image data calculations".

#CodePenChallenge: The 2000s

Our third week of the Design Decades challenge brought us to the y2k era: The 2000s. Check out the Pens from week three, including creations by Sicontis, minimoon, Jim Roberts, and Jordan Taylor.

Cloud Upload Bubble

"An upload sequence based on this Dribbble shot (by Cuberto) where bubbles rise up in a cloud that eventually fills the screen on finish." From Jon Kantner.

CSS accent-color playground

Want to dig in to what accent-color can do? Try this interactive demo from Jhey Tompkins with HSL color sliders.

#curiouslyminded with cacheflowe

On the latest Curiously Minded Twitch stream: Justin Gitlin, a.k.a. Cacheflowe, joined Ilithya and Eliza to chat and create this mind-bending shader with Three.js.

Flatfile is built for developers.

Yes, code. Code assembly for total ownership including Git-based/CI-based publishing for auto-everything. And with Typescript, you'll get fewer runtime errors and can reason about your data in a more sane way.

A data platform that powers every team

Whether you need an embedded data importer or the full suite of data onboarding solutions, Flatfile expands the capacity of every team in your company.

Advent Calendar

Mark Boots kicks off the holiday season with this 3D CSS Christmas tree advent calendar, complete with cheery presents for each day on the calendar.

Elastic Accordion GSAP

Fabio Ottaviani shares a "supah" slick, GSAP-powered photo accordion with a satisfying elastic bounce as the photos move and expand.

Chris' Corner

How do y'all write tests for your code? I know how I generally do it. First I write the code, then, maybe, I test it. Of course, it depends. I'm largely a front-end guy and traditionally I haven't found a ton of value in testing, say, CSS. But any non-directly-UI JavaScript code or back-end code I write generally deserves tests.

Another way to do it is to write the tests first, then write the code to pass the tests. That's called Test Driven Development or TDD. I've only done it a few times in my life, and generally at the prodding of another more skilled developer who saw value in it for the task we were undertaking together. At the time, I admitted it felt like a good approach, and I still feel that way, even if I don't reach for it as much as I should.

I can remember the general circumstances of the first time I was exposed to it. Another (more skilled) programmer and I needed some very expected output that we could easily picture in our minds, and had clear examples for. The input was easy to create and think about as well. When you go into a programming session like this, where you're about to create a function with pretty clear input and output expectations, TDD feels like a strong, obvious move.

I just don't always feel that strongly about when those tests should be written. If you're settling in to write the 23rd resolver for an existing API that plucks data from a database and returns it in a defined format... well, sure, it should have tests... but I don't think it matters all that much if you write them first or last. It doesn't feel like having a set-in-stone philosophy on this makes you any better or worse as a programmer.

This is a deep rabbit hole. TDD isn't a do it or don't thing, there are different ways of practicing it. The "weak" way is just writing tests first, while "strong" adheres to a very regimented approach involving writing minimal tests, minimal code, then slowly refactoring both while keeping the tests passing.

Perhaps my blasé attitude on all this makes me a worse programmer. By all accounts, I'm not terribly good at it, so the math works out. But I think circling back around to my front-end focus matters here quite a bit. TDD is heavily unit testing focused. Testing the input/output situations of the generally-smallest cogs in your software machine. That's a pretty specific type of testing that represents one dot on the spectrum of testing.

Hillel Wayne has some thoughts here:

Unit tests only cover units. There are no side effects, nondeterminism, or sequences of events. They only cover what the programmer thought to test, and only the specific inputs they chose. But many serious bugs are higher level, from correct components interacting in a bad way.

If anything, that's what keeps me bullish on end-to-end tests. If you write a test that literally visits your homepage in a browser, signs up for an account, and does the most important thing your app can do, that's testing about 20,000 things all at once. A lot of bang for the buck, and testing the thing that really matters most to everyone involved.