Tom Sherman

Tom Sherman

@tom.sherman.is

Software Engineer in Norwich. he/him Working on @frontpage.fyi

8.5K followers498 following4.4K posts

Are any other admins of a discord server and seeing many users leaving the server because their account is deleted?

These people are all inactive and I believe discord deleted inactive accounts but we've had a massive wave in the past 24 hours. Maybe discord changed the policy and shortened the window?

I'm so internected right now

Tom Sherman@tom.sherman.is

A @bsky.app thread, published as a @standard.site document, rendered on my site, posted to @bsky.app, rendered as a @standard.site embed ╰(*°▽°*)╯

The other reaction I'm having is that I'm less certain on lifting these things up to infrastructure ie. Serverless. Makes me less excited about things like celld, couldn't that just be a library that gets deployed to a mesh of regular node.js pods?

Tom Sherman@tom.sherman.is

An interesting reaction I'm having to working with effect.website is that I'm way less hesitant to make things stateful or dynamic. Really tips the scales of that trade off in a lot of cases

An interesting reaction I'm having to working with effect.website is that I'm way less hesitant to make things stateful or dynamic. Really tips the scales of that trade off in a lot of cases

Eg. for service configuration I'd usually just rely on a restart, but with Effect I'm happy for config to dynamically update at runtime. The benefits of that config updating dynamically now outweigh the complexity of implementing it because Effect makes it so easy to do

Platform engineer, product engineer, polish engineer These are the three roles going forward, sorry I don't make the rules

Opus 5.5 still isn't that good at doing React Server Components. It doesn't seem to understand that you don't have to render RSCs as children and it doesn't get that you can share state across sibling client trees with context, it's obsessed with lifting and making more stuff client needlessly

Can I author posts on somewhere like @leaflet.pub (that owns my standard.site publication) and integrate/render the post on my own site with @standard.site metadata? Even though the publication URL will be different of course In other words: how does syndication work?

I'm building an activity feed of all of the things I do online inspired by @dame.is' homepage and I just realised that I'm essentially building an appview lol

Me watching you from the row behind you eat your popcorn from your limited edition Digger boot popcorn bucket at the 21.20 showing of Digger

I'm really changing my opinion on shadcn lately, i don't think it adds enough value to warrant existing Humans and LLMs are not capable of using the component abstractions in a way that's accessible. Being accessible is objective number 1 of any component library or design system

Most recent example of many of this is Claude choosing to conditionally wrap something in a tooltip when it should use disabled on the tooltip root, conditional wrapping causes focus to be shifted to document.body when hiding the tooltip These are just fundamentally bad component abstractions

So I just learned that in @typescriptlang.org any JSX element is allowed arbitrary attributes as long as they contain a `-` 🤔 It's documented as an exemption for invalid JS identifiers (why?) but I checked the source and literally only checks for hyphens. Insane behaviour

Accessible tooltips are incredibly hard to build as a generic component in React (and I assume other component-based frameworks) It's way harder than just linking the tooltip text to the trigger with aria-describedby

View full thread

On top of that it's not even clear what the best default experience is, because there are always use cases where having an accessible label is required and where it absolutely shouldn't exist

For example if a tooltip just shows the full value of a piece of truncated text, it shouldn't be linked with aria-describedby lest the label be announced twice by screen readers In this use case the tooltip only exists for users _not_ using a screen reader

Accessible tooltips are incredibly hard to build as a generic component in React (and I assume other component-based frameworks) It's way harder than just linking the tooltip text to the trigger with aria-describedby

Firstly, what if the trigger supplies a description of it's own? Should Tooltip content A: Override it B: Merge with it C: Yield to it I'd say B is the best default behaviour because A & B throw away context

But this is actually impossible to implement in React without relying on mutation observers. And even that relies on being able to get a ref to the trigger's HTML node, which isn't always possible

I'm still not sold on the syntax noise, it feels weird when you're trying to just compose UI. But if all of your data layer and business logic is in already in Effect it might make sense instead of doing `await Effect.runPromise(e)` in every server component

You write server components and server functions using Effect, and it integrates into React and the framework (Next.js adapter in the repo) to scope resources to the request or the process

So, it's recommended that nav links move focus to the main content by #a11y experts. But I can't find a single app that actually does this outside of static content apps. All of the apps of any complexity that I've checked don't work this way What gives?

Many apps/routers/frameworks do include live region announcements for route changes but don't move focus, even though I see that both measures are recommended equally by accessibility advocates

I feel like this is just a massive case of "it depends", with moving focus at least. It depends on the exact UI, app, demographic, user type, demographic etc. Adding live region announcements for a route change seems like a no brainer, very little reason not to do that that I can see.

And just like clockwork GitHub actions is down. The same time every day it feels like. You'd think GitHub would have worked out which time Americans wake up at this point and pre warm their infra or something

If better models can complete the same task with fewer tokens, this makes the smaller models more expensive in token-based billing models. But smaller models are cheaper to run right? So smaller models are more expensive to use yet cheaper to run? Doesn't this seem backwards?