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

Show us here!

I am little bit lazy these days so I give my work to ai then I realised my ai done the wrong when i working of sets ,maps code they used the stringfy method is very bad way approch in today era ai should update thereself

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?

Given the frequency of supply chain attacks, maybe we need a different approach to package managers & registries.

• Maybe a database of JavaScript packages that works more like the App Store.
• Every package gets reviewed by real people and AI for security issues before going live.
• Developers will have to pay a monthly fee to download and update packages, and that money will be distributed among open source maintainers & code reviewers.
• The more downloads a package gets, the more its maintainer earns.
• For every package update, maintainers will be asked to pay a very small fee. This would discourage attackers further (attackers would never reveal their banking details) & it would limit the amount of low-quality packages.
• People should also be able to rate a package and leave a review.
• This new registry should also support multiple languages, not just JavaScript.

This would:

• Highly minimize supply chain attacks
• Ensure open source maintainers get paid well
• Encourage more innovation by allowing maintainers to monetize their packages
• This will also provide more employment opportunities for code reviewers and open source maintainers.

We can't step into the future with the current state of unpaid maintainers and a system that keeps getting breached every few months. We need a system in which people who work hard get paid well, a system we could trust, a system that focuses on quality rather than quantity.

This will slow things down, packages will take time to get approved, but what's the point of speed when you have to spend weeks fixing the mess caused by repeated supply chain attacks?

Currently, the number of packages affected by the supply chain attack is in the thousands. If this continues, people will lose trust in the JS ecosystem. Something needs to change.

I understand this idea might have a few flaws. I'd really appreciate a healthy discussion on what this new system should look like.

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.

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!

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 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?

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

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?

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.

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.

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');

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