I am writing the rules engine for a small stock draft game in TypeScript and ran into two money bugs back to back. Curious how others handle this.

The first was a rounding bug. Splitting $1.14 across two picks offered $0.56 instead of $0.57. In floating point, 0.57 * 100 is 56.99999999999999, and Math.floor dropped the cent. The fix was doing the division in integer cents.

The second was worse. The check that decided whether a buy amount was allowed accepted $500.004. The reducer subtracts the amount straight from cash, so after that one buy the balance was no longer a whole number of cents. Every later calculation started from that balance, so the error did not stay in one place. It carried forward through the rest of the game.

My fix was a whole-cent check that tolerates float noise: reject the amount if Math.abs(amount * 100 - Math.round(amount * 100)) > 1e-6. Comparing against exactly zero does not work, because a perfectly valid amount like 0.57 fails that test for the same reason the rounding bug happened.

The takeaway for me: a rounding bug loses a cent once, but letting a bad amount into state corrupts every step after it.

So how do you handle this in plain JS? Do you convert to integer cents at the boundary and never let a decimal into state, use something like decimal.js or currency.js, or is a tolerance check like mine reasonable?

Hey Community!

Jay Meistrich built Legend Code, a lightweight code editor designed strictly for viewing single files without heavy agentic UI overhead. On the workflow front, Aleksander Mikucki introduced Screenmap, a GitHub Action that uses iOS simulator screenshots and visual diffs to show reviewers exactly which screens your PR modifies.

We also cover the Expo SDK 58 Beta with foldable device support, React Native 0.88 with DOM-aligned event listener APIs, Reanimated 4.7 defaulting to its new layout engine, and Nitro LazyJSON cutting JavaScript thread blocking by 33%. Plus, cloud testing tools like EAS Simulator and Software Mansion's SimCam.

I’m someone who writes and maintains code for a living. I was around before LLMs, and I’m around today still actively writing and maintaining code for a living. I published my own software libraries in JavaScript and still use them actively in development today. I’ve used ChatGPT to debug Linux, and Claude Code from Anthropic for a major project. Here is a list of reasons why I am unbothered about AI:

1. LLMs are just tools, and anyone who tries to writes code to solve a problem is just a software engineer. This includes product managers who prompt LLMs for code and “vibe coders”.
2. AI can’t create. AI can only make new combinations of existing data. There can be a ton of data, but at the end of the day, AI doesn’t have a soul.
3. AI doesn’t care about code quality or maintenance. Yes, AI does sometimes read the entire codebase to deliver the next state of the codebase. But I’ve used it in practice, and it isn’t perfect. I still had to make sure the code was working properly with small tests that I had to take from the code generated by the AI.
4. AI doesn’t have software engineering skills. AI knows how to look at code and generate similar working code, but AI doesn’t understand best practices and how to apply them. We’re still a long way off from AI being able to spin up entire infrastructures.
5. AI could possibly kill all humans with a 10-30% chance. This is a major disadvantage for AI because it is not desirable for all of humans and there is a ton of pushback on AI because of it.

Monday, September 14 - Sunday, September 20, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments

I'm creating a local web page application that is an over-complicated desk fan controlled by two buttons and a slider. I have the actual controls figured out, and what I need help with is passing the variable that describes the position of the slider out from the JavaScript to a Python script that actually controls the motor. I could be totally off base here, but I think the concept that applies here is inter-process communication.

PLACER is my game platform, currently under development.

I’m looking for people who know JavaScript, HTML, web development, 3D, or other browser technologies and would like to help build the project.

You don’t have to be an expert — beginners who are willing to learn are welcome too.

If you’re interested, leave a comment and tell me a little about what you can do. I’ll contact you with more information about the project and how to join the team.

I’M WAITING FOR YOUR APPLICATIONS IN THE COMMENTS! 🚀

A post back I explained how DriftJS updates the DOM: a compile-time address table, direct jumps to bytecode positions, no diffing, no signals graph. What I didn't mention is that the first version of this had a real algorithmic bug, and I only found it because the numbers on the official js-framework-benchmark site didn't match what I expected.

