Jeremy Keith

Why do people decide to use frameworks?

Some sensible answers to this question here…

…of which, exactly zero mention end users.

AddyOsmani.com - Start Performance Budgeting

Great ideas from Addy on where to start with creating a performance budget that can act as a red line you don’t want to cross.

If it’s worth getting fast, it’s worth staying fast.

Uber, Lyft, Taxis, Design and the Age of Ambivalence + Subtraction.com

Design has disrupted taxis in a massive, almost unprecedented way. But good design doesn’t merely aim to disrupt—it should set out to actually build viable solutions. Designers shouldn’t look at a problem and say, “What we’re going to do is just fuck it up and see what happens.” That’s a dereliction of duty.

» Baikonur, Earth

A new impressionistic documentary about Space City.

Workplace topology | Clearleft

The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.

This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:

Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.

Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.

That last part dovetails nicely with Jerlyn’s equally great piece.

Sass Selectors: To Nest Or Not To Nest? | Brad Frost

The fascinating results of Brad’s survey.

Personally, I’m not a fan of nesting. I feel it obfuscates more than helps. And it makes searching for a specific selector tricky.

That said, Danielle feels quite strongly that nesting is the way to go, so on Clearleft projects, that’s how we write Sass + BEM.

Rethinking the date picker UI – UX Collective

I quite like this date-picking interface. It would be nice if browsers picked it up for input type="date".

Notes on prototyping – Ben Frain

Good tips on prototyping using the very materials that the final product will be built in—HTML, CSS, and JavaScript.

The only thing I would add is that, in my experience, it’s vital that the prototype does not morph into the final product …no matter how tempting it sometimes seems.

Prototypes are made to be discarded (having validated or invalidated an idea). Making a prototype and making something for production require very different mindsets: with prototyping it’s all about speed of creation; with production work, it’s all about quality of execution.

The Internet’s keepers? “Some call us hoarders—I like to say we’re archivists” | Ars Technica

A profile of Mark Graham and the team at the Internet Archive.

The Hurricane Web | Max Böck - Frontend Web Developer

When a storm comes, some of the big news sites like CNN and NPR strip down to a zippy performant text-only version that delivers the content without the bells and whistles.

I’d argue though that in some aspects, they are actually better than the original.

The numbers:

The “full” NPR site in comparison takes ~114 requests and weighs close to 3MB on average. Time to first paint is around 20 seconds on slow connections. It includes ads, analytics, tracking scripts and social media widgets.

Meanwhile, the actual news content is roughly the same.

I quite like the idea of storm-driven development.

…websites built for a storm do not rely on Javascript. The benefit simply does not outweigh the cost. They rely on resilient HTML, because that’s all that is really necessary here.

I, Maintainer

Maintaining an open source project is a rollercoaster ride with high peaks and very low troughs.

Release frequency is down. Questions increasingly go unanswered. Issues remain in a triage, unresolved state. Uncertainty and frustration brew within the community room.

Brian’s experience with Pattern Lab very much mirrors Mark’s experience with Fractal. The pressure. The stress. But there’s also the community.

A maintainer must keep the needs of their project, their community, and their own needs in constant harmony.

This is hard!