TanStack dominance intensifies

Today’s issue: Becoming a Silicon Valley insider, erotic Erlang, and a JavaScript engine zoo.

Welcome to #441.

---

TanStack dominance intensifies

TanStack just hit 4 billion total npm downloads across all of its open-source projects – which means that statistically speaking, Tanner Linsley is more famous than Glen Powell now. It’s simple math.

And the Tan train isn’t slowing down any time soon. They just released TanStack DB 0.5 on Tuesday and introduced a unique new feature called Query-Driven Sync, which makes your component’s query the API call. No custom endpoints, no GraphQL resolvers, and no backend changes.

The pitch is to “just write your query and TanStack DB figures out exactly what to fetch.” Here’s what that means in practice:

• Pure queries over data – Similar to how React made components a pure function of state with UI = f(state), it brings the same philosophy to data with view = query(collections). Just describe the data you need and it handles all the fetching, caching, and updating by recomputing queries whenever the underlying data changes.

• Live queries that compute themselves – TanStack DB turns your where, join, orderBy, and limit clauses into expression trees powered by differential dataflow. That lets it incrementally compute exactly which records need to load or reload, and generate the minimal network calls required to keep your query up to date.

• Three sync modes that scale – Eager mode loads everything up front, On-demand mode loads only what your queries request, and Progressive mode gives you a fast first paint while syncing the full dataset in the background. This lets you scale from 1,000 rows to over 100k without changing any code.

Bottom Line: Query-Driven Sync promises to “fundamentally change how you think about loading data,” and it could become the killer feature that eventually convinces millions of developers to give TanStack DB a try.

I can’t wait to watch Tanner star in Twistersss 3.

---

Sentry made logs finally useful

Logs seem like a great idea in theory – but in most real apps, they’re noisy, expensive, and unhelpful (the unholy trifecta).

Sentry finally did something about that by creating structured logs that are tightly connected to your issues, traces, and code.

That way, you can see what happened and why it happened without switching tools or losing context:

• See the logs behind a bad deploy or dropped webhook right from the issue
• Spot silent failures with trace-connected logs
• Search structured logs by real metadata, instead of raw string hopes and dreams

Check out the docs to see how it works.

---

const newsletter = "Bytes"
const tagline = "Your weekly dose of JavaScript"

[newsletter, tagline].forEach((el) => console.log(el))

---

1. Meta software engineer, Melissa Liu wrote an insider’s guide to Meta’s StyleX styling system. So now you can finally feel like a Silicon Valley insider – just not the kind who ends up on flight logs with Peter Thiel and you-know-who.

2. Manoj Vivek wrote about the inner workings of JavaScript source maps.

3. Bora Gönül wrote a love letter to Erlang. I wouldn’t say it was erotic, but I also wouldn’t say it’s not erotic.

4. Molisha Shah wrote about 10 AI tactics that actually end context switching for full-stack engineers – and how Augment Code is uniquely built to do that with a 200k-token context engine and persistent memory architecture. [sponsored]

5. JavaScript engines zoo lets you compare over 100 JavaScript engines by performance and learn more about each one.

6. Speaking of which, Andy Wingo wrote about the last couple years in v8’s garbage collector.

7. Ian Macartney wrote a deep dive on authorization in practice that explains all the different approaches and the tradeoffs of each one. Most importantly, it’ll help you understand how it’s different from authentication. [sponsored]

8. imgui-react-runtime is an experimental React runtime for Dear ImGui that uses Static Hermes to let you write interfaces with React’s component model, hooks, JSX, event handling, and a bunch of other stuff the Remix team probably hates.

9. Nicolas Charpentier wrote an interactive blog post called Don’t blindly use useTransition everywhere, but Nicolas is not my mom so I technically don’t have to listen to him if I don’t want to.

10. CarbonQA provides high-quality QA services for dev teams, so you’ll never have to waste time testing your own app again. Their US-based testers work in your tools, talk with your team on Slack, and let your devs spend their time building real features. [sponsored]

11. Emil Kowalski shared 7 simple animation ideas to help you improve your animations without needing to fully sell your soul to the dark lord of animations.

12. Flutter 3.38 and Dart 3.10 are now available, and the team says “they are HOT.” I’m not 100% sure what that means, so you might want to put your terminal in Incognito Mode just in case.

---

const newsletter = "Bytes"
const tagline = "Your weekly dose of JavaScript"

[newsletter, tagline].forEach((el) => console.log(el))

You might be surprised to learn that this code doesn’t execute. If you try, you’ll get an error – Uncaught ReferenceError: tagline is not defined. But clearly it is, right? Wrongo.

This is the very rare scenario where not using semicolons can bite you. Because we have a string followed by no semicolon followed by an opening array bracket, JavaScript interprets our code like this, as if we’re trying to access elements from the string.

"Your weekly dose of JavaScript"[newsletter, tagline].forEach();

This, of course, throws an error because tagline isn’t defined. To fix this, add a + sign before the array.

const newsletter = "Bytes"
const tagline = "Your weekly dose of JavaScript"

+[newsletter, tagline].forEach((el) => console.log(el))

That’s mostly a joke, but it does work…

Instead, just use semicolons.

const newsletter = "Bytes";
const tagline = "Your weekly dose of JavaScript";

[newsletter, tagline].forEach((el) => console.log(el));