Can you share what software you’re using to make the diagram? Is this Graphviz or something else?

What about taking impl Into<String> as a function argument?

The orange site never fails.

All this to say, it’s a little concerning.

It isn’t like we couldn’t build stateful web applications before React.

I hope we don’t forget those patterns.

As an example, imagine a server-rendered application a la Rails or Django: I see folks trying to conflate HTTP verbs because they, “don’t want to lose form input state” between requests.

What problem do folks think things like sessions are solving?

My hunch is that people, especially junior folks, are so used to thinking about the ways that frontend frameworks address state management, that patterns which lean into HTTP seem foreign or impossible.

Maybe the most surprising thing is how confident folks are in their misconceptions .

That’s what I’m doing.

I’ll say that I don’t think you really need HTMX most of the time tho.

I do want ML. But that’s kind of orthogonal to the TypeScript woes.

Actually what I really need is less client-side runtime.

While there are some JS things that do this, frankly I’m so much more productive with Rust. (One killer feature here is cargo; compare with esbuild and ecmascript modules.)

I think the thing about Rust productivity is you don’t need to be deep in the weeds with complex memory management (unless you want to be).

In other words, you can work at a pretty high level most of the time if what you’re doing fits that scope (like web dev).

Update: no longer friends with TypeScript.

In all seriousness the stability of the JavaScript ecosystem is insane and so now things have moved to Rust.

Going forward I can’t see many situations where I’d actively reach for JavaScript (typed or otherwise).

Most of our stack is actually TypeScript 😅

That’s right, we’ve implemented custom crawlers

I agree.

They need to “self police” their own platform, bsky.app.

That isn’t up to us the users.

Plenty of folks are objecting to the idea that they would moderate their own instance of AT.

The problem with centralized protocol moderation is that it’ll be fine until the day Elon takes over and removes all the value aligned rules you care about.

You don’t actually want that.

That isn’t a point I’m arguing.

However, plenty of folks are up in arms because they don’t want to run their own server and self moderate it.

This is absolutely wild: you need to moderate an online forum if you run one. The advantage is AT will (hopefully) have better tooling for it.

I already said that I would agree the platform, bsky.app, has a responsibility to moderate. They need to “self police” their platform.

Where people are running amuck is conflating this instance of AT with AT as a protocol and demanding the team moderate the protocol itself.

But that’s how the WWW works.

What AT gives you over HTTP is hopefully better tooling to prevent harassment.

They never promised to police the whole protocol (this is exactly what Jack wants to escape vis-à-vis Twitter) and I truly don’t think that’s what most of us would want anyway.

Think of it like this: I can run my own forum accessible via the World Wide Web.

This forum can be targeted in all sorts of awful ways, which mirror the ways communities can be targeted here.

But ultimately it’s up to me to moderate and police that community… I can’t ask Tim Berners-Lee to help.

It’s important to differentiate between AT, the protocol, and bsky.app, the most popular instance that provides AT today.

I agree that bsky.app should do their own platform moderation.

I disagree with the suggestion that they should also own moderation of the broader AT protocol.