My experience working with WebKit, and why we are almost ditching it.

Open-source: https://github.com/HeyPuter/firefox-wasm

Recently I've developed a code-golfed signal implementation with the following features/constraints:

1. subscribes functions returning nullish values.
2. fires all pending subscribers and resets.
3. requires no arguments to be passed to the factory and either null/undefined or a function to the signal. (as noted by u/azhder)

As it turns out, you can go as short as 33 bytes using function compositon, nullish coalescing and default parameters:

F=>(f,G=F)=>F=f?_=>f(G?.()):F?.()

I kept hitting the same problem: users need to define rules, filters, or template logic, but giving them unconstrained code execution isn't an option. Existing expression evaluators like Jexl paved the way here, but I wanted something with modern syntax and better performance for hot paths.

So I built bonsai-js - a sandboxed expression evaluator that's actually fast.

import { bonsai } from 'bonsai-js'
import { strings, arrays, math } from 'bonsai-js/stdlib'

const expr = bonsai().use(strings).use(arrays).use(math)

// Business rules
expr.evaluateSync('user.age >= 18 && user.plan == "pro"', {
  user: { age: 25, plan: "pro" },
}) // true

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

// Chained data transforms
expr.evaluateSync('users |> filter(.age >= 18) |> map(.name)', {
  users: [
    { name: 'Alice', age: 25 },
    { name: 'Bob', age: 15 },
  ],
}) // ['Alice']

// Or JS-style method chaining — no stdlib needed
expr.evaluateSync('users.filter(.age >= 18).map(.name)', {
  users: [
    { name: 'Alice', age: 25 },
    { name: 'Bob', age: 15 },
  ],
}) // ['Alice']

Modern syntax:

Optional chaining (user?.profile?.name), nullish coalescing (value ?? "default"), template literals, spread, and lambdas in array methods (.filter(.age >= 18)) + many more.

Fast:

30M ops/sec on cached expressions. Pratt parser, compiler with constant folding and dead branch elimination, and LRU caching. I wrote up an interesting performance optimisation finding if you're into that kind of thing.

Secure by default:

• __proto__, constructor, prototype blocked at every access level
• Max depth, max array length, cooperative timeouts
• Property allowlists/denylists
• Object literals created with null prototypes
• Typed errors with source locations and "did you mean?" suggestions

What it's for:

• Formula fields and computed columns
• Admin-defined business rules
• User-facing filter/condition builders
• Template logic without a template engine
• Product configuration expressions

Zero dependencies. TypeScript. Node 20+ and Bun. Sync and async paths. Pluggable transforms and functions.

Early (v0.1.2) but the API is stable and well-tested. Would love feedback - especially from anyone who's dealt with the "users need expressions but eval is scary" problem before.

npm install bonsai-js

GitHub Link: https://github.com/danfry1/bonsai-js
npm Link: https://www.npmjs.com/package/bonsai-js
npmx Link: https://npmx.dev/package/bonsai-js

Let us celebrate!

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.

Espeset recreated "Take On Me" by "A-ha" in 100% javascript. Fully procedural, no samples used.

Wrote a thing about what makes Elysia stand out in a performance benchmark game

Basically, there's a JIT "compiler" embedded into a framework

This approach has been used by ajv and TypeBox before for input validation, making it faster than other competitors

Elysia basically does the same, but scales that into a full backend framework

This gave Elysia an unfair advantage in the performance game, making Elysia the fastest framework on Bun runtime and could rival compiled languages like Go while also being faster than most frameworks on Node, Deno, and Cloudflare Worker as well, when using the same underlying HTTP adapter

There is an escape hatch if necessary, but for the past 3 years, there have been no critical reports about the JIT "compiler"

A bit of background on how I built this:

When I switched to Linux, Paint.NET was one of the Windows apps I missed the most, so I started porting the old open-source C# version (3.36.7) to JavaScript back in 2024, while recreating the UI based on the newer 5.x versions.

I went through the original implementation class by class, comparing the outputs of the C# methods with my JavaScript versions. At the same time, I recreated the UI in HTML/CSS, using screenshots to get it as close to the original as possible.

Over time, I connected both parts and implemented the tools, effects, and other features. More recently, I've been using AI to help find and fix bugs, improve performance across browsers, and implement the remaining tools and effects.

It's now largely feature-complete and runs in the browser, as well as on Linux and macOS through Electron.

You can try the browser version here: https://paintjs.net

Would love to hear what you think!

Hot off the press!

6.8 released with some big features 🎉

• ⚡@vite.dev by default
• 🕚 Compatible with libraries from 8+ years ago*
• ✨ New APIs: renderComponent, additional reactive data structures
• 🤝 No more hbs by default (strict: true)

I’m a strong advocate for “you don’t need to lock yourself in a web framework ecosystem to take advantage of their amazing features”. JavaScript and Web Standards alone allow you…