dfabulich

I didn't say "easy" either, I said "straightforward hard work."

What you're doing is hard work, but it's way more straightforward than building out CSS Tricks.

You're a successful marathon runner. CSS Tricks will have to run a marathon with both legs tied together.

What makes your subject matter (LLMs) work is that it's a very fast moving topic, much faster moving than CSS, so people come to you for news.

Plus, it's difficult to test new models effectively, so people are looking for trusted names to do meta analysis, fast. Is the new OpenAI model better than Claude? Better how? Quality of output? Evaluated how? Even comparing prices can be difficult, as different models (at different settings) can generate different numbers of tokens (and different numbers of cached tokens) for the same tasks.

None of that applies to CSS Tricks.

CSS fundamentally can't move that fast, as long as changes in CSS require Apple, Google, and Mozilla to all agree on standards. Hardly anybody needs to know about the latest CSS news. Mostly you only need to know about Baseline Widely Available CSS features, which are at least 30 months old by definition. And when you do learn about new CSS features, it's usually pretty obvious (either to you or to an LLM) whether those new CSS features apply to something you're working on.

It's going to be very, very hard to keep CSS Tricks alive, even with a lot of hard work.

You're saying that like it's straightforward hard work. But that strategy has been on the decline for years, with no sign of reversing. High-value technical audiences aren't Googling for educational articles, videos, and courses. They're just asking LLMs, and getting answers. Sometimes the LLMs are searching the web, but LLMs approximately never click on the ads.

Agreed! And you aren't even restricted to currentScript; you can run arbitrary JS in an XML document, reformatting it however you like.

You can also style XML documents with CSS, like this:

    <link rel="stylesheet"
       href="style.css"
       xmlns="http://www.w3.org/1999/xhtml" />

Mozilla has announced that they intend to unship XSLT. https://groups.google.com/a/mozilla.org/g/dev-platform/c/ZRy...

Style them with CSS. https://danfabulich.medium.com/beautify-your-rss-atom-feeds-...

I'm looking as closely as I'm able, and I don't see what you mean. (I'm not a car guy, or a photo guy.) What do you mean by highlights? What am I looking for? Reflections?

Great news! If you use a cloud-sync password manager, passkeys are way more convenient than TOTP.

"Weird, my password manager isn't submitting my password properly. Well, that happens sometimes. I'll just copy and paste it" [or manually select a password to autofill]

The defining feature of passkeys is that they're stored in your password manager, and you can't read them, so you can't be tricked into typing them into the wrong web site.

Most password managers don't even allow you to export/backup the passkeys yourself. (Bitwarden is an exception.)

Instead, password managers support a finicky app-to-app transfer protocol called "Credential Exchange Protocol" (CXP), where you install two password managers at once, and they convey your passwords + passkeys, without ever generating a file that you can read. (And Microsoft's password manager doesn't even support CXP yet. As of today, you can only do it on Android and iOS.)

Many people read that and say, "see, that's why I'm never going to use passkeys! I'm safer managing my own backups, and I'm too smart to be tricked into copying and pasting my password to the wrong site." But they're wrong. You are not too smart to be tricked. Nobody is.

If you use the same cloud-sync password manager everywhere, passkeys just work. If you don't, you'll have to use Credential Exchange Protocol to transfer them, which is a hassle.

It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.

Passkeys are stored in your password manager, too. You'll only lose access to your passkeys if Google is your password manager and you get locked out of your Google account. So, if you don't trust Google, use another password manager. (May I recommend Bitwarden?)

The advantage of passkeys is that no one can trick you into giving your passkeys to the wrong person. Every time this comes up, people say "I don't need that! I've got a password manager. I'm too smart to get tricked." But they are wrong.

Yes. https://imgur.com/a/lRSM128

This is a category error.

