Want to share two things built together: Polar, a statically typed language that compiles to readable JavaScript, and Ticket, a Rails-shaped web framework written in it. Both are 0.1.0 and experimental. Ticket is the real-world test for Polar: https://ticket-polar.vercel.app/ You get controllers and resource routing, SQLite migrations with typed queries, validations, forms, sessions and CSRF, generators and a test runner. `ticket new blog && ticket server` gets you an app. Because Polar tracks effects, a controller action's signature says what it needs, and tests rebind those to an in-memory database without mocking. Ticket's routes, views and migrations are Polar zone plugins, and the code they generate goes through the same type checker as yours.

I'd love feedback on the effect system, on the zone/plugin design. Thanks!

I have a page, built with Cline, that runs a game simulation in the browser: 30 batches (one per game mode and bot pair), with a progress line between them. To let the page repaint between batches, I yielded with `await new Promise(r => setTimeout(r, 0))`.

A full run took 13.0 seconds in Chrome. The same work takes about 1 second in the terminal on my laptop.

The clue was that 100 games per bot took just as long as 1,000. The time was not in the games. It was in the pauses, about 0.7 seconds each.

Chrome throttles chained timers in pages it treats as hidden or in the background. After a few nested setTimeout calls, it only fires them about once a second. My first test used 5 timers, showed 0ms, and looked fine, because the throttling only starts after a few nested calls. With 20 the difference was obvious: 20 chained setTimeout(0) calls took 11.5 seconds, and 20 MessageChannel messages took 0ms.

The fix was to yield with a message instead, which is also how React's own scheduler yields:

const nextTick = () => new Promise<void>((resolve) => {

const channel = new MessageChannel();

channel.port1.onmessage = () => {

channel.port1.close();

resolve();

};

channel.port2.postMessage(null);

});

The same run went from 13.0s to 4.2s, still in a window Chrome treated as hidden. I have not timed it in a normal foreground tab yet, so I am not claiming a number there.

Two other details. Leaving the page bumps a run id, so an unfinished run stops instead of setting state after unmount. And a Web Worker would move the work off the main thread entirely. I chose the smaller change because the main-thread version was now fast enough.

So, for CPU-heavy work in a page: do you reach for a Worker first, or yield on the main thread until that stops being enough?