MoreRSS

site iconJim NielsenModify

Designer. Engineer. Writer.20+ years at the intersection of design & code on the web.
Please copy the RSS to your reader, or quickly subscribe to:

Inoreader Feedly Follow Feedbin Local Reader

Rss preview of Blog of Jim Nielsen

Do You Prefer Artificial?

2026-09-19 03:00:00

“Artificial” things can get a bad rap next to their counterparts, but they have their place.

For example, artificial light (i.e. not from the sun)? Super useful, especially at night.

And when it comes to skiing, I’ll take artificial snow if I have to. Beats no snow.

Artificial isn’t necessarily inferior in all cases, everywhere, all the time. But it is optimized for different values. For example:

  • Artificial grass (i.e. turf) is great for certain contexts, but I don’t want a golf course of artificial grass.
  • Artificial flowers are great for certain scenarios, but I don’t want them at my wedding.
  • Artificial flavoring is yummy (love me some peach rings), but I’d prefer a real peach pie over one with artificially flavored filling.

Artificial is an alternative. It’s understood as a trade-off, not a substitute.

You trade the real for the artificial when you’re concerned about attributes like cost, convenience, and availability.

Which brings me to “artificial” intelligence: surely a trade-off, not a substitute.

Ain’t nothing like the real thing.

These labs should consider ripping off (cause they’re good at that) Mastercard’s old tagline: “There’s some intelligence money can’t buy; for everything else, there’s Claude.”


Reply via: Email · Mastodon · Bluesky

Bottlenecks Get a Bad Rap

2026-09-16 03:00:00

Poor bottlenecks. Always seen as problematic, antithetical to efficiency.

But bottlenecks aren’t universally bad.

Think about it: a bottle’s neck is designed to constrain the amount of liquid that can flow out. A decrease in bandwidth is its entire purpose! Otherwise an overwhelming amount of liquid flows out and makes a big mess.

We humans have a particular anatomy. We can only consume so much liquid at a time. The neck of a bottle works with that fact.

We could make machines to produce so much wine that we’re drowning in it. But that wouldn’t change the fact that we’re only capable of consuming so much liquid at a time (not to mention digestion, etc.).

When it comes to liquid consumption, the bottle’s neck isn’t the bottleneck — our neck is!

So if you’re having a hard time drinking out of a firehouse, perhaps the question isn’t, “How do I modify my biology to accommodate the bandwidth of the firehose?” But rather, “Why am I trying to drink out of a firehose in the first place?”

Maybe a bottleneck isn’t your problem. In fact, it might just be the solution.


Reply via: Email · Mastodon · Bluesky

Preserving Netlify Analytics Data Beyond 30 Days

2026-09-14 03:00:00

I’ve got Netlify Analytics turned on for a few of my websites.

I use it send myself a little daily digest that alerts me when folks link to my writing, be it an individual sending me a few referrals, a newsletter sending me a few hundred, or Hacker News sending me thousands.

But sometimes I want to know more than, “What happened with traffic in the last 24 hours?”

Sometimes I want to know, “What happened with traffic in the last month?” I can log in to Netlify to answer that question.

Sometimes I want to know, “What happened with traffic in the last six months?” Netlify doesn’t have an answer for that because they only store the last thirty days of traffic data.

I’ve known about this limitation for years and always thought, “I really should just start saving that data for myself.”

But, you know, laziness. How bad do I really want it? The answer, it seems, was “I only want it if it’s _easy_”.

Enter Val Town.

Val Town makes this kind of task easy. Each “Val” is it’s own little bucket of scoped computing primitives for just such a task:

  • Code (run a script that fetches data)
  • Secrets (securely store my Netlify access token)
  • Storage (my own little SQLite database for persisting data over time)
  • Automation (run this task every 30 days)

All of this might seem like overkill for a single-script task like mine. But I like it. The scoped nature of each of these primitives makes composition easy without the kind of entanglement I’d have to fight to keep isolated if I were co-locating this task with other small tasks.

I don’t want to think about a shared schema for this task and whatever other tasks I might think of in six months. I don’t want to have to reason about evolving an architecture and maintaining a codebase of miscellaneous, unrelated tasks. Vals are perfect for this.

So the way I have this setup is: run the .ts file every 30 days which fetches the last 30 days worth of analytics data from Netlify and stores it in SQLite. (You can see my Val here.)

At that point, I have the data I need to curiously ask any question, e.g.

  • What are the top referring sites to my blog?
  • What post has received the most page views over time?
  • Where does most of my traffic come from?

The answers to these questions get more and more interesting over time, as the long tail of web dynamics play out: search engine traffic, serendipitous rediscovery of old posts in light of new trends, etc.

“But how do you actually view the data you’re storing to get answers to these kinds of questions?”

Great question. Val Town has a UI where I can see the raw data I’m storing (which I chose to store exactly as I got it from Netlify, rather than doing some pre-processing first):

Screenshot of the SQLite tab on a Val, showing a database table with a number of rows and columns of analytics data from Netlify.

But that’s not very useful. I need to parse that data and turn it into some kind of useful analysis.

And you know what tool is super useful for understanding data? A spreadsheet.

