> JS devs have tried to use JS for everything and found limits

Yeah, seems NodeJS kind of made some people into JS-zealots, while us web developers have thought of separation of concerns from the beginning, hence the holy trinity of HTML, JS and CSS. Glad others are catching up with web developers for once :)

> Meanwhile I can’t get Claude code to fix its own shit to save my life.

Maybe this should give you some hint to that you're trying to use it in a different way than others?

Yeah, also missing a built-in JS API for turning Markdown into safe HTML. Sure, there are lots of different implementations, but maybe start with something small at least.

Maybe BIOS or other firmware? No clue, but my GPU also runs better on Linux that Windows today.

When people talk about "The Algorithm", they're not talking about just some function that sorts stuff by X or Y, but an feed optimized for "evil X", usually trying to drive longer attention, or push up engagement.

If GitHub started using the submissions GitStars to recommend repos in people's GitHub feed, I don't think people would get their pitchforks out about "The Algorithm" in that case. But if GitHub started to make the feed so you spend as much time there as possible, by whatever means and potentially irrelevant stuff, then the GitHub feed would start being considered as one of "The Algorithms" by many, would be my guess.

It seems to generate pretty good "Recommended repos for you" suggestions, all of them I've heard and seen before, but for one or another reason didn't use for anything or found a need for. Would be great if it could show more options than just 10, because I'm sure further down the list it'd have interesting suggestions I hadn't seen before.

Sounds like it actually generates poor suggestions for the reason you are describing. For me, it exclusively suggested repos I've already seen, but did not like.

These seems like an inherent challenge to recommending based on stars. Stars are very sparse, so there’s little “didn’t star this” signal, and there’s no “thumbs down”.

So you’re left with things you “should” star, but there very well could be a reason you didn’t.

> The only driver that I can really comprehend is the desire for freedom and autonomy in less populated spaces

Exploration and seeing what's beyond seems to be innate in some people, not so much in others. Personally, if someone gave me to the opportunity today to "Sit in this rocket and get launched out into infinity and report back what's out there", I'd probably do it, and I'm sure I wouldn't be the only one. Curiosity would be enough for me to go.

> They really shouldn’t be let outside unsupervised.

Alternatively, get them a collar with a little bell, and let them try (and always fail) to hunt.

I guess the odd deaf squirrel wasn’t likely to last long anyway. A bell could work to keep them from stalking. They can still run, leap, and ambush. It seems a bell should at least greatly mitigate the issue. I might say usually rather than always. To be fair, though, supervision won’t stop them every time either.

> They can still run, leap, and ambush.

Whenever they do, there is a little tingle tingle, whatever tiny little movement they're trying to do. They end up unable to catch anything basically, I literally never witnessed one of our cats catching anything growing up, nor them bringing any "gifts".

> Then there is the whole experience, again depending on the language, to produce a .wasm file, alongside the set of imports/exports for the functions, instead of a plain "-arch=wasm".

Doesn't the "WASM Components Model" kind of solve this? I've been hacking on a WASM-app runner (in Rust) which basically loads tiny apps that are compiled into "Components", and seems simple enough to me to use and produce those.

Not really, you have a blessed experience by using the language most people on WebAssembly ecosystem are using nowadays.

> MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code.

I don't think MCP is what actually enables that, it's LLMs that enable that. We already had the "HTTP API" movement, and it still didn't allow "without custom glue code", because someone still had to write the glue.

And even with MCP, something still has to glue things together, and it currently is the LLMs that do so. MCP probably makes this a bit easier, but OpenAPI or something else could have as easily have done that. The hard and shitty part is still being done by a LLM, and we don't need MCP for this.