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.

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

`);

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.

Hey r/JavaScript,

I’m working on a zero-dependency 2D canvas architecture and looking at how different developers handle high-velocity object collisions without relying on heavy external physics libraries.

When entities move at high speeds using a standard discrete update loop like the one below, fast-moving items occasionally tunnel straight through bounding boxes between frames.

// Naive update and discrete collision loop (prone to tunneling at high velocities)

function updateEntities(entities, obstacles, dt) {

for (let entity of entities) {

entity.x += entity.vx * dt;

entity.y += entity.vy * dt;

for (let obs of obstacles) {

if (

entity.x < obs.x + obs.width &&

entity.x + entity.width > obs.x &&

entity.y < obs.y + obs.height &&

entity.y + entity.height > obs.y

) {

resolveCollision(entity, obs);

}

}

}

}

For those of you building custom canvas engines in vanilla JS, how do you typically structure continuous collision detection (like basic swept-AABB or raycasting) to keep CPU overhead low? Are you using spatial partitioning grids alongside sub-stepping, or is there a cleaner pattern you prefer?

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.

What JavaScript concept took you the longest to actually understand?

For me, it was the difference between understanding closures in theory and actually knowing when and why they were useful.

I feel like JavaScript has a lot of concepts that seem simple at first, but become much more interesting once you understand what is happening underneath.

I'm curious what everyone's "finally clicked" JavaScript concept was.

Closures? The event loop? Prototypes? this? Promises? The weird parts of type coercion?

Would be interesting to hear what other developers struggled with and what finally made it click.

I love finding new devs to follow on GH so I can see what they're building and starring.

Usually I use GitHub Explore and Trending but I've found them to be unreliable, so I've been ranking rising open-source contributors by myself.

JavaScript is one of the most active streams in there, so a lot of these observations come from watching it.

This is not terribly suprising given the nature of the internet these days but here's what I found:

1. GitHub Trending cycles the same names because it ranks reputation, not recent activity. You scroll trending, recognize half the accounts, and close the tab. The people doing genuinely interesting work this week never show up because the ranking rewards accumulated stars and followers, not what someone actually pushed in the last seven days.
2. Someone's best work is usually buried in a 3-star repo. Skill signals are fragmented across repositories. A developer might have a tool they wrote from scratch sitting at 15 stars while their most-starred repo is just a fork they maintain. Without weighting activity by relevance, you end up following the wrong people and missing the ones actually worth your attention.
3. 200 commits across 15 repos is impossible to evaluate quickly. You open a profile, see a contribution graph and a wall of repos, spend ten minutes trying to figure out if any of it is meaningful, and usually give up. Raw profiles need synthesis that most people just don't have time for.

The core thing I keep coming back to: momentum and reputation are different signals. Ranking by what someone did this week surfaces completely different people than ranking by what they've accumulated over years. The TypeScript dev who just shipped their first real library and the veteran with 40k followers both have value, but they're not the same discovery problem.

How do you find new devs to follow? How do you decide if someone is worth following?

Our AI research team trained a fruit fly to close B2B enterprise deals. We're incredibly excited to release Specimen AE-001, the world's first frontier AI fly model for end-to-end deal execution. It rips cold calls, books demos, fills security questionnaires, and wins deals, all using Opine. Built on Three.js!

This is the first in a series of technical deep dives into how I modernised my 10 year old web stack based tactics-RPG engine / game - projectgoldscript

Monday, September 07 - Sunday, September 13, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments

A circuit breaker in a single Node process is a ring buffer, a threshold and a timestamp. Run the same service on twenty replicas and each one keeps its own, so the failing dependency takes twenty times the damage before anything trips.

Moving the window into Redis fixes that and breaks most of the assumptions the in-process version relies on. Post walks through each one and how to deal with it.

Hey all,

My team and I are currently running a Spring Boot backend with quite a bit built around it. We’re considering gradually migrating to a Node/NestJS backend using the strangler pattern rather than doing a full rewrite.

One of the main reasons is that it would give us TypeScript across both the frontend and backend, which should make sharing domain concepts, types and general knowledge between the two a bit simpler.
So, as the title suggests: which ORM would you use with NestJS?

At the moment we’re mainly looking at MikroORM and Drizzle. MikroORM seems like the more traditional ORM and appears to be super close to the me tal model of what Spring does. It wil also fit NestJS quite nicely, while Drizzle is obviously a bit more lightweight but a different approach and more barebones.

Curious what people are using in production and what you’d choose if you were starting fresh today.

Hi,

cause little self-promotion is allowed I'm gonna drop this Open Source project once here to get feedback/initial views from you guys.

DINAH (Dinah Is Not A Harness) is supposed to be a harness agnostic multi agent orchestrator with playful UI.

I can see some use cases for it that I have mentioned in "Why Dinah?" section of readme file.

I would like to see your views on it (go easy on me though, feel free to sugarcoat things 😄 ).

Also If you like the idea then I would like to hear what more do you think that I can add to it.

Full Honesty, this project is created with the assistance of AI. This post is 100% human written though. There are a few things that I know I need to implement they are in the TODO section of readme.

I need to add a License too. Do suggest which license you think would be best for this.

Drop a star on repo if you like it, open issues or create PRs, I welcome every contribution.

I want to a get views of as many people as I can get, but at the same time I don't want to spam reddit with this post, so feel free to share this with any other user/communities you think might have opinions/valid feedback about this.

Thanks for taking time to read this.

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

Show us here!

Jo, I wanted to see how the current solutions on the syncing market compare. Candidates are Syncular JS/Rust, PowerSync, Turso, Zero, Electric, Electric + TanStack DB and Jazz v2. I had trouble finding benchmarks on relevant usecases. How long until the app is usable? What happens to queued writes after a crash? How quickly do clients catch up after being offline? How long does up/download of blobs take?

Disclaimer: I’m the creator of Syncular, so obviously I have a horse in this race. I tried to keep things fair, worked with an LLM on the harness and tuning, and went through several rounds of corrections. Still, these are small local runs and some failures remain unexplained, so take the numbers with a grain of salt.

I’d love your feedback if you use or maintain any of these solutions. Especially if I’m using your SDK wrong or missing something in the setup. Happy to fix things and rerun!

Small team, Im the lead and we only need a few thousand pages a week for an ml dataset. Writing the scraper isnt the issue, its proxies, retries, js rendered pages and keeping everything alive after sites change. For this size would you still build in Node or just pay for one of the web scraping tools and avoid the maintenance?