Link tags: main

82

sparkline

Guarding Against Disposable Design — Smashing Magazine

Always refreshing to see some long-term thinking applied to the web.

The Organic Web - Jim Nielsen’s Weblog

Growing—that’s a word I want to employ when talking about my personal sites online. Like a garden, I’m constantly puttering around in them. Sometimes I plow and sow a whole new feature for a site. Sometimes I just pick weeds.

I like this analogy. It reminds me of the the cooking analogy that others have made.

Most of my favorite websites out there are grown—homegrown in fact. They are corners of the web where some unique human has been nurturing, curating, and growing stuff for years. Their blog posts, their links, their thoughts, their aesthetic, their markup, their style, everything about their site—and themselves—shows growth and evolution and change through the years. It’s a beautiful thing, a kind of artifact that could never be replicated or manufactured on a deadline.

This part of the web, this organic part, stands in start contrast to the industrial web where websites are made and resources extracted.

Goodbye.Domains

A graveyard for good domains you let expire.

The Long Now Foundation: “Nadia Eghbal Talk”

This is a great talk by Nadia Eghbal on software, open source, maintenance, and of course, long-term thinking.

Boring by default

More on battling entropy:

Ever needed to change “just a small thing” on an old page you build years ago? I recently had the pleasure and the simple task of changing some colors in CSS lead to a whole day of me wrangling with old deprecated Grunt tasks and trying to get the build task running.

The solution:

That’s why starting with HTML, CSS and JavaScript without the need to ever compile anything on your local machine is a good idea. Changing some colors on such a page would indeed only take minutes and not a whole day.

I like this mindset:

Be boring by default and enhance on the way.

Cheating Entropy with Native Web Technologies - Jim Nielsen’s Weblog

This post really highlights one of the biggest issues with the convoluted build tools used for “modern” web development. If you return to a project after any length of time, this is what awaits:

I find entropy staring me back in the face: library updates, breaking API changes, refactored mental models, and possible downright obsolescence. An incredible amount of effort will be required to make a simple change, test it, and get it live.

Always bet on HTML:

Take a moment and think about this super power: if you write vanilla HTML, CSS, and JS, all you have to do is put that code in a web browser and it runs. Edit a file, refresh the page, you’ve got a feedback cycle. As soon as you introduce tooling, as soon as you introduce an abstraction not native to the browser, you may have to invent the universe for a feedback cycle.

Maintainability matters—if not for you, then for future you.

The more I author code as it will be run by the browser the easier it will be to maintain that code over time, despite its perceived inferior developer ergonomics (remember, developer experience encompasses both the present and the future, i.e. “how simple are the ergonomics to build this now and maintain it into the future?) I don’t mind typing some extra characters now if it means I don’t have to learn/relearn, setup, configure, integrate, update, maintain, and inevitably troubleshoot a build tool or framework later.

Built to Last

Don’t blame it on the COBOL:

It’s a common fiction that computing technologies tend to become obsolete in a matter of years or even months, because this sells more units of consumer electronics. But this has never been true when it comes to large-scale computing infrastructure. This misapprehension, and the language’s history of being disdained by an increasingly toxic programming culture, made COBOL an easy scapegoat. But the narrative that COBOL was to blame for recent failures undoes itself: scapegoating COBOL can’t get far when the code is in fact meant to be easy to read and maintain.

It strikes me that the resilience of programmes written in COBOL is like the opposite of today’s modern web stack, where the tangled weeds of nested dependencies ensures that projects get harder and harder to maintain over time.

In a field that has elevated boy geniuses and rockstar coders, obscure hacks and complex black-boxed algorithms, it’s perhaps no wonder that a committee-designed language meant to be easier to learn and use—and which was created by a team that included multiple women in positions of authority—would be held in low esteem. But modern computing has started to become undone, and to undo other parts of our societies, through the field’s high opinion of itself, and through the way that it concentrates power into the hands of programmers who mistake social, political, and economic problems for technical ones, often with disastrous results.

