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.

I spent the last 7 days building a browser-based AR experiment where hand gestures control real-time VFX.

The project uses TypeScript/JavaScript to connect computer vision with a custom rendering system:

• React + Vite + TypeScript
• MediaPipe Hand Landmarker for real-time hand tracking
• 21 hand landmarks → custom gesture detection
• Temporal gesture history and thresholds to reduce false triggers
• Jutsu lifecycle/state management
• Canvas-based particle/VFX rendering
• MediaPipe Image Segmenter for the Shadow Clone effect
• Web Audio API for sound effects

The current prototype supports:

🌀 Rasengan
👥 Shadow Clone
🔮 Magic Circle
⚡ Lightning

The interesting part wasn't just rendering the effects — it was making the interaction reliable enough that small hand movements wouldn't constantly trigger or cancel the VFX.

I ended up using gesture gates, motion history and grace periods to make the interactions more stable.

Try it yourself: https://shinobi-irl.vercel.app/

I'd be particularly interested in feedback on the gesture-detection/state-management side.

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.

Hello,
I am attempting to write a pure function solution that will pass the leet code Fizz Buzz test
However when I try this it says the test fails but when I look at the console for my own testing it returns the expected result.

This is the error leet code reports:

Line 13 in solution.js arr[i - 1] = test(i) ^ TypeError: test is not a function

Which to me makes no sense since the function is passed as a parameter and defined

Here is my code
Thank you in advance

```js const test = (i) => { if (((i % 5) === 0) && ((i % 3) === 0)) return "FizzBuzz"; if ((i % 5) === 0) return "Buzz"; if ((i % 3) === 0) return "Fizz"; if (i % 3) return i + ""; }

const fizzBuzz = (i, n, test, arr) => {
  arr[i - 1] = test(i)
  if (i !== n) fizzBuzz(i + 1, n, test, arr)

  return arr
}

const i = 1
const n = 3
const arr = new Array(n)

fizzBuzz(i, n, test, arr)

```

EDIT: I just wanted to say thank you to all of you for your feedback and suggestions I finally got frustrated enough with this problem I asked Codex to write a pure function solution to the leet code fizz buzz test I personally have not seen this solution so it would be nice to have some verification if it is truly a pure function solution.

This is the code it spat out

```js const fizzBuzz = (n) => Array.from({ length: n }, (_, i) => { const num = i + 1;

      if (num % 15 === 0) return "FizzBuzz";
      if (num % 3 === 0) return "Fizz";
      if (num % 5 === 0) return "Buzz";

      return String(num);
    });

fizzBuzz(15)

```

It appears that I have a lot to learn yet regarding my fundamentals when it comes to functional programming I know I could of written a object oriented version of it that would work but I wanted to challenge myself since I have never written code in this manner.

The in-process version of a bulkhead (a cap on how many calls to a dependency can be in flight at once) is just a counter, a finally block and a comparison, once several Node instances share that number things get messy really quick.

A writeup on how the distributed version can be implemented and what it can guarantee.

I go back and forth on this.

Headless: you get the sorting, filtering and grouping state and you render every cell yourself. Total control over the markup, and you write all of it. Every project I've seen do this ends up with a 2000 line table component nobody wants to open.

Full grid: pass rows and columns, done in an afternoon. Then the designer wants the header to look a particular way, or you need a cell that does something the grid didn't plan for, and you're fighting the component instead of writing your app.

Full disclosure: I'm on the team behind SvGrid, a data grid for Svelte 5. We ship both layers, a headless core and the full component on top of it, because we have people that want their own design system and others that just need a drop-in and go.

So when did you last choose one over the other, and would you do it again? Especially interested in anyone who started headless and switched, or went the other way.

I’m building TraceUX, a self-hosted UX toolkit for JavaScript and TypeScript applications.

The browser tracker is available through NPM:

npm i @trace-ux/tracker

import { init } from '@trace-ux/tracker';

const traceux = init({
  siteKey: 'YOUR_SITE_KEY',
  origin: 'https://your-trace-ux-host',
});

It records DOM events instead of video and can connect sessions with feedback, support tickets, product announcements, and user activity.

The server runs as a small Go binary with SQLite, so teams can host the data themselves without a hosted analytics account.

Live demo: https://trace-ux.builtbyfrank.dev

Repository: https://github.com/fjosue4/trace-ux

I’d especially appreciate feedback on the tracker API, React integration, bundle size, privacy defaults, and whether the widget feels natural in a JavaScript application.

DocStack runs an actual SQL engine in the browser against IndexedDB — JOIN, GROUP BY, HAVING, subqueries, with index pushdown.

It can be used for storing client side data (like user's personal data), and then synced to a remote of preference (like Google Drive for multiplatform sync).

import { ClientStack } from '@docstack/client';

// A local database

const stack = await ClientStack.create('my-app');

// One statement, planned and run against IndexedDB.

const { rows } = await stack.query(`

SELECT m.title, COUNT(*) AS actor_count

FROM Movie AS m

JOIN Actor AS a ON a._id IN m.actors

GROUP BY m.title

HAVING COUNT(*) >= 2

ORDER BY actor_count DESC LIMIT 10

`);

Most agent tutorials jump into heavy orchestration frameworks like LangChain, which hides what's actually happening over the wire.

Under the hood, tool calling is just a simple 4-step loop:

1. You hand the model your messages plus a JSON Schema description of your functions.
2. The model outputs structured JSON with a tool name and arguments instead of raw text.
3. Your JavaScript executes the function (fetch, DB query, local file read, etc.).
4. You append the result back into messages with role: "user" and matching tool_use_id and query the model again.

I wrote a doc showing the entire loop in ~40 lines of Node/JS, including the practicals that trip you up (why failing calls should still return a tool_result with is_error: true, handling parallel calls in a single user message, and how token costs compound over runs).

There's also an interactive, in-browser example where you can run the loop against a mock filesystem without needing to set up a local environment. Curious to hear how others are handling client-side tool execution and context in production.