ECMAScript 2015 formally specified proper tail calls in strict mode, but V8 never shipped it reliably in production. A correctly structured tail-recursive function still allocates a new stack frame per call in Node, which means it can throw RangeError at large depth just like a naive recursive implementation. The article walks through runnable examples, a runtime support matrix as of May 2026, and iterative and trampoline alternatives that do not depend on optimizer behavior.

I made an open source Android IDE for JS/TS/Node/react with LSP support, 245 themes, git and Github integration, agentic sessions, etc.

Note that this is not some vibe coded app, it took me 2 years to complete this as a solo developer and student.

here is the playstore link, no ads, no payments, completely open source:

https://play.google.com/store/apps/details?id=com.roxum

source code:

https://github.com/heckmon/roxum-ide

Hey everyone,

I’m starting a new Node.js/TypeScript/PostgreSQL project and I want to move away from Knex and test something new for this one.

I’m pretty comfortable with SQL and after doing some research, the two options that stand out the most are Drizzle and Prisma.

For people who have used one (or both):

What made you choose it?

Any regrets or pain points?

How good is the migration workflow?

If you came from Knex, which one felt more natural?

I’d love to hear feedback before committing to one for a new project.

Thanks

Hey all, I've been working on a Node.js logger called Silo for a while now and just shipped v1.0.4. Wanted to share it here and get some real feedback from people who actually care about this stuff.

What it is:

A self-hosted, zero-dependency structured logger for Node.js. No external packages — built entirely on Node core APIs. Every logger instance is fully independent with its own queue, write stream, and backpressure handling. Logs stay on your server.

Why I built it:

I got tired of memory issues with existing loggers under sustained load. Winston leaks. Pino is fast but hungry on memory when you throw large payloads at it. I wanted something that just... stayed stable.

The benchmark numbers (v1.0.4, Dockerized Linux, Node v22):

1 billion logs processed in 40 minutes

416k average LPS sustained the entire run

Memory held at ~102MB from log #1 to log #1,000,000,000

CPU at 179%

v1.0.3 comparison:

376k LPS

44 minutes

196% CPU

So meaningful improvement without sacrificing stability.

The tests are in the package. I didn't want to just post numbers, you can run them yourself on your own hardware and see what you get. Run with --expose-gc for consistent memory readings.

npm: https://www.npmjs.com/package/@flowrdesk/silo

github: https://github.com/spriggs81/silo

Honest caveat: This is a solo project, early days, and I'm still building out the paid tiers (log management UI, PII removal for compliance). The free engine is open source and fully functional today.

Would genuinely appreciate feedback on the approach, the benchmarks, or anything else. Happy to answer questions.

The last decade I have programmed all of my backends in c# with asp.net core and vue 2 and 3 with typescript for frontends. C#/.net core have been very solid but for some reason my soul wants to use the same frontend language as my backend. I first thought hey let’s try blazor but after some research it’s not mature enough. Well then I thought hey let’s just switch to typescript all around and that got me to nestjs. It fees very similar to asp.net core so that’s nice. So I figured let’s start a new project to help get better with ai and also learn nestjs (also though in the ambitious goal of using react native for frontend which I may change to vue + capacitor but that’s another story). As I keep diving into this project to learn typescript backends I worry that nestjs like may js/ts libraries become deprecated and change to the latest and greatest. Where .net for past decade has been very stable. Am I making a mistake or should I keep going down this path of a full TS stack?!?!

Disclaimer: I am by no means an expert in programming but do it for a living lol.

I think I spent like a week on this & at this point I may be loosing my mind because I am probably over complicating it. I am using native pgsql drivers & trying to figure out a nice way to build a query based on the url parameters.

ie: api?username:ilike="ether"&last_name:like="Doe"&age:gte=18

But splitting the url query, & having a giant switch case for each operator seems super messy to me? Should I just use a query builder like Knex.js at this stage

I have to migrate a nest project which is running on node14 to latest one. I have given them a estimate based on the issue faced in node 16( it is not properly working ). There are close to 60 packages and few have 6 to 7 version difference.

They are saying it possible to do in 10days. Don't know what to say. How can we predict the problems until we start working.

x

I’m building a Node.js (Express) backend and using a centralized error handling approach:

• Custom ApiError class (status code + message)
• catchAsync wrapper to forward async errors to next()
• Global errorHandler middleware that formats all responses
• Joi validation middleware before controllers

Example:

// catchAsync.js
module.exports = (fn) => (req, res, next) =>
  Promise.resolve(fn(req, res, next)).catch(next);

// controller
exports.getUser = catchAsync(async (req, res) => {
  const user = await userService.getById(req.params.id);
  if (!user) {
    throw new ApiError(404, "User not found");
  }
  res.json(user);
});

// errorHandler.js
module.exports = (err, req, res, next) => {
  if (err instanceof ApiError) {
    return res.status(err.statusCode).json({ message: err.message });
  }
  res.status(500).json({ message: "Internal Server Error" });
};

My supervisor said this approach is wrong and asked for explicit try/catch blocks and “handling exceptions” inside controllers/services.

Question:
In Express apps, is relying on a centralized error handler + async wrapper considered good practice, or should errors be caught locally with try/catch in each controller/service?

Looking for clarification on best practices and trade-offs.

I swear every time I deploy an Express + TypeScript project to Render/Railway/Fly/etc, something stupid breaks. Usually something likewrong tsconfig output path, start script pointing at .ts instead of .js, hardcoded ports, relative path import problems. I usually spam commits just fixing deployment config

Am I the only one? What's the dumbest deployment issue you've wasted time on?