Pinboard is Eleven (Pinboard Blog)

I probably need to upgrade the Huffduffer server but Maciej nails why that’s an intimidating prospect:

Doing this on a live system is like performing kidney transplants on a playing mariachi band. The best case is that no one notices a change in the music; you chloroform the players one at a time and try to keep a steady hand while the band plays on. The worst case scenario is that the music stops and there is no way to unfix what you broke, just an angry mob. It is very scary.

Easily rename your Git default branch from master to main - Scott Hanselman

Nice and straightforward. Locally:

git branch -m master main git push -u origin main

Then on the server:

git branch -m master main git branch -u origin/main

On github.com, go into the repo’s settings and update the default branch.

Thanks for this, Scott!

P.S. Don’t read the comments.

Through a design system, darkly. — Ethan Marcotte

  1. Design systems haven’t “solved” inconsistency. Rather, they’ve shifted how and when it manifests.
  2. Many design systems have introduced another, deeper issue: a problem of visibility.

Ethan makes the case that it’s time we stopped taking a pattern-led approach to design systems and start taking a process-led approach. I agree. I think there’s often more emphasis on the “design” than the “system”.

Maintaining Performance - daverupert.com

In my experience, 99% of the time Web Performance boils down to two problems:

  1. “You wrote too much JavaScript.”
  2. “You have unoptimized images.”

But as Dave points out, the real issue is this:

I find that Web Performance isn’t particularly difficult once you understand the levers you can pull; reduce kilobytes, reduce requests, unblock rendering, defer scripts. But maintaining performance that’s a different story entirely…

The History of the URL

This is a wonderful deep dive into all the parts of a URL:

scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

There’s a lot of great DNS stuff about the host part:

Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularily given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.

On design systems and agency | Andrew Travers

Design systems can often ‘read’ as very top down, but need to be bottom up to reflect the needs of different users of different services in different contexts.

I’ve yet to be involved in a design system that hasn’t struggled to some extent for participation and contribution from the whole of its design community.

Design System Won’t Fix Your Problems | Viljami Salminen

This is something we’ve learned at Clearleft—you can’t create a design system for an organisation, hand it over to them, and expect it to be maintained.

You can’t just hire an agency to create a design system and expect that the system alone will solve something. It won’t do much before the people in the organization align on this idea as well, believe in it, invest in it, and create a culture of collaboration around it.

The people who will be living with the design system must be (co-)creators of it. That’s very much the area we work in now.

Frank Chimero · Who cares?

Aaaaaand the circle is now complete.

Frank—whose post on architects and gardeners inspired my post on design systems and automation—has now written his follow-on post about all of this. His position?

It is a crisis of care.

As with anything, it’s not about the technology itself:

A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement. Tools are always beholden to values. This is well-trodden territory.

Save .ORG | SaveDotOrg.org

I’ve signed this letter.

Standard Ebooks: Free and liberated ebooks, carefully produced for the true book lover.

Books in the public domain, lovingly designed and typeset, available in multiple formats for free. Great works of fiction from Austen, Conrad, Stevenson, Wells, Hardy, Doyle, and Dickens, along with classics of non-fiction like Darwin’s The Origin of Species and Shackleton’s South!

(Open) source of anxiety – Increment: Open Source

If we continue as we are, who will maintain the maintainers?

In the world of open source, we tend to give plaudits and respect to makers …but maintainers really need our support and understanding.

Users and new contributors often don’t see, much less think about, the nontechnical issues—like mental health, or work-life balance, or project governance—that maintainers face. And without adequate support, our digital infrastructure, as well as the people who make it run, suffer.

The Web Developer’s Guide to DNS | RJ Zaworski

At Codebar the other night, I was doing an intro chat with some beginners. At one point I touched on DNS. This explanation is great for detailing what’s going on under the hood.