I’ve written about how Svelte, Vue, and Solid are all reactive and share common pitfalls due to their reactive solutions. My theory is that they all cause worse bugs than they prevent.

https://crank.js.org/blog/why-be-reactive/

Compared to what? I mean, what's the alternative for an interactive app?

Manual refresh(). This is something Crank does, and other frameworks like the new Remix one is picking it up as well. Being explicit has its advantages.

I had the same reaction to this post. Mainly because one of Meta's explanations for the lapse was that they didn't have moderators who understood the local language

You hear that folks? Lack of localization kills.

Do you also boycott Toyota for the Hilux?

I don’t own a car :)

I must tell you, it is an incredible relief to learn that McZee was not a figment of my imagination.

Just found the text editor from my childhood

I keep asking why the default Claude tools like Read(), Write(), Edit(), MultiEdit(), Replace() tools aren’t just Bash() with some combination of cat, sed, grep, find. Isn’t it just easier to pipe everything through the shell? We just need to figure out the permissions for it.

Because the Tools model allows for finer grained security controls than just bash and pipe. Do you really want Claude doing `find | exec` instead of calling an API that’s designed to prevent damage?

not for every user or use case. when developing of course i run claude —-do-whatever-u-want; but in a production system or a shared agent use case, im giving the agent least privilege necessary. being able to spawn POSIX processes is not necessary to analyze OpenTelemetry metric anomalies.

Making those tools first-class primitives is good for (human) UX: you see the diffs inline, you can add custom rules and hooks that trigger on certain files being edited, etc.

I’ve found that humans are pretty good at reading through the output of bash commands. And Claude Code keeps insisting on truncating the output for some reason.

A long time ago, I wrote an abstraction called a Repeater. Essentially, the idea behind it is, what would the Promise constructor look like if it was translated to async iterables.

  import { Repeater } from "@repeaterjs/repeater";
  
  const keys = new Repeater(async (push, stop) => {
    const listener = (ev) => {
      if (ev.key === "Escape") {
        stop();
      } else {
        push(ev.key);
      }
    };
    window.addEventListener("keyup", listener);
    await stop;
    window.removeEventListener("keyup", listener);
  });
  const konami = ["ArrowUp", "ArrowUp", "ArrowDown", "ArrowDown", "ArrowLeft", "ArrowRight", "ArrowLeft", "ArrowRight", "b", "a"];
  (async function() {
    let i = 0;
    for await (const key of keys) {
      if (key === konami[i]) {
        i++;
      } else {
        i = 0;
      }
      if (i >= konami.length) {
        console.log("KONAMI!!!");
        break; // removes the keyup listener
      }
    }
  })();

https://github.com/repeaterjs/repeater

It’s one of those abstractions that’s feature complete and stable, and looking at NPM it’s apparently getting 6.5mil+ downloads a week for some reason.

Lately I’ve just taken the opposite view of the author, which is that we should just use streams, especially with how embedded they are in the `fetch` proposals and whatever. But the tee critique is devastating, so maybe the author is right. It’s exciting to see people are still thinking about this. I do think async iterables as the default abstraction is the way to go.

In the repeater callback, you're both calling the stop argument and awaiting it. Is it somehow both a function and a promise? Is this possible in JS?

edit: I found where stop is created[1]. I can't say I've seen this pattern before, and the traditionalist in me wants to dislike the API for contradicting conventions, but I'm wondering if this was designed carefully for ergonomic benefits that outweigh the cost of violating conventions. Or if this was just toy code to try out new patterns, which is totally legit also

[1]: https://github.com/repeaterjs/repeater/blob/638a53f2729f5197...

Yes, the callable promise abstraction is just a bit of effort:

  let resolveRef;
  const promise = new Promise((res) => { resolveRef = res; });
  
  const callback = (data) => {
    // Do work...
    resolveRef(data); // This "triggers" the await
  };

  Object.assign(callback, promise);

There’s a real performance cost to awaiting a fake Promise though, like `await regularPromise` bypasses the actual thenable stuff.

It's not common, but there are web APIs where you await a promise that already exists as a property, rather than being returned from a function call, like

    await document.fonts.ready

    device.lost.then(() => {
      console.log('WebGPU device lost :(')
    })

