the [@react.dev](
Bluesky Social
react.dev
 ) Compiler works for the same reason that compilers for pure programming languages are able to make non-trivial optimizations. if your code is composed of pure functions, it is safe to re-order their computation, or save the result for some inputs and reuse it for later for same inputs.
i thought [@ricky.fm](
Bluesky Social
Ricky (@ricky.fm)
React core team • Forbes 30 worst over 30
 ) talk was very good. i hope they’ll glue it up together from two days into a cohesive video. slightly sad about the last example breaking (a one-line mistake) but such is the nature of live demos. overall i think it’s a great conclusion to last ten years of work from the team. 💜
i agree, not because i hate ai or think its bad or whatever, but because it looks ass. it rarely communicates more than prompt. semantically it’s like 2x2 resolution, waste of space RE:
Bluesky Social
Andy Bell (@bell.bz)
If you’re generating an image for your article with AI, you didn’t need one in the first place
 View quoted note →
this is actually my motivation for typelex. not so much specific production usage but more that i can't write an atproto tutorial that includes "write this json blob". i *still* want to close a tab when i see a lexicon json definition. so with myself as the "target reader", i *need* an idl already RE:
Bluesky Social
dan (@danabra.mov)
so imo it's the difference between "here's this arcane config you have to write to get the most basic app working" vs "here's a sleek mini-language...
very interesting talk by [@lunaleaps.bsky.social](
Bluesky Social
Luna Wei (@lunaleaps.bsky.social)
 ) from the second day of react conf about RN threading and virtualizating lists, highly recommend watching https://morel.us-east.host.bsky.network/xrpc/com.atproto.sync.getBlob?did=did:plc:fpruhuo22xkm5o7ttr2ktxdo&cid=bafkreihddbjeg65wvhyjw2ltxexjs6ra4pf4mbqib733uqv3eb2btkeqpe
the biggest challenge in contributing to the AT ecosystem so far is whatever small project i think of doing, i find out somebody has already done before. this isn’t a complaint though i wish things were more discoverable. but also i just need better ideas
in my opinion this ended up being a great thing for react. if you chase “adoption” as a primary metric in your open source project, you’ll make different choices than if you just want the project to meet its use cases and be useful to other people RE:
Bluesky Social
dan (@danabra.mov)
i worked on react at meta for eight years, and there was literally never a moment when the management would ask what we’re doing to increase “d...
ayyy [@ricky.fm](
Bluesky Social
Ricky (@ricky.fm)
React core team • Forbes 30 worst over 30
 )’s getting a second chance! i’ll watch though it’ll be late RE:
Bluesky Social
Ricky (@ricky.fm)
Part 2 is on the schedule, I’m just going to start the demo over and finish the talk from there [contains quote post or other embedded content]
posted some thoughts on "external lexicons" workflow for typelex. [tangled.org/@danabra.mov...](
First-class support for External Lexicons #5
The current state of externals is documented here: https://tangled.org/@danabra.mov/typelex/blob/main/DOCS.md#external-stubs Currently, if you wa...
 ) this would require a CLI that generates stubs based on a list of external lexicons. this makes me think it might make sense to adopt a convention like lexicons.json from [jsr.io/@lpm/cli](
JSR
@lpm/cli - JSR
@lpm/cli on JSR: Lexicon package manager for atproto schemas.
 ) cc @Tom Sherman
yay! “three hours” was bait tbh RE:
Bluesky Social
Tangled (@tangled.org)
*ahem* https://tangled.org/@danabra.mov/typelex that was not a three hour change btw :) [contains quote post or other embedded content]
 View quoted note →