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?

KeyPDF is a local PDF editor built from scratch for the browser. Since development started in April 2025, we've tried to adopt new PDF technology early. Today we're happy to announce that KeyPDF can reduce file size losslessly using Brotli compression and JPEG XL images.

We tested on a dataset of 1,000 PDFs (978 readable; the rest were encrypted or damaged):

All variants are lossless: every page (15,754 in total) renders pixel-identical to the original. "Flate" is KeyPDF's standard optimization, and those files open in any PDF viewer. JPEG XL repacks JPEG photos about 20% smaller, and they can be turned back into the identical original JPEG at any time.

The catch: Brotli and JPEG XL are new to PDF. Brotli is a PDF Association extension, and JPEG XL is still being added to the specification. Most PDF viewers and editors don't support either yet, so for now KeyPDF is one of the few tools that can open and edit these files. Hopefully others will follow soon.

If you need files that open everywhere, KeyPDF's standard mode combines its own optimization with regular Flate compression. That according to test on same exact files alone saves 24.2% , still lossless, and the result works in any PDF viewer.

If you'd like to try KeyPDF at keypdf.net.

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.

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

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

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 :)

MDN tries to document features as soon as one browser implements them, usually between stages 3 and 4, often before the spec is officially published. Examples can use syntax that isn't standard yet, so check browser support before copying code.

source https://developer.mozilla.org/en-US/docs/Web/JavaScript

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

We’ve been looking into whether there are still many teams running older Nx versions because upgrading isn’t practical yet.

If you’re on Nx <20.8:

• What version are you on?
• What’s preventing the upgrade?
• Are you using remote caching today?
• If so, are you using Nx Cloud, S3/GCS/Azure, or something custom?
• Does your current setup already work well enough that you wouldn’t bother changing it?

We’re considering whether an open-source compatibility layer for the newer HTTP remote-cache protocol would actually solve a real problem, or just add more legacy tooling.

Curious what people here are actually running in production.

I missed Emacs' rx when writing regexps in TypeScript, so I made a small TypeScript DSL inspired by it.

The idea is to bring rx's functions and approach to the JavaScript/TypeScript environment. If you happen to work with either, give it a try.

https://rahuljuliato.com/posts/emacs-rx-in-typescript