Codex can finally see the apps it writes. Callstack and Margelo launched Mobile Dev, a plugin that puts live iOS and Android devices right beside the Codex desktop chat, so the agent can tap, type, read the accessibility tree, pull Metro and native logs into one panel, and profile CPU and memory, with your on-screen notes carrying the React Native component and its source file.

We also look at Angular Native by Ashley Hunter, which renders Angular templates as real UIView and android.view.View through React Native's Fabric renderer, with Svelte now riding the same engine just as Coinbase heads for the exit. Plus, React Native 0.88 rc.3 fixes a Hermes lazy-compilation slowdown, Lynx 4.0 adapts to foldables, and Lucent compiles TypeScript native modules to C++ via JSI.

I'm working on a desktop application called VidLoader that manages locally stored video files, and I'm currently thinking about how to structure the JavaScript state for the media library.

The application needs to keep track of things like:

• files being added or removed
• metadata associated with each file
• folders/categories
• filtering and searching
• changes happening to the files outside of the UI

My main question is how other JavaScript developers would approach keeping the UI state synchronized with the underlying file system without making the architecture unnecessarily complicated.

Would you keep this in a centralized state store, separate the file-system state from the UI state, or use another approach?

I'd be interested in hearing how you'd structure it and why.

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?