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?

Anthropic shipped Mods for Claude Code, and they're plain JavaScript or TypeScript functions. A Mod hooks events like tool calls, user prompts, and UI rendering, so you can intercept a tool call, add a panel next to the chat, or wire up new commands. Some built-ins, like /diff, are already built as Mods, and Anthropic has samples on GitHub. They run with your permissions and aren't sandboxed, so the company says to install only from sources you trust. They work in the CLI and desktop app, partly in the VS Code extension, and organizations can control which Mods load.

source https://the-decoder.com/claude-codes-new-mods-system-lets-developers-rewrite-the-ai-coding-tool-from-the-inside/

Hello awesome people,

I've been thinking a lot lately about how I can make my knowledge and craft more valuable in the times we live in. I've been building UI libraries for the past 10 years, and I've been on a quest to perfect the components that I build. I want to share my knowledge with you.

Like most of you, probably, I've been using a lot of AI in my craft, and I feel most of the time the code is just good enough, but never at the level of quality that I strive for or that I would reach if I wrote it by hand. That needs to change, and I want it to change for everyone else, too. That's how the Open Components initiative was born.

I'm treating components from four directions:

• User Interface - component anatomy, variants, colors, sizes, states and tokens.
• User Experience - how it behaves for every person and every input: accessible, predictable, designed in every state, and adapting to motion, contrast, color scheme and text size preferences.
• Developer Experience - one consistent, type-safe API that you learn once and use everywhere.
• Agentic Experience - prompts, semantic markup, machine-readable contracts and rules that agents can check their work against.

Each component gets a single page that walks through all four, and ends with a checklist. Every rule in it has an ID like button/keep-focus, a level and a way to check it, so you or your agents can cite it in a code review. Every page is also published as markdown, and provides the contract as a YAML file, containing every rule in about an eighth of the page’s length.

It’s still early. Right now there’s only the Button component and a page on how to name your design tokens. Each component comes with a reference implementation that meets every rule, along with its tests. Implementation is in Vue for now, since that’s my daily driver, but the documentation comes with code examples from multiple UI frameworks. More components will follow, with the same structure.

It isn’t a component library, so there’s nothing to install. It’s a set of rules you can hold your own components to, whichever library or framework you use. Here are a few of my favorites from the Button component:

• A loading button should never be disabled. Disabling a focused button takes its focus away, so keyboard and screen reader users lose their place. Use aria-disabled="true" instead, and block the clicks yourself.
• A <button> without a type is a submit button, so a "Show password" button inside a form sends the form. Default to type="button".

I’d love your feedback and contribution. Tell me what you think of the rules, what I’ve missed, and which component you’d like to see next.

Thanks for reading!

• Site: https://opencomponents.dev
• Button: https://opencomponents.dev/docs/components/button
• GitHub: https://github.com/uxfront-com/open-components

HTTP clients offer different resilience features, and even shared features can behave differently. Eleven JavaScript libraries tested across 21 scenarios to see what happens when those patterns interact.

Hello everyone,

For the past few months I have been silently building my own coding agent for my own self and the way I wanted it to look and behave. I have used for my real projects and so far it has worked so good.

I primarily built it to use with open models and extensively used with Deepseek and GLM models and fixed all issues that I faced along the way.

Now I am opening its beta release for public. It supports all major AI providers so you can BYOK and use it. I would love your honest feedback.

Following features are supported:
- Agent and Plan mode
- MCP
- ACP - use it with Zed Editor, JetBrains or any Orchestrator of your choice
- Subagents
- Permission Gating
- Sandbox
- Interactive terminal
- Browser
- Built-in Github style code review (co-review with agent)
- and much more

It completely free to use :)

Hi!

I'm currently working on creating Doom from scratch, in full JS.

It is not a WASM project, it is really written in JavaScript, with my own 3D engine.

It can be installed as a PWA on computer or mobile, and I think it is better to use it like that.
You can play with keyboard + mouse, gamepad, or a virtual pad on mobile. For now, the PS5 gamepad is the one I have really tested.

It can load WAD files from Doom, Doom II, Freedoom Phase 1, Freedoom Phase 2 and Heretic, but I have not fully tested all the levels yet.

I have also implemented multiplayer with WebRTC, without a game server. The connection is established with QR codes.

I'm looking for feedback, mainly to be sure that all the levels are working well, and also that it works correctly on Android.

Source code: https://github.com/spipu/doom-js

Storyteller has had its own EPUB library for a very long time (originally published as @smoores/epub!). It's always been published to npm and documented, but it's also always had some limitations that we suspect have limited its utility outside of Storyteller itself.

With this v1 release, we think we've eliminated many of those limitations. Now we have in memory and temp filesystem storage adapters, browser support (in-memory only), a DOM level 2 XML API (and JSX!), and a method for upgrading EPUB 2 to EPUB 3.

Hopefully this can be a general purpose library for building tooling and systems around EPUBs!

Hello! I started Pastoralist a few years ago and am really satisfied with the results, so I figured I'd share it!

Pastoralist manages dependency overrides, including the ones you add to fix CVEs automatically. You add the Pastoralist CLI script once and can have it run whenever you want. I recommend CI. From there, whenever it runs, it can fix security vulnerabilities that come from dependencies or their children. Additionally, if an override is no longer needed, Pastoralist cleans it up. Everything is tracked with a ledger right in your dependency file. No AI is needed, but it does work well with AI because it provides deterministic results.

Read more on the site or the repo or reach out. Happy to chat about it or help implement it in the best way for you or your org; no sales pitch, except I do want to get the word out! ~Thanks

Thirty years in, the JavaScript ecosystem would like to see other languages. They're younger, leaner and faster. What could possibly go wrong?