I’m a huge fan of snapshot testing, especially in JavaScript/TypeScript where types often lie, ane especially in backend. This article was a good reminder to me why I think it’s such a powerful tool in the arsenal.

At Pallet I found these to be an essential part of allowing our eslint rules to change. Essentially bulk suppressions allow you to keep a file tracking everywhere the code violates existing lint rules because the code predates the new lint rules. This is cleaner than using // eslint-diable everywhere and prevent normalizing disabling lint rules all the time, since all the disables are separate.

Yes, ideally, when you introduce a new rule (like no-floating-promises, a literal savior of sanity in the cruel world of JavaScript race conditions), it would be way better to go and fix all the instances. But that can change behaviors you don’t always expect. Or, more plainly, it’s just a lot of work to be able to take advantage of a new rule. So rather than try to go strive for perfection in your code base you can make things better, right now, and eventually get everything into compliance (if ever).

This capability has existed for a long time in the patch package eslint-bulk, but seeing it native in eslint means it’ll be less finicky to work with (the package above takes a bit of finesse to work correctly since it overrides eslint’s suppression system).

A2A is an open protocol that […] empowers developers to build agents capable of connecting with any other agent built using the protocol and offers users the flexibility to combine agents from various providers. Critically, businesses benefit from a standardized method for managing their agents across diverse platforms and cloud environments. We believe this universal interoperability is essential for fully realizing the potential of collaborative AI agents.

I think it’d be nice if this worked, but I’m certainly skeptical right now. One of the big things about how agents are supposed to do better than a standard worfklow is that they can work with highly ambiguous APIs (a.k.a., no API), so whether working against that talent will help improve accuracy or stall adoption remains to be seen.

Put another way, it would be nice if we had a standard way to communicate, but we all know these systems don’t talk to each other well for a reason. This may well be just another standard if there isn’t significant resources behind its adoption, and that part I certainly can’t tell.

You’ve probably seen this phenomenon before, where it’s easier to cope with a subpar situation rather than fix it or pick an alternative? Region-beta paradox. I wish there was a better name.

There’s a lot of places this shows up in a software team:

• Using shitty software because it’s not worth switching off (looking at you, Jira).
• A teammate who everyone knows is painful to work with, but not so bad that anyone thinks to tell them.
• Not complaining about mildly bad situations, allowing them to fester over time.

Some solutions:

• Complain loudly. (Biggest red flag to me in an organization is when people praise each other for not complaining.)
• Trying new things, for their own sake. Make people feel like change is normal rather than bullshit.
• Valuing improvement. (This is a hard one, and I still haven’t mastered it. But I know it’s possible.)

Brendan is an old friend from my time at Backbone, and someone I really admire for the journey he’s taken through both design and engineering. So when I saw he posted a personal manifesto, I had to read it. This is my favorite line in this piece:

The best feedback I get isn’t praise. It’s momentum. When someone says, “Oh, this makes sense,” and they keep going.

This has been bothering me because I use Bartender pretty heavily. If you’ve ever been bothered by prompts that “X app is accesisng your screen” in Sonoma, this should work.

A small side rant: Apple, you’re training users to ignore warnings when they’re so naggy like this. Maybe this will cover your ass, but it’s certainly not good security.

Instead of simply blocking bots, Cloudflare’s new system lures them into a “maze” of realistic-looking but irrelevant pages, wasting the crawler’s computing resources. The approach is a notable shift from the standard block-and-defend strategy used by most website protection services. Cloudflare says blocking bots sometimes backfires because it alerts the crawler’s operators that they’ve been detected.

One question that’s been crossing my mind lately–what will this do? A couple years ago, we worried about model collapse, but if anything, it’s gone the other way now. Claude is trained on its own data, modulated by researchers, for example.

The effect may be that it just separates out the shops that can afford advanced scrapers and inefficient compute versus the ones that can’t, and the veterans (who have already built up their datasets) versus the newcomers.

So continues the training data arms race, I suppose.

If you know trigger.dev, this is essentially Cloudflare’s version of Trigger, a technology I haven’t personally used but really want to. These two products are runtimes similar to Temporal, but with much simpler ergonomics.

I haven’t given much thought to the differences between these platforms, to be honest. However, one thing stands out: Trigger aims to run your existing Node.js codebase in its serverless runtime, while Cloudflare Workflows integrates with the Cloudflare V8 isolate system, which has some incompatibilities and does not support external API calls like napi. (Inversely, this can be a blessing because the Cloudflare Workers is sooo much simpler.)

Additionally, Cloudflare Workers provide about 60% of the value of something like Trigger because Workers’ pricing is based on CPU time rather than wall time. This means if you spend 2 ms making a call and wait a minute for it to return, you’re only billed for 2 ms of compute. The reliability and observability aspects are where workflows win out.

I’ve seen a lot of traction from this library lately, and compared to the juggernauts like zod, it leverages some of the newer technologies available to the ecosystem:

//----
// examples/checkString.ts
//----
import typia, { tags } from "typia";
export const checkString = typia.createIs<string>();