Meaning > Motivation > Mechanics, but Measurement is how you know that Meaning > Motivation > Mechanics, and, more importantly, Measurement is how you prove to anyone else that Meaning > Motivation > Mechanics (or even that you've built any motivation in your students at all).

Measurement is how you prove that your approach (as opposed to anyone else's) is worth people investing their time and money with you.

Trust > Meaning > Motivation > Mechanics. How do you earn trust from a stranger? Measurement.

"Apparently"? Is this something that can be tested with VMs?

Does the macoOS login keychain get backed up by Time Machine backups in a way that could restore the keychain if the original machine's Secure Enclave is lost or destroyed?

Did you switch to SwiftUI or UIKit?

Small self-driving busses would do exactly what you want. The cost of increasing bus service is overwhelmingly the cost of bus drivers. If the busses could drive themselves, cities could afford to deploy a lot more busses, especially smaller busses, running much more often.

As for light rail, in the US, light rail projects can typically cost hundreds of millions of dollars per mile. The NYC 2nd Avenue subway expansion cost billions of dollars per mile.

And, if you want people to stop wasting city space on parking, self-driving taxis are exactly the right solution.

1. Dating apps/sites are a rich-get-richer market. Most people go where everyone else goes, because everyone else is there.

2. The more work you ask your users to do up front, (e.g. answering a bunch of survey questions, taking high quality photos, paying up front) the fewer highly desirable people you'll have, because they can easily find people wherever they go without doing all that work.

3. Swiping is more fun (more addictive) than answering survey questions. OKCupid switched to swiping when A/B testing showed that swiping retained people better than survey questions.

Bitwarden lets you extract and import passkeys. Apple, Google, Microsoft, and 1Password don't support that directly, but they do support a finicky app-to-app transfer system, where you install two password-manager apps on the same device, and you directly export your passkeys from one app to another. It's called the "Credential Exchange Protocol" (CXP).

Bitwarden's app can receive CXP passkeys, so you can install a passkey in Apple's password manager, CXP it to Bitwarden, and then export it to a file that you control.

Putting the file under your control does make it possible for someone to trick you into sending you that file, undermining some of the phishing protections of passkeys. It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.

Passkeys aren't tied to physical hardware. They're tied to your password manager. Passkeys are just passwords that require a password manager.

On Windows, macOS, iOS, and Android, there's a cloud-based password manager built into the operating system, so you can use your passkey anywhere you use that password manager.

Microsoft, Apple, Google, 1Password, and Bitwarden all have password-manager apps for Windows, macOS, iOS, and Android.

Pick a password manager and use the same one everywhere, and your passkeys will be available wherever you go.

You say "they're packing lots of signals into fewer words," and sometimes they do, but often they do the opposite of that.

I think the deeper problem is that the models (not just Claude) have a very poor understanding of what their readers already do/don't know.

They belabor obvious points and underexplain jargon, because they don't know what's obvious to you.

The best writing is surprising but inevitable in hindsight. The models don't know what's surprising or what's inevitable in hindsight, making it very difficult to write well.

It's just to reduce the maintenance burden of backwards compatibility.

+1. Most games, once shipped, completely disband their development team.

If you require game developers to even so much as recompile their game, they simply cannot do it. If you want the game to keep working, you have to guarantee ABI compatibility in perpetuity.

Now seems a good time to mention that you can beautify your XML RSS/Atom feeds without XSLT using CSS and JS.

You can add a stylesheet to an Atom feed by adding a <link> tag with an xmlns attribute, like this:

    <?xml version="1.0" encoding="utf-8"?>
    <feed xmlns="http://www.w3.org/2005/Atom">
        <link rel="stylesheet" href="style.css" xmlns="http://www.w3.org/1999/xhtml" />
        <!-- ... the rest of the feed goes here ... -->

Or add styles directly with a <style> tag:

    <?xml version="1.0" encoding="utf-8"?>
    <feed xmlns="http://www.w3.org/2005/Atom">
        <style xmlns="http://www.w3.org/1999/xhtml"><![CDATA[
            * { color: red; }
        ]]></style>
        <!-- ... the rest of the feed goes here ... -->

You can even run JavaScript when users browse to your feed like this:

    <?xml version="1.0" encoding="utf-8"?>
    <feed xmlns="http://www.w3.org/2005/Atom">
        <script src="script.js" xmlns="http://www.w3.org/1999/xhtml" />
        <!-- ... the rest of the feed goes here ... -->

You can use JS to transform your XML, just like you can (could) with XSLT.

We get to define "AI" however we like, but a definition of AI that includes a SQL planner is so broad that it includes literally all complex software.

When I wrote that a broad definition of AI "obscures more than it reveals," I meant that lumping LLMs in with SQL planners and deterministic chess bots ignores (obscures) all of the details of their implementation.

But those implementation details matter. They have big implications on the uses, limitations, and risks of the software.

As I write this, one of the top stories on HN is a story about an OpenAI model accidentally hacking itself out of Hugging Face's sandbox. SQL planners don't do that. Chess bots don't do that.

That's not to say that saying "all complex software is kinda the same, and we can call all of it AI" doesn't reveal anything. There are some similarities that all complex software has, especially as we look back on the history of complex software and the impact it has had (or not had) on labor productivity.

But, IMO, what you discover by ignoring the details is less important than what you discover by delving in.

I watched Dr. Hipp's keynote. Here's my summary for folks who don't want to sit through it. (This is hand written, not LLM-generated.)

Dr. Hipp suggests a definition of "AI" in which SQL planners are AI, defining AI as "any computing system that performs tasks typically associated with human reasoning, problem-solving, and decision-making." (He then explains briefly how SQL planners are runtime code generators. If you're not familiar with how SQL planners work, the keynote is pretty short and worth a watch.)

He then makes a recommendation to developers who are afraid that AI will take their jobs. He points out that SQL planners kinda take away part of the job of a developer, but really just changed the nature of the job.

He makes his point with a slide:

> Q: How can you avoid being replaced by AI?

> A: Solve more problems than you create.

He concludes with a recommendation against having LLMs generate your SQL entirely. He recommends writing it yourself in order to understand it better and engage both the part of your brain that process human language and the part of your brain that processes formal languages like SQL. (He gives an example of trying to ask a coworker for help, but solving the problem by explaining it to the coworker, and how valuable that experience is.)

---

For my part, I'm not sure I agree with calling a SQL planner "AI" in 2026 (I think that obscures more than it reveals), but the advice to solve more problems than you create will always be wise.

Today, Gmail and other major providers do this by tracking sender reputation at the domain level. If users mark your emails as spam, that hurts your domain's reputation. If a domain's reputation gets low enough, Gmail won't deliver mail from that domain.

It's better than nothing (much better than nothing, IMO), but but spam will continue to be an issue as long as we want/expect to receive incoming mail from strangers, and as long as we plan not to have a centralized authority for email identities.

> It should be really, really cheap to send an email to one person (like a fraction of a fraction of a cent), but get exponentially more expensive the more you send.

The problem is the cost of creating fake identities. As long as creating fake identities has a fixed cost (increasing linearly with the number of identities you create), there's no way to charge the "same person" exponentially more for sending more email. They'll just create new identities to send new emails.

Some people realize this and then start imagining how to forbid fake identities (forbidding truly anonymous email), but that requires a centralized identification authority, which many participants in the system are actively trying to avoid.

If you want a centralized authority for sending messages without spam, then you should just use a popular centralized messaging app. Each messaging app is controlled by a centralized authority, for better and for worse; the general consensus is that spam is a much smaller problem on centralized messaging apps than on email. But centralizing authority is a very high price to fight spam.

Today, each email client just reads the emails and tries to categorize spam, assigning each email a spam "score" and quarantining mail over a certain threshold. We track email identities only by top-level domain names, which do have a cost. Emails can be signed with DKIM/SPF, and we can penalize emails that don't sign themselves. We don't have "central authorities," but there are very popular email services, following a power law, and they're close enough. If Gmail thinks your domain reputation is too low, you're gonna have to buy a new domain name if you want to email anybody on Gmail.

Without one official centralized authority, I think that's about as good as it's ever gonna get.

For the "quick one-off script" case (where Implicitly Declared Classes shine), I think the most galling ceremony in this example is explicitly converting all N items in a list of literals into JsonValues for JsonArray.

This would help a lot:

    public interface JsonArray extends JsonValue {
        static JsonArray of(JsonValue... elements) { ... }
        static JsonArray of(String... elements) { ... }
        static JsonArray of(Double... elements) { ... }
        static JsonArray of(Integer... elements) { ... }
        static JsonArray of(Boolean... elements) { ... }
    }

Then, you could at least write:

    IO.println(JsonObject.of(Map.of("providers",
        JsonArray.of("SUN", "SunRsaSign", "SunEC"))));

And for JsonObject, a little fluent builder API would probably knock out a lot of ceremony, too.

    JsonObject json = JsonObject.builder()
        .put("name", "John")
        .put("age", 30)
        .put("active", true)
        .put("providers", JsonArray.of("SUN", "SunEC"))
        .build();

The alternative today looks quite ceremonious:

    JsonObject json= JsonObject.of(Map.of(
        "name", JsonString("John"),
        "age", JsonNumber(30),
        "active", JsonBoolean(true),
        "providers", JsonArray.of(List.of(
            JsonString("SUN"),
            JsonString("SunRsaSign"),
            JsonString("SunEC")
        ))
    ));