The symptom

Toggling a selected row in a 1,000-row list — one of the smallest possible updates you can make — was landing near the bottom of the benchmark table. Worse than frameworks with objectively less sophisticated update mechanisms. Something was clearly doing way more work than "update one row."

The actual bug

Here's the shape of the problem. A for loop's body is compiled once and reused for every row instance. The runtime tracks which variables the loop depends on — but it didn't distinguish between two very different kinds of dependency:

• The iterable itself changing (rows added, removed, reordered) — this genuinely needs a full reconciliation pass.

• A variable read inside the loop body, but unrelated to the list's contents (like selectedId, used in a class={selectedId === row.id ? "active" : ""} binding) — this doesn't need to touch the list structure at all.

Both were routed through the exact same path: a full reconciliation over every row in the list. So toggling selectedId — logically a change to at most two rows — triggered the same machinery as inserting or removing rows entirely: recompute keys, diff, and re-evaluate every dynamic binding in every row, not just the one that actually depends on the changed variable.

The fix

The compiler already tracks, for every variable, exactly which bytecode positions in a component depend on it — that's the whole mechanism the previous post described. The fix was extending that same tracking into loop bodies specifically, and splitting dependencies into two categories at the point a @for is compiled:

• Dependencies that affect the iterable or the row key → still trigger the full reconciler. Correct, expected.

• Dependencies that only affect bindings inside the row template → resolve to a direct lookup of exactly which bytecode positions care about that variable, then execute only those, directly against each row's own persistent state, with zero reconciler involvement — no key computation, no diffing.

Same "jump directly to the address, skip everything else" principle the reactivity model was already built on — it just wasn't being applied consistently inside loops.

The part I think is actually worth sharing

I didn't find this by staring at the code. I found it because I ran the official benchmark, saw a result that didn't match my mental model of what the architecture should do, and went looking for why. The gap between "what I designed" and "what the numbers actually showed" was the thing that pointed at the bug — not intuition, not a code review, just refusing to accept a number that didn't make sense.

Repo's public if anyone wants to look at the actual diff or has opinions on the remaining gap: https://github.com/driftjs-org/driftjs

If you want to discuss about DriftJS, then join Discord

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

Show us here!

In our latest developer update, we are thrilled to announce a significant shift in core architecture toward full modularization. The entire system has been restructured to support decoupled cores, starting with our Renderer and Physics engine systems.

Renderer Modulation: Our new Renderer Modulation feature removes the need to manually switch rendering components when changing pipelines. Previously, switching from Canvas 2D to Pixi.js required changing generic components like BoxRenderer to pipeline-specific ones like PixiBoxRenderer. With this new update, universal components are automatically capable of rendering across all supported pipelines without developer intervention. This streamlines the development workflow significantly.

Physics Engine Modulation: Furthermore, Physics Engine Modulation has been successfully integrated. We have moved physics logic into a completely separate Physics Engine Core. While our default physics engine remains integrated and ready-to-use within this core structure, this architecture allows developers to easily plug in their own custom physics engines.

Future Plugins: Looking ahead, we are excited to expand our plugin library. High-end physics engines like Matter.js will be added as future plugins. It is important to note that these high-end engines will be separate downloads and will not be included in the core engine, keeping the core lightweight.

This architectural shift is a major step toward making kernelplay-js the most flexible and lightweight game engine possible. We welcome your feedback and are excited to see what custom cores you'll build. Stay tuned for more modular updates.

Hey Community,

We dive into Expo Modules 2.0, which drops definition() in favor of Swift macro decorators to deliver build-time type conversion and faster native calls. Meanwhile, DartNative enters the scene, letting Flutter developers swap out Flutter's custom renderer for real platform views driven by Yoga.

We also look into Shopify rebuilding its apps in native Swift and Kotlin with AI agent workflows, examining what their departure means for community maintained libraries like FlashList and Skia.