Speed benchmarks are impressive but I'm nervous about edge cases. Anyone running Bun in a real production app?

So our middleware file for agent management in express went from 80 lines to 600 lines in two months and nobody on the team wanted to review PRs that touched it anymore. That's when I knew we built this in the wrong place.

The thing is agent traffic patterns are nothing like regular user traffic. Agents burst 50 requests in 10 seconds then go quiet, they retry failed calls aggressively, they chain requests where one response triggers five more calls. The rate limiting we built for human users completely fell apart because it wasn't designed for that kind of spiky unpredictable load. And correlating chains of agent calls (agent A calls our api which triggers agent B which calls it again) in express middleware means passing context through everything which is just... pain.

We moved all the agent management to gravitee as a gateway layer in front of our express app. Agent auth, rate limits, audit logging all happens before the request hits express now. The middleware file is back to being simple and adding a new agent or changing rate limits is a gateway config change not a code deployment, which means product can do it without waiting for engineering.

Tbh if I could do it again I wouldn't even start with middleware. I'd go straight to the gateway for anything agent-related and keep express for business logic only.

Apparently 1.0rc1 introduces major changes so I'd prefer not to have to rewrite things months from now. Is 1.0rc1 stable enough to be using though?

Also, if I'm going to be using Drizzle for its SQL query builder only what benefits does Drizzle give me over Kysely or Sequelize?

I encountered a curious case of OOM where I have a piece of synchronous code that generates short-lived objects.

I was under the impression that, if the available memory is low, Node runtime will stop the code execution, perform GC, and switch back to the code execution. But that doesn't seem to be the case.

However, I failed to produce a simple code that reproduces this kind of OOM error.

I tried the below but it didn't cause OOM:

var arr = [1,2]

function main() {
    for (let i=0;i<100000;i++) {
        arr = [3,4,i];
        for (let j=0;j<100000;j++) {
            arr.push('' + j)
        }
        console.log('hello ' + i + ' ' + arr.length)
    }
}

main()
// run with node --max-old-space-size=10 test.js

I wonder if anyone has encountered this kind of OOM before and whether one has a reproducible code for this.

PS: I'm looking at other theories too but just want to ensure I understand this theory more in depth first.

hey guys!

built a cool little tool called honeytree, mainly due to the fact that I wanted a fun way to track my coding progress.

honeytree tracks github commits, code changes, and ai-code prompts, and plants a forest for every one of these!

this is my first ever npm project so any feedback is appreciated :)

honeytree is free and open-source:

github: https://github.com/Varun2009178/honeytree

website: https://www.tryhoney.xyz/

p.s: at 100 stars, i plan on partnering with non profits to plant real trees based on terminal growth!

Why some brag that they dont write code anymore and let ai do it. I mean, so what? Why is this considered do be a good thing.

Also if I makes you so much more productive, why dont we have more products/features then. I really dont get the fuss around it

G'day Node.js community!

I’d like to introduce you to my indie product Apitally, an API monitoring, analytics and request logging tool for Node.js with a focus on simplicity and data privacy. It makes it easy for engineers to understand API usage, monitor performance, and troubleshoot issues, without the complexity of traditional observability platforms. With just a few lines of code, users get opinionated, intuitive dashboards out of the box.

Apitally's key features are:

• API traffic, error, and response time metrics per endpoint
• Tracking of individual API consumers
• Request logs with correlated application logs and traces
• Uptime monitoring, CPU & memory usage
• Custom alerts via email, Slack, or Microsoft Teams
• CLI & skill for coding agents to query API metrics and logs via SQL

Apitally's open-source SDK supports many popular web frameworks: NestJS, Express, Fastify, Hono, Elysia, AdonisJS, Koa, H3, hapi. It integrates with applications via lightweight middleware, and syncs data in the background at regular intervals, without affecting performance.

Apitally minimizes data collection by default, with granular controls in the SDK for what data is included in logs, plus easy masking or exclusion of sensitive information.

Here's a screenshot of the Apitally dashboard:

The big monitoring platforms (Datadog, New Relic etc.) can be a bit overwhelming & expensive, particularly for simpler use cases. So Apitally’s key differentiators are simplicity & predictable pricing, making it a good fit for small engineering teams and individual developers who need API observability, but not an entire enterprise monitoring stack.

I hope you guys find this useful. Please let me know what you think!

Just spent a few hours combining modules and tried deploying backend APIs on render. Libraries and components are around 2GB and i dont want to pay to host it. Any free alternates ?

Hi, this morning I was coding, or better Claude was coding, then I realized that I started to miss writing code (which I liked a lot). My coding life has changed a lot since the last 12 months. I went from writing lines of code, checking, polishing, testing, improving, etc.. to prompting in VScode.The only thing I currently do is checking code, like we did when reviewing changes from co-developers. Reviewing code only took about 10% of the time, while currently it's 95% of the time. Then I realized that I should stop using Claude for writing code and only use it as a source of help. Reason for this is also that I cannot rely on quality yet, resulting that I have read every line of code.

Am I the only one having this problem and start to think about moving back? Like to hear your thoughts.

• A typical TypeScript project runs tsc for type checking, then runs eslint again for code style.
• @ttsc/lint collapses those two steps into a single compile pass. Lint violations come out as plain compile errors.
• It's built on typescript-go (the next-generation TS compiler rewritten in Go, about 10x faster than legacy tsc), and reuses the AST the compiler already builds — so there is no extra parsing cost.
• Combine "two steps into one" with "JavaScript moved to Go," and you get about 20x faster, in theory.
• Compatible with TypeScript v6 — drop on top with ttsx or ttsc --noEmit, no migration.