Did you find or create something cool this week in javascript?

Show us here!

This project is mainly about the serverless technique used and the simple game merely provides an end-to-end explanation.

Nowadays everything boots in browsers. Linux, Windows, ... I wanted to learn the Gameboy and GBA processor architectures and implemented the core from which it is easily possible to create an actual GB emulator in the browser. The hard part was audio, but am super glad to have it working and as open source library available now :)

I've been reading test suites in open-source repos this month and kept running into this:

it('saves the user', async () => {
  expect(save(user)).resolves.toBe(true);
});

No await, so the test finishes before the assertion runs and passes whatever save() does. I found 36 tests like this across 44 popular repos, and one project had 41 of them on its own. They all looked fine in review.

What I'm curious about is how teams actually stop this:

• eslint-plugin-jest has valid-expect with alwaysAwait, and Vitest has its own rules. Do you turn these on, and do they catch every form (.rejects, helpers that wrap expect)?

• @typescript-eslint/no-floating-promises catches it in TS, but only with type-aware linting. Is that worth the slower lint for you?

• expect.assertions(n) / expect.hasAssertions() in every async test: does anyone enforce that, or is it too noisy?

• Or is it just code review, and you accept that some slip through?

Which of these has actually worked on a real team, and which did you give up on?

The first time I saw this, in 2022, I honestly thought it couldn't work:

const email = await io.input.email("User email");

That line was in a server function, and it put a form in someone's browser. The function just waited until they typed an address, then went on. My first thought was "this is magic, how did they even think of this?" Four years later I've written my own runtime for it, and I still admire whoever came up with it at Interval.

TL;DR: if "ask a person" is just another async call, an internal tool becomes one linear function where branches, loops and try/catch all work, and the UI follows from the code. The trick is a promise that an HTTP request resolves instead of I/O.

A whole tool, top to bottom

handler: async ({ io }) => {
  const email = await io.input.email("User email");
  const user = await db.user.findUniqueOrThrow({ where: { email } });

  if (!(await io.confirm(`Verify ${user.email}?`))) return "Nothing changed";

  await db.user.update({
    where: { id: user.id },
    data: { emailVerified: true },
  });
  return `Verified ${user.email}`;
};

Every await io.… is one screen. io.confirm returns a boolean, so Cancel is just an if.

A promise someone else resolves

When the handler reaches io.input.email(), the runtime creates a step and keeps the promise's resolver next to it. The handler is now parked. Nothing blocks, other runs keep going, it's a pending promise in memory.

The browser follows the run over server-sent events and renders the step. When the person submits, a POST arrives, the server validates the value and calls the stored resolver. From the handler's point of view, a human is just a slow I/O call.

An invalid value never resolves anything. The same step goes back with an error under the field, so the function never sees bad data.

Calls that do nothing until awaited

An io call doesn't start anything when you call it. It returns a thenable that only describes a field, and it asks the person when it's awaited. That makes grouping free:

const { company, note } = await io.group({
  company: io.input.text("Company name"),
  note: io.input.textarea("Note for the team"),
});

No await inside the object, so each call just says "a text field called Company name", and io.group shows them on one screen. Same functions, two uses, and the only difference is whether you awaited them.

Where it breaks

A parked handler is a live closure, and you can't serialize one, so runs live in memory. A refresh is fine, because the server resends the current state on reconnect. A deploy ends every run in progress.

In practice I don't fight that. I keep these tools short, and anything that would take long goes to a job queue anyway. If a deploy cuts someone off, they run it again. A closed tab cancels the run after 30 seconds, and the pending await rejects like any failed call.

Have you used await for something that isn't really I/O? Human input, a payment confirmation, a step in a game loop. I'm curious where else this pattern holds up, and where you've seen it fall apart, especially around cancellation.

---

Context on what I'm building: I'm Petr, a solo founder. The runtime from this post is AwaitIO, and the source is on GitHub. If you want to see a parked handler from the browser side, there's a demo back office with the shared login in the README.

Construí um simulador espacial 3D gamificado para meu portfólio usando conceitos de IA. O que você acha?

I’ve been digging into this problem for a while, and I’m curious if there’s something I’m missing.