I feel like this isn't confusing if you know how promises work, but maybe it can be confusing for someone coming from Python/Rust, where async functions don't evaluate until their futures are awaited.

Off topic - But just wanna say - Love the cheat code! 30 Lives added :-) Nostalgia runs deep with that code. So deep - in fact, that I sign many of my emails off with "Sent by hitting Up, Up, Down, Down, Left, Right, Left, Right, B, A"

Off topic to the off topic, but that logic doesn't look right. It seems like if up is pressed, you might need to reset i to 1 or 2, not 0.

Not accepting PRs for this. I think the logic is sound (Easter Eggs should be difficult to trigger).

Can anyone who works with the Unicode consortium explain why Cistercian numerals aren’t just part of Unicode? There’s Aegean numbers, counting rod numerals, Mayan numerals, Roman numerals (beyond the Latin letter aliases), cuneiform numbers, and plenty of other historical numeral-only systems.

The 4-stave system is interesting but can almost certainly be done using ZWJ hacks maybe.

From the Script Ad Hoc Group: https://www.unicode.org/L2/L2021/21016-script-adhoc-rept.pdf

"A project to digitize Cistercian manuscripts at Western Michigan University is not requesting the characters be in Unicode, so this is just an informational document. [...] We recommend the UTC make the following disposition: Notes this document (L2/20-290) but takes no further action."

For something to be added to Unicode, someone actually has to request it and shepherd it through the process.

My immediate thought was combining characters eg

  934 = CISTERCIAN STAFF + 
        COMBINING CISTERCIAN 900 +
        COMBINING CISTERCIAN 30 +
        COMBINING CISTERCIAN 4

Would require allocating (1 staff) + (9 digits) * (4 places) = 37 code points.

Were you thinking

  934 = CISTERCIAN 900 +
        ZWJ + 
        CISTERCIAN 30 +
        ZWJ +
        CISTERCIAN 4

?

I was thinking using ZWJ because the staff is always implied by the usage of Cistercian numerals. I was also wondering if we could reuse CISTERCIAN 1-9 for each significant digit rather than having to encode all 4 separately, though at the end of the day it’s only 36 separate code points.

Adding the staff is 37 codepoints versus 36, but I think using ZWJ would at least have each numeral independently renderable so it degrades gracefully. I’m not too sure about how combining characters degrade.

Essentially it boils down to whether you think the staff and the digit flag part of the numeral are independent or not.

Thanks for the kind words! Let me know your thoughts if you end up exploring.

I’ve just published the first public release of a new open source project Shovel.js, replacing tools like Express, Fastify, Next.js, Vite. It’s a full-stack/meta server framework which implements the full Service Worker specification but in Node, Bun, Cloudflare. It leans into using web standards to do things like accessing the filesystem, reading cookies, create client-side bundles rather than inventing new APIs. You can read about the process of making Shovel with AI in the introductory blog post.

https://shovel.js.org/blog/introducing-shovel/

https://github.com/bikeshaving/shovel

Seeing this makes me miss the salad days of MOOCs. I learned programming in the 2010s through MIT’s EDX Introduction to Programming course, and then a course on Coursera by Martin Odersky on Functional Programming through EPFL, and I feel like that ladder has been kicked away due to MOOC monetization policies. I wonder if we could return to these days.

I took the EPFL course as well, although did not finish it. As someone who only had experience working with imperative programming and OOP stuff, it blew my mind -- I never knew you could write code like this. The course was great but a bit too fast for me at the time (part of the reason I did not complete it).

Dont many of them end up as Youtube playlists anyways?

Yeah, there were 2 golden ages:

1- When this internet thing came out

2- When this covid thing came out

On the first era, here's a Java lecture from Stanford, if it's too basic for you, it still has historical value, iirc it's something like Java 6. And it also reinforces the basics.

https://www.youtube.com/watch?v=KkMDCCdjyW8&list=PLA70DBE71B...

It's a bit harder to follow along with online materials since you have to use the Internet Archive, and download older compilers or use options to target older versions, but it's all the more fun for it.