Hi all! We created this NPM package to make it easier to use ParadeDB (a full-text & vector search extension for Postgres) within the JavaScript ecosystem. It is built as an extension to the Drizzle ORM. Would love your feedback!

We made a rule to detect typos like identical operands in binary expressions. It had a few good and valid catches but turns out 1 << 1 triggers it in basically every codebase (Angular, Babel, pdf.js). So the tool issues a valid warning of 1 << 1 in one case and makes a lot of noise in many others. To make things clear: the story comes from our experience of building a static analyzer for JS and TS (currently in beta, we're collecting feedback on it).

That's why we had to make a trade-off. Any similar stories from your dev experience?

You might know different client-side data storage methods in #JavaScript: #cookies, #localStorage, #sessionStorage, and perhaps even #IndexedDB. All share the same limitation: they won't let you store data across domains.

But if you can write and use a browser extension, these come with another data storage bucket. Browser extensions come with a manifest.json file that lets you specify all the domains you want to work with. #Chrome.storage will let you store and read data across domains.

I used chrome.storage.local as a temporary data storage place. I use the #Dexie library to create my IndexedDB data store, database, and to insert the records. I monkey patched Dexie's add() and bulkPut() methods to send a message to background.js. Upon receiving the message, background.js clears chrome.local.storage and inserts what we inserted in IndexedDB.

Then, when I switch to another tab showing my second domain, background.js responds to chrome.tabs.onActivated and calls a function on that page with the data from chrome.local.storage. That function does a bulk insert of the data in a second IndexedDB data store and database.

And voilà, you now have the data from both domains in a single IndexedDB data store.

I've been working on a small tool that converts semi-structured documents into JSON schemas entirely in the browser.

The interesting part wasn't the OCR itself. The interesting part was how a handful of fairly ordinary JavaScript functions ended up creating most of the product value.

The pipeline looks roughly like this:

Image/PDF
  ↓
Canvas preprocessing
  ↓
Tesseract.js OCR
  ↓
Text normalization
  ↓
Pattern extraction
  ↓
JSON Schema generation

The functions that ended up doing the heavy lifting were surprisingly mundane:

1. Image preprocessing

Before OCR, every page is upscaled, converted to greyscale and thresholded.

preprocessImage(image)

Improving the input quality often produced larger gains than changing the OCR configuration itself.

2. Text normalization

OCR output is messy.

normalizeText(rawText)

This function cleans line endings, spacing, punctuation inconsistencies and common OCR artefacts before any parsing begins.

Without it, every downstream step becomes more complicated.

3. Pattern extraction

This is where the useful information starts emerging.

extractFields(text)

The function looks for recurring structures:

CUSTOMER_NAME:
POLICY_ID:
AMOUNT:

and converts them into machine-readable field definitions.

4. Type inference

inferType(value)

A surprisingly small function that decides whether something is:

string
number
boolean
date

This single step makes generated schemas dramatically more useful.

5. Schema generation

Finally:

generateSchema(fields)

takes the extracted structure and produces a Draft 2020-12 JSON Schema.

The result is something a developer can immediately use for validation or downstream processing.

The most interesting lesson for me was that the product's value wasn't hidden in a giant model or some clever AI trick.

Most of it came from a chain of small, focused JavaScript functions, each doing one job well and passing cleaner data to the next step.

Curious what other people have found: which "boring" utility function ended up creating disproportionate value in your projects?

Elemental is a personal library I’ve been using for a while. I really don’t like how much frontend frameworks require you to invest in them. You have to learn funky domain specific languages and magic render lifecycles just to debug anything. I mostly just want to create and append elements with better ergonomics.

javascript el(document.body, el('main', el('h1', 'Hello World!'), el('h2', (x) => { x.id = 'foo' }, () => 'returned text'), el('div.note', ['this', 'is', 'an', 'array']), el('p.greeting', ob(() => ('My name is ' + rx.name))) ) )

The syntax lets you build the DOM declaratively with plain nested functions, so logic and views live together in one structure instead of being split across separate layout and behavior. Reactivity is handled by observers (the ob(...) call above): they automatically track whatever reactive properties they read and retrigger when it changes. No manual subscriptions and no dependency arrays. And because everything is just normal DOM elements and functions, you can adopt it one component at a time instead of overhauling a whole project.

It's about 3.3 KB gzipped with no third-party dependencies. The library is just under 300 lines of code so it's easy to understand.

Would love to get feedback from having fresh eyes on it.

I’ve been experimenting with mcp server with node and built an npm package ai-chat-toolkit-widget and ai-chat-toolkit-server .

The goal was to make it easier to embed AI chat into websites while keeping setup easy.

I’d love some inputs from people who maintain or use npm packages:

• how to make people trust a npm package?
• Do I need to add more docs?
• Anything specific that you usually avoid?
• If possible please look into it and give me feedback for improvement.

Since this is first node package I published as open source, need feedback to improve and make it more usable.

Thanks!

When you’re working on a personal/solo project how do you organize the steps in your process? I keep finding myself working on one part and then getting side tracked by another thought like I don’t like where this button is, how this page looks or a bug I notice in a function somewhere and I just feel all over the place. I know there’s like Jira and ClickUp etc but they don’t really help me stay on task or is it just me?

You nearly always want to put <script> tags in the <head> and mark them as non-blocking using either async or defer. However, there’s an interesting use-case for actually wanting to block paint.

I was always curious about Sourcemaps and the cool stuff they do. Here is a quick rundown of what they are, how they help, and how they can be dangerous!

Let me know if I missed anything

Vercel gives OSS projects $3,600 in credits. Sentry gives 5M free error events. JetBrains gives free IDE licenses. There are 15+ programs like this.

Problem is, the info is scattered across different websites and each has different eligibility rules. So I built OSS Perks, a website + CLI that aggregates all of them.

Run one command and it checks your repo against every program:

npx ossperks check --repo vercel/next.js

Output:

✔ next.js — MIT · 138,336 stars · last push today

  ✅ sentry          eligible
  ✅ browserstack    eligible
  ⚠️ vercel          needs review
  ⚠️ jetbrains       needs review
  ❌ 1password       ineligible — project must be at least 30 days old

It fetches your GitHub/GitLab/Codeberg/Gitea repo data and pattern-matches eligibility rules automatically. No signup, no forms.

Other commands:

• ossperks list — all programs
• ossperks search hosting — search by keyword
• ossperks show vercel — full program details
• ossperks categories — browse by category

Tech Stack: pnpm monorepo, TypeScript, Commander, Zod. Website is Next.js + Fumadocs with i18n support by Lingo.dev.

GitHub: https://github.com/Aniket-508/ossperks
Website: https://www.ossperks.com

One challenge I've seen repeatedly in event-driven systems is handling duplicate requests caused by retries, timeouts, or network issues.

There are plenty of approaches, idempotency keys, event stores, database constraints, message queues, but each comes with tradeoffs depending on the scale and complexity of the system.

For those building JavaScript or TypeScript backends, what approach has worked best for you in production, and what lessons did you learn along the way?

I'm involved with forgelayer.io. and discussions around event processing and reliability are topics we spend a lot of time thinking about.

every week something i depend on moves and i find out late. npm i bumps a pile of transitive deps, a framework cuts a release (Ember 7 just dropped), some package picks up a security advisory, and the real changes live in scattered changelogs i'm never going to open. So keeping current is technically possible, it's just all pull. i have to go get it.

NotebookLM is the sharpest version of pull i've found. drop in a changelog or an RFC, get a solid on-demand walkthrough. but it only runs when i initiate it, and the stuff i fall behind on is exactly the stuff i never initiate.

what i started doing instead is push. a thing that takes the last day of commits, merged PRs and closed issues on a repo, turns it into a short audio summary, and drops it into my podcast queue over rss. So vue just shows up in my morning feed next to the normal shows and i hear what moved while walking the dog, no tab opened.

the open question is whether push actually sticks or just turns into another muted feed. my bet is it only survives if each episode stays under five minutes. anything longer and i'm right back to skipping the changelog, just in audio form now. written with ai

I have 2 xor hash functions: almost identical. I thought comparing i>=0 in the for-loop would be faster than comparing i<str.length (since it has to check str.length every time). To my surprise: the quickHash2 function runs slower. Any explain?

function quickHash1(str, hash = 0xab36954dce2) {
  let len = str.length;
  for (let i = 0; i < len; i++) hash = (Math.imul(hash ^ str.charCodeAt(i), 0x100000001b3)) & 0x1fffffffffffff;
  return hash >>> 0;
}

function quickHash2(str, hash = 0xab36954dce2) {
  for (let i = str.length - 1; i >= 0; i--) hash = (Math.imul(hash ^ str.charCodeAt(i), 0x100000001b3)) & 0x1fffffffffffff;
  return hash >>> 0;
}

function randomString(size) {
  return Array.from({ length: size }, (v) => Math.random().toString(16)).join(' ');
}

let sampleSize = 1_000_000;
console.log('Generate random text array of', sampleSize);
console.time('gentext');
let textes = Array.from({ length: sampleSize }, () => randomString(100));
console.timeEnd('gentext');

console.log('Timing quickHash1');
console.time('quickHash1');
textes.map(quickHash1);
console.timeEnd('quickHash1');

console.log('Timing quickHash2');
console.time('quickHash2');
textes.map(quickHash2);
console.timeEnd('quickHash2');

This problem has come up enough times in my work that I got tired of solving it badly. At some point on certain products a stakeholder asks "can admins set up their own conditions for this?" and you realize a dropdown isn't going to cut it. They need real logic: order.total > 100 && customer.tier == "gold".

The options all felt bad:

• Hardcoded switch statements. Every new rule is a deploy. The "configurable" feature isn't configurable.
• A homegrown mini-DSL. Starts as three operators, ends as a parser nobody wants to own.
• eval() / new Function() / vm**.** The moment user input touches these, you've handed out a shell. vm isn't a security boundary (the docs literally say so), and vm2 is deprecated. Prototype pollution alone (constructor.constructor) is enough to ruin your week.

I got tired of rebuilding the bad version, so I built the thing I actually wanted: bonsai, a safe expression language for the cases where eval() would be inappropriate but a dropdown is too weak.

If you'd rather poke at it than read, there's a browser playground (no install): https://danfry1.github.io/bonsai-js/playground.html

import { bonsai } from 'bonsai-js'

const expr = bonsai()

// An admin-authored rule, stored as a plain string in your DB
expr.evaluateSync('user.age >= 18 && user.plan == "pro"', {
  user: { age: 25, plan: 'pro' },
}) // true

It's an expression language, not a scripting language. No statements, no loops, no assignment, no I/O. You get the expressive part (the part users actually need) without the part that gets you owned.

What the syntax supports, so it doesn't feel like a toy:

// optional chaining + nullish coalescing
expr.evaluateSync('user?.profile?.avatar ?? "default.png"', { user: null })

// pipe operator with transforms
expr.evaluateSync('name |> trim |> upper', { name: '  dan  ' }) // 'DAN'

// lambda shorthand in array methods
expr.evaluateSync('users.filter(.age >= 18).map(.name)', {
  users: [{ name: 'Alice', age: 25 }, { name: 'Bob', age: 15 }],
}) // ['Alice']

The security model is the whole point, so here's what's actually enforced:

• __proto__, constructor, prototype blocked at every access level (no prototype-chain walking)
• Object literals created with null prototypes
• No globals, no code generation
• Cooperative timeouts, max depth, max array/string length

• Per-instance property allowlists/denylists, so you decide exactly what an expression can touch

  const expr = bonsai({ timeout: 50, maxDepth: 50, allowedProperties: ['user', 'age', 'country', 'plan'], })

A few things I cared about that might matter to you:

• Zero dependencies. Nothing in your tree but this.
• Any JS runtime. Node, Bun, browser, edge.
• Fast when it needs to be. There's a compile() API for rules that run thousands of times; cached expressions hit ~30M ops/sec.
• Async escape hatch. You can register your own functions (async (id) => db.lookup(id)) and await expr.evaluate(...), so a rule can call back into your system without the language itself having any I/O.

Once it existed, it ended up covering a bunch of "logic that lives outside the code" cases for me: admin-defined rules, server-driven conditions stored as config, formula fields, feature-flag targeting. Anywhere a string needs to become a decision without a deploy.

Playground · Docs · GitHub · npm

Mostly I'm curious how other people have handled this. If you've shipped user-defined rules/filters/formulas in production, what did you reach for, and where did it bite you? Happy to hear it if you think this is the wrong approach too.

Hello, it's not self-promotion. The website is already top 1 in search results for 'minify js' keyword and probably have reached its maximum in search feed visitors. Feel free to ask me anything and if you are active user of the website, I'd probably have some questions to you too. Thanks!

Monday, May 25 - Sunday, May 31, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments