Abandon ship

Welcome to #126.

We finally got to the bottom of a massive cheating scandal last week when my grandma admitted to her Bridge group that she had been fixing games since the mid ’90s. It turns out her “nicotine patch” was hooked to a wire that buzzed twice whenever one of the other ladies was bluffing. Does this mean I should return those unusually large birthday checks?

This week, we’ve got death, zero tolerance policies, and becoming drunk with power. Let’s ride.

---

Would You Rather

Remember that shiny new React hook that was going to solve all our problems? Yeah, so that’s dead now 🥲.

Zooming in: It’s been 6 months since we got our first look at useEvent, and while the JavaScript thought leaders have been figuring out how to outrank each other for the top SEO spot, the React team has apparently been reading lots of Faulkner.

To be fair, the React Team says they aren’t actually killing useEvent — they’re just incorporating “slightly different usage recommendations, slightly different semantics, and possibly a different name.” This is eerily similar to when my parents told me that my dog Scoot went to live on a farm in the countryside (that was a lie, he was dead).

Similar to when the men’s restroom was closed at my gym (forcing me to choose between pooping my pants or making direct eye contact with the cleaning staff after debasing the ladies’ room), the React team finds itself in an uncomfortable predicament.

On one hand, React has a massive user base and churning the ecosystem isn’t a good option. But on the other hand, it seems like they’re suffering from analysis paralysis and have been struggling to ship meaningful improvements. So what should we all do in the meantime?

It seems like we have 3 main options:

• Option 1: Sit back and let Russ React cook. Patience is indeed a virtue, and the reality is that many of these issues are way smaller than Twitter discourse would make it seem. They’ll eventually figure it out (we hope 😃).

• Option 2: Move state/effects out of React. This is the option that solutions like Signals or Jotai have introduced — which move state and effects out of React and optimizes renders, while still delivering a good developer experience.

• Option 3: Abandon ship. Hot new frameworks like Svelte and Solid look appealing, but they obviously come with their own, very real set of tradeoffs.

Bottom Line: For most developers, it looks like facing the judgmental eye of the cleaning staff is (metaphorically) the best option here. Interpret that how you will.

---

Bright Data is the easiest way to get public web data

Your team has a great idea for this new app. The problem? The data… isn’t easily accessible, you don’t want to spend tons of engineering time trying to get it, and the legal/HR team says you’re “never allowed to visit BlackHatWorld again.”

That’s where Bright Data can help. They can get you public data from anywhere on the internet, and make it easily consumable via JSON or Webhooks. Here’s how:

• It comes with pre-built web scrapers you can use out of the box, or you can build your own in JavaScript with their IDE.

• Their “Unblocker” tool lets you scrape public web data from super complex sites — including solutions for CAPTCHAs.

• If you don’t want to worry about scraping, Bright Data has custom, unique datasets for industries like ecomm and finance that you can access via their API.

Want a practice use case? Check out this video where Nick White used Bright Data to build an app that alerted him when Airbnb prices dropped — even though Airbnb doesn’t even have a pricing API 🔥.

What data are you looking for? Bright Data can get it for you — just ask.

---

Have a job you want to fill?

---

class User {
  async constructor(userId) {
    const user = await getUser(userId)
    this.id = user.id;
    this.name = user.name;
    this.email = user.email;
  }
  ...
}

---

1. ViteConf is happening tomorrow and Wednesday online for free. The speaker lineup is great, but by far the coolest thing they’ve done is allow you to claim a virtual ticket and personalize it with the Bytes tongue logo. (Does this mean we’ve made it? Is this what being drunk with fame and power feels like?)

2. Datadog wrote this solution brief about How to use synthetic monitoring to feel more confident. We’re pretty sure they’re talking about feeling more confident in the software you’re writing, but it might help you feel more confident in your personal life as well. There’s only one way to find out. [sponsored]

3. Salma Alam-Naylor (a staff DX engineer at Netlify) wrote about how she changed her mind about writing new JavaScript frameworks. It turns out that you actually can’t have too much of a good thing, after all.

4. Luca Casonato (from the Deno team) wrote a custom JavaScript runtime in 30 minutes on stage during his talk at Armada JS Conf. Unfortunately, that violated the non-compete clause of his employment contract, so Ryan Dahl was forced to fire him during his subsequent talk on “zero-tolerance policies” at Hardcore OSS CEO Conf.

5. Aleksey Kladov wrote about Hard Mode Rust, which would be a great title for a Discovery Channel show about dudes with beards searching for heavily oxidized objects at the bottom of the ocean.

6. Axios v1.0 just launched (8 years later). Now you can finally use it safely in production.

7. Zarf is a Bun-powered Web API framework with full Typescript support, which we assume is based on Snarf from Thundercats — but the creator wanted to make sure they wouldn’t get sued by Cartoon Network.

8. Andrey Sitnik wrote about a smarter approach to creating Favicons in 2022. It reminded me a lot of my grandma’s recent blog post about “a smarter approach to laundering money through birthday cards.” I guess there were some red flags after all.

---

JavaScript doesn’t allow class constructors to be async. We have to do any async actions outside of a constructor. Static class methods can help with this.

class User {
  static async init(userId) {
    const user = await getUser(userId);
    return new User(user);
  }
  constructor(user) {
    this.id = user.id;
    this.name = user.name;
    this.email = user.email;
  }
} 

const me = await User.init(1)