The Davos of web components

Today’s issue: The Bun + Smuckers collab we’ve been waiting for, the most important part of Reactivity, and using a new JavaScript feature to figure out the optimal Settlers of Catan strategy.

Welcome to #256.

---

The Davos of web components

Earlier this month, the W3C Web Components Community Group met to discuss new Web Components features and platform improvements going into 2024.

This W3CWCCG (?) meeting featured representatives from big tech companies, open source libraries, and browser vendors — it’s pretty much the Davos of the web standards world, just with fewer private jets and slightly less cricket flour.

We weren’t classy enough to score an invite, but we still managed to get the inside scoop on three of the most impactful platform developments coming soon to a browser near you:

Declarative Shadow DOM will be shipped in Firefox v123 on February 20th, which will give it full cross-browser support 🥳. This API lets you use Shadow DOM directly in your HTML without writing any JavaScript — allowing you to do lots of cool stuff like server-rendering your web components without having to use the attachShadow() JS element.

Scoped Element Registries were recently prototyped in Chrome to allow multiple custom element definitions for a single tag name to exist within a page. This gives you the option to not have all custom elements defined globally in HTML, which is particularly helpful for larger, more complex applications. Sadly, it’ll probably be a while before we get full support from all three browsers.

CSS Style Queries let you query a CSS property or variable for a container and style the child based on that. Today, we have full cross-browser support for Container Size Queries, but only Chrome currently supports Style Queries. WebKit and FireFox discussed their plans for implementing this feature at the meeting, so we should hopefully see cross-browser support for Style Queries in the near future.

Bottom Line: It’s interesting to contrast the excitement around the web platform’s continued glow-up with the frustration and bad vibes within the React community right now. Could we see more React devs turn to platform-focused libraries like Lit and Astro for more projects going forward? It’s definitely worth monitoring.

---

Make sure your application is ready for scale with Multiple

Your team has been working towards this big launch for months. And today, you finally get to share your work with millions of users and bask in the glory of your software and — oh crap, the whole app just crashed ☠️.

You should’ve used Multiple. Their developer-centric load testing platform lets you test anything across your stack in less than 10 minutes, so you never have to worry about outages or cloud cost spikes again.

Here’s how:

• Write load tests with JavaScript and npm packages; no proprietary tools or config files needed (see the docs)

• Test any service, database, or protocol in your stack and easily share real-time results with your team

• Create custom metrics to measure resource utilization, scalability, and anything else you need

Try it for free — so you can prevent outages, reduce cloud costs, and release new stuff with confidence.

---

function p1() {
  return new Promise((resolve, reject) => {
    setTimeout(() => reject("Error in p1"), 1000);
  }).catch((error) => {
    console.error(error);
  })
}

function p2() {
  return new Promise((resolve) => {
    setTimeout(() => resolve("p2 resolved"), 1000);
  });
}

function pAll() {
  Promise.all([p2(), p1()])
    .then((results) => {
      console.log("All data resolved:", results);
    })
    .catch((error) => {
      console.error("Error resolving data:", error);
    });
}

pAll();

---

1. The Bun Shell is an experimental embedded language and interpreter in Bun that lets you run cross-platform shell scripts in JavaScript & TypeScript. I’m not sure how we can get Smuckers Magic Shell to sponsor this, but it’s a collab that needs to happen.

2. Ricky Hanlon from the React core team wrote this tweet thread about some upcoming features for client-only React apps.

3. On Jan 31st, Sentry is hosting a free workshop on How to identify, trace, and fix endpoint regression issues. “Wait, what’s an endpoint regression issue?” If you just thought that to yourself, you should probably definitely sign up. RSVP here. [sponsored]

4. Bradley Meck Farias wrote this very in-depth post called Judicious JSON, which covers all of JSON’s underlying topics. Keep an eye out for the sequel, Bodacious Booleans.

5. Next.js 14.1 just came out with parallel & intercepted routing improvements, Turbopack improvements, and next/image improvements. #NewYearNewMe.

6. Ryan Carniato wrote about how Derivations are the most important part of Reactivity

7. Waku just released v0.19, which marks a shift from Waku being a theoretical implementation of RSC, towards it becoming a production-ready React framework.

8. If you’re tired of testing your team’s app yourself, check out CarbonQA’s high-quality QA services for dev teams. They give you a team of US-based QA testers, so you can catch bugs and never waste engineering time on QA testing 🙏. [sponsored]

9. Like we mentioned in the main story, there are various leaders in the React community who have recently written about their frustration with React’s current direction, including Cassidy Williams, Tanner Linsley, and Tom MacWright.

10. iliazeus wrote about the new Explicit resource management feature in JavaScript and TypeScript. Contrary to popular belief, this feature does not generate an optimal strategy for which Settlers of Catan resource hexes to claim at the beginning of the game.

---

function p1() {
  return new Promise((resolve, reject) => {
    setTimeout(() => reject("Error in p1"), 1000);
  }).catch((error) => {
    console.error(error);
  })
}

function p2() {
  return new Promise((resolve) => {
    setTimeout(() => resolve("p2 resolved"), 1000);
  });
}

function pAll() {
  Promise.all([p2(), p1()])
    .then((results) => {
      console.log("All data resolved:", results);
    })
    .catch((error) => {
      console.error("Error resolving data:", error);
    });
}

pAll();

First, Error in p1 is logged, then [ 'p2 resolved', undefined ] is logged. Since p1 catches the rejection, it doesn’t propagate to the Promise.all catch handler allowing p2 to resolve. But, since p1 doesn’t return anything, it’s result is undefined.