If I were using Excel, I’d probably have to figure out a way to dump the SQL, convert the JSON to some kind of CSV, then import it. And every time I wanted to see the “latest” data, I’d have to run that workflow.

Enter Quadratic.

Val Town has an API where I can fetch the latest data via code, and Quadratic is a spreadsheet that runs code. So seeing “the latest data” from my pipeline in Val Town is as easy as pressing a “re-run code” button in Quadratic.

Screnshot of a spreadsheet in Quadratic where Python code is open on the right and the result of that Python script is some tabluar data on the spreadsheet on the left.

Quadratic serves as a kind of “front-end” to my data pipeline. Easy to pull the raw data, transform it however I need, and create a “dashboard” I can revisit whenever I want to see the latest insights or ask new questions.

And, since I’m storing data for a couple different sites in Netlify, I have a single cell in my spreadsheet where I can swap out the domain — say from blog.jim-nielsen.com to iosicongallery.com — and the entire dataset and dashboard redraw.

Screenshot of a web-analytics-like dashboard in a spreadsheet in Quadratic, showing trend lines, top data sources, etc.

I know, I know. There are lots of products for stuff like this. And there’s probably a million other ways to do what I’m doing, all peculiar in their own way. But this one is mine.

And now I can sleep at night knowing that every 30 days my little Val Town robot is gonna go store the last 30 days of data that Netlify is throwing away.

One person’s garbage is another person’s treasure trove of data.


Reply via: Email · Mastodon · Bluesky

An Ode to Links

2026-09-11 03:00:00

A URL is a technical thing: a hostname, a path, a port, an origin, some query parameters, etc.

But a link is a cultural thing: an invitation, a citation, a gift, a shortcut, a connection.

All from a simple idea: here’s a thing that points to another thing, off you go!

We’ve built an entire culture around links. Just look at the language we use for them:

  • “Drop me a link.”
  • “Send me the link.”
  • “Got a link?”
  • “Link in bio.”
  • “Link in the description.”
  • “Here’s the link.”
  • “Don’t click that link.”
  • “Sorry, wrong link.”

Or even just, “Link?”

Our language spans the spectrum of meaning, from one end to the other:

  • We save links. We lose links.
  • We share links. We hide links.
  • We send links. We receive links.
  • We collect links. We discard links.
  • We open links. We close links.
  • We add links. We remove links.
  • We make links. We break links.
  • We shorten links. We expand links.
  • We follow links. We ignore links.
  • We click links. We don’t click links.
  • We link in. We link out.

We make links. Links make the web. The web makes Us.


Reply via: Email · Mastodon · Bluesky

Don’t Let Anyone Take Away Your Big Box of Cables

2026-09-10 03:00:00

Speaking of being on the internet and finding things that make you go, “Hey! It’s not just me!” I scrolled across this skeet from Tyler Gaw:

I just dug to the bottom of my Big Box of Cables to find two cables that I needed for something. They've been in the bottom for 10+ years. So, "when are you ever gonna use these?" was today. Don't ever let anyone take your Big Box of Cables away.

I laughed. I cried. I felt inspired.

So inspired, in fact, that I decided I was gonna do something about it.

Something that would make me forever remember the value of that advice.

  • I screenshotted that skeet.
  • I printed it (in black and white with the ole’ trusty Brother).
  • I cut it out.
  • I pulled out my big box of cables (the one my wife lovingly labeled “FAMILY TECHNO BOX”).
  • I cut some clear packing tape.
  • And I plastered that thing on the front on my box.

Photo of a cardobard box with cables hanging out of it. There is handwriting on the box with a sharpie that says “FAMILY TECHNO BOX”. There is also a print out of a skeet taped over the box that says (amongst other things): “Don’t ever let anyone take your Big Box of Cables away.”

Now every time I pull that box out to add YAC (yet another cable), instead of asking myself, “Why do I keep this box?” I’ll see that skeet and I’ll be reminded why I do what I do. I’ll feel a spark of joy, motivation, and purpose rekindled. (Not to mention the fact that it will serve as a warning to anyone in the family who thinks “I should just throw this away…”)

One day my kids will find that box in the attic amongst my other belongings. I hope they will pay heed to the timeless advice lovingly taped on the outside.


Reply via: Email · Mastodon · Bluesky

The Bulldozing of an Interface

2026-09-09 03:00:00

Marcin Wichary has a lovely article titled “Photoshop’s challenges with focus, pt. 2”. If you’re into the minutiae of interface design, this is a good ‘un. It perfectly illustrates how impossible it is to try and compare two interfaces side by side as static images.

What matters in an interface is how it works, i.e. how you interface with it.

And when you bulldoze an interface to build a new one, comparing the old vs. new side-by-side to make sure you “captured everything” is a lie. It’s never obvious what has been lost because the interactive pieces are missing from the static images — and those are what matter most because it’s how the feature works!

I’ve found this to be true a lot as of late. Lots of tiny details that were meticulously crafted over years with specific rationales tied to real-world use cases, all completely bulldozed in a giant refactor. (All made possible by the great omniscient power of AI.)

Few notice what’s gone because few can see what’s being lost in the first place.


Reply via: Email · Mastodon · Bluesky