JS Developers should read "You Don't Know JS Yet"

Jeffrey Marvin Forones — Mon, 10 Aug 2026 13:27:53 +0000

I was working through Kyle Simpson's You Don't Know JS Yet, and the coercion chapters did the thing good books do: they made me realise I'd been writing JavaScript for years while quietly avoiding the parts I didn't understand.

Not avoiding them deliberately. Avoiding them the way you avoid a creaky floorboard - instinctively, without noticing you've changed your route. I always used ===. I never thought hard about why, beyond "== is bad". That's not knowledge. That's a superstition that happens to produce correct code.

Kindly look through the work I made to further help delivering Kyle's work through npm cli.

It's free

No tiers, no trial, no email wall. just a normal js npm package where you can practice js quicks.

npx wtfjavascript

If you find a challenge that's wrong, tell me. And if the event loop panel ever disagrees with real Node, I especially want to know - it means my oracle missed a case.

wtf( js ) wtf, JavaScript?! - prove you actually know it
🗿 for JavaScript gigachads - and those about to become one
Every prompt takes h for a hint and s to skip.
Flags, for when you want to aim
wtfjs --list # every challenge, topic and difficulty

wtfjs --topic "Type Coercion" # drill one subject
wtfjs --count 20 # how many
wtfjs --easy 2 --medium 5 --hard 3 # pick your own mix
wtfjs --time 10 # ten-minute run
wtfjs --sudden-death # one wrong answer ends it
wtfjs --no-hints # +10 points a solve

284 challenges, and deliberately not all in one format :)

Credit where it's due

This exists because of other people's work:
You Don't Know JS Yet by Kyle Simpson - the reason I knew there was something to learn.

JavaScript Questions by Lydia Hallie - proof the format works.
Stack Overflow, and the people who spent years arguing about the abstract equality algorithm so I didn't have to.

The idea that these quirks are worth drilling isn't mine, and I'd rather point you at the sources than pretend otherwise. If you haven't read YDKJSY, read that first - this is practice, not instruction.

Testing OTP email flows shouldn't be flaky — meet AssertKit

Jeffrey Marvin Forones — Sun, 24 May 2026 08:58:02 +0000

The single most flake-prone test in any E2E suite is "user signs up,
verifies via emailed OTP, completes onboarding." Why? Because the email
is async, the test runner can't see it, and the bridge between the two
is a 60-line polling helper everyone writes once and nobody wants to
maintain.

I shipped AssertKit to remove that bridge entirely.

The pitch in 8 lines of test code:

  import { test } from "@assertkit/playwright";

  test("signup with OTP", async ({ page, inbox }) => {
    await page.goto("/signup");
    await page.getByLabel("Email").fill(inbox.address);
    await page.getByRole("button", { name: "Sign up" }).click();
    const otp = await inbox.waitForOtp({ from: "noreply" });
    await page.getByLabel("Code").fill(otp);
  });

That's it. No polling. No regex. No flake.

How it works

The inbox fixture gives every test a unique disposable address (foo-1717xxx@assertkit.com).
waitForOtp long-polls the AssertKit server for up to 25 seconds.
The server watches for inbound mail to that address, extracts any OTP-shaped code, and returns it as a typed field.
Your test gets a string, not an email body to parse.

Cypress users: same package, same shape:

  import "@assertkit/cypress";

  cy.uniqueInbox().then((inbox) => {
    cy.visit("/signup");
    cy.get('input[name="email"]').type(inbox.address);
    cy.get('button[type="submit"]').click();
    cy.waitForOtp(inbox.local).then((otp) => {
      cy.get('input[name="otp"]').type(otp);
    });
  });

Try the live demo (no signup):
https://assertkit.com/demo

The demo opens a real long-poll against the real wait endpoint. A
canned email arrives 3 seconds later. You'll see the OTP land in real
time.

Free to try:

Both npm packages are MIT, zero runtime deps
The free public API works without an account
Subscriptions aren't open yet — there's a /beta program for early access with admin approval

Tech stack (if anyone's curious): Next.js 16 App Router, Drizzle +
Neon Postgres, Supabase Realtime for sub-100ms broadcast, CloudMailin
for inbound MX, Resend for outbound (DKIM-signed), Upstash KV for
rate limits, argon2id + RFC 6238 TOTP for auth.

Solo founder, happy to answer anything.

DEV Community: Jeffrey Marvin Forones

JS Developers should read "You Don't Know JS Yet"

Testing OTP email flows shouldn't be flaky — meet AssertKit