There was no hint of Tailwind suggested here before this - open Claude, say you're building a new cross-platform React app, ask for a plan to get started => use Tailwind A, Tailwind B, or Tailwind C.
Which UI styling approach do you prefer? 1. Tailwind + shadcn/ui (Recommended) Tailwind for utility CSS + shadcn/ui (Radix-based) for accessible, customizable components. Best native feel with full control. 2. Tailwind + Radix UI Tailwind for styling + raw Radix primitives. More manual work but maximum flexibility. 3. Ionic + Tailwind Ionic provides native-quality components and transitions out of the box. Heavier but purpose-built for Capacitor apps.
Wow, I sure am glad we have such diversity in the CSS world and that AIs consider all of the options fairly, instead of hypothetically being hyper focused on any specific library.
⚠️LAST CALL TO WRITE TO CMA: 5pm TODAY ⚠️ DEMAND FAIR ACCESS on iOS Equal API Access to All Apps Equal Performance and Privileges Enforceable Deadlines & Oversight FAILURE MEANS: Developers can’t compete with Apple’s Apps & Hardware Apple keeps features to themselves Browsers & the Web won’t be able to compete Sets Global Precedent for weak digital legislation Less Competition = More Expensive + Worse Quality for consumers 👇 Read more, OWA blog link below
⚠️ LAST CALL TO WRITE TO CMA: 5pm TODAY ⚠️
Under the current proposal, Apple can keep iOS and iPhone functionality exclusive to its own apps and services.
If you want fair access to APIs for competing apps and browsers email 📧 mobilesms@cma.gov.uk
See: open-web-advocacy.org/blog/apples-...
🧵👇️(1/5)
Haha, fair. In this case it was Open Collective, which is some cases effectively is a bank - but yes it's very annoying when random sites act like they need the same security as a gold vault to protect my shopping list. Honestly even for bank accounts most of the time it's way OTT.
Magic link login is fine, session expiry is fine, but for the love of god please don't do both.
If you have to re-auth every week, there is little more frustrating that blocking the process waiting for an email so I can click a button, over and over and over...
After implementing web streams in multiple runtimes, supporting them for years, talking with other implementers, dealing with issues... I think it's well past time we talked about something better blog.cloudflare.com/a-better-web...
This inspired by me quickly temporarily creating a "WIP" commit to track some state, and then worrying about actually pushing it publicly by accident... Now conveniently impossible!
Everybody's favourite "save me from myself" git hook (github.com/pimterry/git...) has the first new major feature in nearly 5 years: it'll now validate and catch unintended git pushes too 😀
Wouldn't it be nice if HTTP compression suddenly got 90% better for a whole bunch of common web scenarios?
Dictionary Compression is here to save the day: httptoolkit.com/blog/diction...
2026 is the year Bluesky and the Atmosphere really come alive
here's what's next
bsky.social/about/blog/0...
Node.js code that loads TLS & crypto, starts defining a KEY variable with BEGIN PRIVATE KEY, and then loops on the same 'random' string forever...
My AI code generation has decided it can generate an inline private key pair by itself, and I think we might be in trouble...
I use Bunny for CDN, DNS, video streaming & object storage. It's been absolutely rock solid (I've noticed zero downtime in multiple years) and very reasonably priced.
DX less polished, narrower feature set, but for the core functionality if I started again today, I'd pick them over Cloudflare 100%.
Really? He's the #1 frontman for tech getting into bed with the hard-right. Bold choice.
Screenshot of a Cloudflare site that says "500 Internal Server Error – Cloudflare"
Happy Cloudflare is down once again to all who celebrate
I have a published general purpose hook for exactly this: github.com/pimterry/git-confirm 😀
Add any patterns you like (like TODO) and it'll ask you to confirm before you ever commit any change with those strings.
A perfect CVSS 10 🧑🏻🍳💋
CVE-2025-55182: Unauthenticated remote code execution vulnerability in React Server Components
The vuln is in versions 19.0, 19.1.0, 19.1.1, and 19.2.0:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
Upgrade immediately!
Honestly I'm just really excited to discover that people running a global DDOS setup have heard of me.
Maybe this is somebody trying to hammer Paddle through me? Maybe they're just messing around & testing things? Very odd.
On a more practical note: all this API is separate from product delivery & functionality, and existing accounts will work fine even if it goes offline for days. Could only really impact new checkouts, no need for anybody else to worry.
Much credit to Scaleway autoscaling & Bunny CDN for taking the edge off here.
Wouldn't say the accounts API loves it, but seems to be autoscaling and holding up just fine, the only errors I see are affecting the attackers' own requests for now (largely due to Paddle rate limits). All manageable.
Needless to say, HTTP Toolkit normally does not normally have 500k daily customers. Clearly recent marketing efforts are paying dividends!
For some reason, somebody using random IPs and random-ish emails for every request hit the HTTP Toolkit checkout API ~500k times this morning.
Being hit by my first DDOS attack right now, it's all quite exciting!!!
I have seen github.com/step-securit..., but a) I'd rather go 100% hardware passkeys instead of messing with TOTP, b) I want to gate non-npm deployments as well, so I'd love a general solution, and c) linking a rule directly to the env instead of using a step would provide some broader guarantees.
It looks like you could gate OIDC publish on 2FA today via docs.github.com/en/actions/h..., though I can't see that anybody has implemented a 2FA provider for that yet.
Would that be sufficient? Any idea if anybody is working on it?
I'm aware of concerns with CI publishing, hadn't heard about provenance concerns, it's interesting! Imo full reproducible builds would be great, but reproducing the process is an independent problem to proving the input (though a shared goal). But if you don't want to rehash that's fair, no worries.
Is it? Seems like the npm metadata is user controlled (a nice signal, little more) while TP provenance does give some guarantee (backed by GitHub) that the code at the recorded commit hash generated the output.
Stores the commit hash as well, so GHA history would be nice but not strictly necessary.