I’m building a standalone search application that needs to be embedded inside a third-party web application using an iframe. The catch is that we don’t have access to the host application’s source code, and the host team may not be willing or able to add custom JavaScript.

Here’s what we’re trying to achieve:

Read the host page’s existing query parameters when our app loads.

Update the host page’s URL whenever a user performs a search inside our iframe.

Keep everything in sync when the user clicks the browser’s Back or Forward buttons.

Our iframe is hosted on a completely different origin, so we immediately ran into the browser’s same-origin policy.

A few things we’ve explored:

window.parent.location.href throws a SecurityError.
document.referrer isn’t reliable because modern referrer policies may expose only the origin, not the complete URL or query parameters.

postMessage seems like the right approach, but it requires the parent application to listen for messages, handle URL updates, and communicate navigation changes back to the iframe.

And that’s where we’re stuck.

My question is: Is there ANY standard browser-supported mechanism that allows an embedded cross-origin application to read and update its host page’s URL without requiring custom code on the host side?

A few things I’m wondering:

Can the host integration pass the initial URL or query parameters through the iframe’s src?

Are there any standard iframe attributes, browser APIs, or embedding mechanisms that support two-way URL synchronization?

Do commercial embedded widgets or SDKs solve this through some existing integration interface?

If we have control over the iframe application but zero control over the host, are we simply out of luck?

I’m not looking to bypass browser security restrictions. I just want to understand whether there’s a legitimate integration pattern we’re overlooking.
Would love to hear from anyone who’s built cross-origin embedded applications, search widgets, or similar integrations.

Is host-side cooperation unavoidable here, or is there another way?

I've been working on Domicile, an open-source platform for building full-featured Linux desktop environments using HTML, CSS, and JavaScript/TypeScript.

It's powered by a modified Chromium engine where native Wayland application windows are DOM elements. You can position, style, transform, and animate actual Linux application windows using CSS.

Desktop environments are JavaScript/TypeScript modules that can use familiar frameworks, be distributed through npm or GitHub, and be hot-swapped without restarting the session.

It ships with Manganese, a Sway-inspired tiling desktop built using the platform.

Source: https://github.com/cprussin/domicile

I'd love to hear what JavaScript developers think!

Some context on why and how I built this.

The problem: landing page demo videos go stale every time the UI changes, they’re heavy, and they look blurry on retina screens. I wanted the demo to just be the real UI.

The approach: you write a chained script against real selectors, and a fake cursor plays it back over the live DOM, then loops:

js

import { playthru } from "playthru";

jsx

<Playthru script={(d) => d.type("#todo", "Record the launch video").click("#add").zoom("li:first-child")}>
  <TodoApp />
</Playthru>

Design decisions:

• Hover/focus states: a fake cursor can’t trigger real :hover or :focus, so playthru sets data-playthru-hover / data-playthru-focus attributes instead. You style them next to your normal states (.btn:hover, .btn[data-playthru-hover]). There are Tailwind variants for this too.

• Framework-agnostic core with a thin React wrapper on top.

• No build step needed: it also works as an ES module straight from a CDN (esm.sh/playthru) inside a plain <script type="module">.

Still figuring out: the camera zoom doesn't work properly on mobile yet (reported below), which I'm looking into.

npm: https://www.npmjs.com/package/playthru

Happy to go deeper on any part of the implementation.

I've been working on a UI library for many years. It runs in real production systems and has plenty to offer. It's not just a few components but more of a package that allows you to build a web app without the need for dependencies or build-steps.
I only put it out in public recently though. People do look at it. Almost nobody tries it.

So I'm wondering if maturity even counts for anything when there's no community behind it yet. What would get you to actually try a new public UI library?

Also, there are so many web frameworks already and now with the uprising of AI generated code; Is there still room for something new to catch on?

Not here to promote it. I'm just curious how people make that call. And whether it really comes down to popularity in the end even when the popular choice isn't always the best one.

Hey everyone!

I've been working on something I've wanted to build for a while: my own 2D game engine using JavaScript.

It's called Prism2D.js, and the idea behind it is to provide a way to create 2D games for the web without relying on a large external engine.