//----
// examples/checkUUID.js
//----
import typia from "typia";
export const checkString = (() => {
  return (input) => "string" === typeof input;
})();

Zod would instead be using runtime types to generate static types, but here typia is creating runtime types from static types, using a TypeScript transformer.

Super neat, and I certainly did not realize how ready the TypeScript plugin ecosystem was for prime time until seeing this.

I’m still looking for a practical Gleam-based web framework to play around with, and it feels like Wisp is the most interesting one so far (made by the Gleam creator).

Why Gleam, over Elixir? Mostly because I think types make life a lot easier than pattern-matching, but that’s more of a stubborn opinion. I have no doubt that Elixir’s pattern-matching is “good enough” in dynamic-land, but given that most of my brain has been rewritten in TypeScript over the last 6 years, the adjustment to a truly dynamic language sounds a lot more daunting than just picking a statically-typed or incrementally-typed language.

I’ll cut to the chase here:

To meet those goals, we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage. By porting the current codebase, we expect to be able to preview a native implementation of tsc capable of command-line typechecking by mid-2025, with a feature-complete solution for project builds and a language service by the end of the year.

Given the current meme of rewriting core JavaScript tools in Rust, Zig or Go, this comes both as no surprise and yet still very unexpected (TypeScript defines trends as much as it bucks them). Almost every single non-JS tool has not bothered to rewrite the typechecker because there’s just so much complex and semi-undocumented behavior that it’s not worth doing. But if the TypeScript team is doing it, it’s another matter altogether; they’re on the hook for this keeping compatibility with existing behavior.

🍿🍿🍿

I got to listen to a (fanstastic, by the way) talk outlining this platform a couple days ago at a meetup. What struck me about the way Snap described their models is the sheer size of their recommendation systems. Deepseek V3 was trained on about 60 TB of tokens, but Snap’s recommendation system eats about 20 times that.

Caveat, of course: a recommendation model is very sparse, meaning not all of the model needs to be activated at the same time, whereas most LLMs are still dense. Bigger model doesn’t necessarily mean a harder scaling problem, just a different one.

If you’re greenfielding a JavaScript application, I can’t recommend enough starting with Remeda. The main reason here is that unlike lodash, Remeda is composable and functional, but unlike something like Ramda, you aren’t forced to use data last all the time. In the same breath:

const items = [1, 2, 3];

const doubled = R.map(items, (x) => x * 2);
const doubleSquared = R.pipe(
  R.map((x) => x * 2),
  R.map((x) => x ** 2),
);

It makes functional programming practical in the semi-functional style that works really well in modern TypeScript.

Omnisearch is a search engine that “just works”. It always instantly shows you the most relevant results, thanks to its smart weighting algorithm.

I’ve been taking more notes lately on pen and paper, partially because I got a very nice Memosyne notepad and fountain pen from Japan, but also because it’s easier for me to not feel distracted when I’m not using a keyboard.

But I also want to be able to index and search my notes. But I also don’t want to move off Obsidian (all of the AI note taking apps have yet to sway me, despite the Tana invitation collecting dust in my inbox). So I’m trying to find stuff that OCRs properly, or can use an LVM to clean it up for me.

I’ll post back about this if it’s lifechanging, but probably not. Let’s be real, it’ll probably just sit in my configuraiton for a while and be banally useful.

Perfectly reasonable people thought that maybe we should put more of a wall between designers and the css source code. […] But instead a miracle happened. There was an inspired person who decided to do the opposite. They just yolo’d giving the designer the deploy keys. […] We spent our free time building everything we needed to in terms of monitoring, test suites, et cetera to make that safe for them to do. Everyone rejoiced and got shit done. Nothing bad happened.

When this talk was first shared with me, my mind was blown because everything I had ever heard about building an organization, was that we need people to respect their lanes and learn to communicate with each other. I don’t think that value is wrong (talking cross-functionally is important in almost any organization), but this talk blurred the lines for me between what is good communication, and what is building fiefdoms.

Make your discipline more accessible This should be part of your job!

I will say, the challenges here are really, really underemphasized. (Not to say it’s not worth it, of course, but that there’s more to it.) If I don’t have the right tooling needed, making a code change, ensuring it’s safe, and deploying it to production is barely safe for an engineer, now imagine someone without the skills to debug if the flow fails half the time.

Sometimes the walls come up because people want to perpetuate those little stupid fiefdoms, but sometimes it’s just because it’s the easiest thing to do, everything is on fire, and you don’t have the time.

(The perfect retort to that, which I believe, is if you set your team and processes up to be accessible from the start, it’s pretty cheap to maintain it, and people will even help you point out failures far sooner. Looked at this way, fiefdoms are organizational debt that can be paid down easily at the start, but not much later.)

Most of my professional experience has been in Node, but it’s clear to me that despite working fantastically in practice, there’s so many limits to the event loop that make it really hard to write performant code correctly. I’d love an environment that combines the expressiveness of TypeScript/JavaScript with the concurrency of something like BEAM, and I’d love it to be mainstream.