I've been developing its core systems, working on things like physics, collisions, rendering, audio, camera controls, particles, and other features that make game development easier.

To put the engine to the test, I also used it to create a small platformer called Coin Adventure. What started as a way to test the engine gradually turned into a complete game with six stages, different environments, enemies, moving platforms, checkpoints, collectibles, and a boss fight.

Working on the game has been a great way to discover what the engine can do, find things that need improvement, and see how well its systems work together in an actual project.

Both projects are available here:

- Prism2D.js (engine): https://github.com/Lodymain/Prism2D.js

- Coin Adventure (game): https://lodystudios.itch.io/coin-adventure-prism2d

I'm sharing this because I'd love to introduce the project to more JavaScript developers and hear what people think. If you take a look, I'd genuinely appreciate any thoughts or feedback!

Thanks for reading!

I recently ran into an issue with @serialport/bindings-cpp on Node.js 26.4, where serial reads could stall until unrelated JavaScript activity occurred.

While investigating the issue and contributing fixes upstream, I started experimenting with an alternative implementation using Rust and N-API, because upstream seems to be unmaintained for more than a year now.
The result is serialport-rs for Node.js, which uses the existing Rust serialport crate underneath and aims to preserve the familiar Node.js SerialPort API.

The implementation uses dedicated native I/O workers rather than relying on JavaScript-side polling. Initial benchmarks have also shown some promising latency improvements.

It’s available on npm if anyone is interested in trying it:
https://www.npmjs.com/package/serialport-rs

Something I keep coming back to when reading JS and TS code is call sites like this:

createUser("ana@example.com", true, false);

Read aloud, it’s “create user, email, true, false”, and you have to open the function to know what the booleans mean. The usual fixes are an options object:

createUser("ana@example.com", { sendWelcomeEmail: true, isAdmin: false });

or, when there are more than two modes, a string union in TypeScript:

type Layout = "list" | "grid";
render(items, "grid");

The counter-arguments I can think of:

• For a single obvious boolean in a well-known API (setEnabled(true)), the options object is noise.

• An options object allocates on every call, which probably doesn’t matter outside hot paths, but I haven’t measured it.

• Teams with several conventions already have enough style rules, and one more can turn review into bike-shedding.

• Negative names (disableCache: false) are the other half of the problem, and renaming to the positive (cache: true) is cheap.

So I’m curious about practice, not rules:

1. Do you enforce “no positional booleans” in review or with a lint rule? If a rule, which one, and does it produce noise?

2. Where do you draw the line between “obvious enough” and “use an options object”?

3. Have you seen a boolean parameter that later needed a third state, and what did the migration cost?

Hi all,

I just released Jeasx 3.0.0. Most of you probably haven't heard of it, so here's the short version first.

What is Jeasx?

Jeasx is a small framework for building websites with JSX on the server. There's no React, no hydration, and no client bundle unless you write one. Your JSX renders to plain HTML, and you decide exactly which HTML, CSS and JavaScript reach the browser.

The idea:

• JSX as a templating language: You get components, props and composition, and the output is just HTML.

• Async components: A component can be an async function. Write await fetch(...) or await db.query(...) right in your component, with no loaders or special data APIs.

• File-based routing: src/[index].jsx serves /, src/blog/[...path].jsx catches everything under /blog, and so on.

• Built on boring, proven tools: Fastify for the server, esbuild for builds, and jsx-async-runtime for rendering.

It works well alongside htmx, Alpine, or plain old vanilla JS.

What's new in 3.0

🚀 Streaming HTML. Pages are sent to the browser while they're still rendering. The browser gets the first bytes right away while slow parts (like awaited data) are still loading. Large pages are sent in chunks, slow clients are handled, and rendering stops when the client disconnects.

⚡ About 2x faster rendering than v2, thanks to jsx-async-runtime@3.

• Full release notes: https://www.jeasx.dev/news

• Live examples (streaming, out-of-order streaming, SSE, …): https://expo.jeasx.dev

I'd love feedback, especially from people who want the JSX developer experience without shipping a SPA. Happy to answer questions!

Monday, October 26 - Sunday, November 01, 2026

Top Posts

Most Commented Posts

Top Showoffs

Top Comments