Meet JSON's functional half-brother.
A Single-source-of-truth (SSOT) for keeping business logic up to date and giving the same results on different codebases (e.g. front & backend).
I built JSOL because I didn't want to keep maintaining the same rules twice (once for the server, once again for the browser) on IPAX, a color science framework for accessible design systems. Every change meant updating both, testing both, and hoping they still agreed.
Did you know that something as simple as modulo can give you different results across languages? My LLM didn't. And that's just one bug that slipped through code review.
The ugliest common denominator
Since most general-use languages today are somehow C-like, I wondered if there was some lingua franca we could use to declare business logic once, and include afterwards in our code with bit-for-bit parity.
That's how JSOL was born: a strict subset of JavaScript that transpiles to JavaScript, PHP, TypeScript and Python (with more targets planned), guaranteeing deterministic parity. Write the rule once, change it once, test it once.
Think JSON, but for business logic. Also, think dumb and ugly: the foundation was to find an economical point where C-like languages "naturally" meet, to the point an AST was not even needed. That lowest common denominator is usually PHP.
| Case | JS | PHP | Python |
|---|---|---|---|
| 7.5 % 2 | 1.5 | 1 | 1.5 |
| Math.round(2.5) | 3 | 3 | 2 |
| Math.round(-2.5) | -2 | -3 | -2 |
| "😀".length | 2 | 4 | 1 |
| String(true) | true | 1 | True |
| "12abc" as int | 12 | 12 | ValueError |
| "12abc" as int | 12 | 12 | ValueError |
| "10" < "9" | true | false | true |
| [10, 1, 2].sort() | 1, 10, 2 | 1, 2, 10 | 1, 2, 10 |
| "abc".split("") | a,b,c | a,b,c | ValueError |
| "a" || "b" | a | true | a |
| min(NaN, 5) | NaN | 5 | nan |
| [].pop() | undefined | null | IndexError |
| "" as number | 0 | 0 | ValueError |
Every language behaves slightly differently. When maintaining business rules across several of them, it's a disaster waiting to happen. JSOL is being developed to give the same canonical answer on every target, considering more than 140 semantic differences to sort out.
Is it worth your time?
The first question we developers ask about a new tool is: "Should I bother learning this?"
JSOL has strict syntax, zero syntactic sugar, and a learning curve. Writing it — even with an AI's help — will take you longer than writing native code you've already mastered. But JSOL's upfront cost can pay off in iterative maintenance.
The honest way to answer that question is with a model. So the first example below is exactly that: an adoption-economics model written in JSOL, running live in the REPL. And compiled to every target for inspection.
Play with the inputs: how many targets you maintain, how often your rules change, how many iterations until the upfront cost pays for itself. Add rows to evaluate different scenarios. And while you're at it, you're watching JSOL do what it was built to do.
(INPUT)
(OUTPUT)
Function: $nKaryTreeDepth
// @JSOL v0.2.97
/**
Test: depth of a perfectly balanced k-ary tree with n leaves, computed
as ceil(log_k(n)). With n=27 leaves and branching factor 3 (27 = 3^3),
the true answer is exactly 3.
Naive JavaScript (Node/V8), verified:
```js
function karyTreeDepth(leaves, branchingFactor) {
return Math.ceil(Math.log(leaves) / Math.log(branchingFactor));
}
karyTreeDepth(27, 3);
// -> 4
// Math.log(27)/Math.log(3) evaluates to 3.0000000000000004 in V8, one
// bit above the true value. ceil() of that silently returns one level
// too many.
```
Naive Python, verified, and here it lands exactly on 3:
```python
import math
def kary_tree_depth(leaves, branching_factor):
return math.ceil(math.log(leaves) / math.log(branching_factor))
kary_tree_depth(27, 3)
# -> 3 (glibc's log() happens to round this particular case cleanly)
```
Important honesty check: Python is not "correct by design" here, it
got lucky with this specific input on this specific libm. ECMA-262
explicitly does not require exact precision for Math.pow/Math.log
across engines, so this is not a bug either engine is obligated to
fix, and a future glibc or a different Python build could round this
exact expression the other way. This is not a logic bug like the
other examples, it's proof that "same algorithm, same language
family" is not enough for determinism when the algorithm leans on a
transcendental function. Math.logX must not be implemented as
log(x)/log(b) division when a native base-N primitive exists, and
where it doesn't, needs a portable, non-native algorithm, precisely
because no target's native math library will sign a contract on the
last bit.
*/
/**
@contract
{
"cases": [
{
"in": { "$nLeaves": 27, "$nBranchingFactor": 3 },
"expect": 3
},
{
"in": { "$nLeaves": 9, "$nBranchingFactor": 3 },
"expect": 2
}
]
}
*/
const $nKaryTreeDepth = function ($nLeaves, $nBranchingFactor) {
return Math.ceil(Math.logX($nLeaves, $nBranchingFactor));
};// @JSOL v0.2.97
/**
Test: depth of a perfectly balanced k-ary tree with n leaves, computed
as ceil(log_k(n)). With n=27 leaves and branching factor 3 (27 = 3^3),
the true answer is exactly 3.
Naive JavaScript (Node/V8), verified:
```js
function karyTreeDepth(leaves, branchingFactor) {
return Math.ceil(Math.log(leaves) / Math.log(branchingFactor));
}
karyTreeDepth(27, 3);
// -> 4
// Math.log(27)/Math.log(3) evaluates to 3.0000000000000004 in V8, one
// bit above the true value. ceil() of that silently returns one level
// too many.
```
Naive Python, verified, and here it lands exactly on 3:
```python
import math
def kary_tree_depth(leaves, branching_factor):
return math.ceil(math.log(leaves) / math.log(branching_factor))
kary_tree_depth(27, 3)
# -> 3 (glibc's log() happens to round this particular case cleanly)
```
Important honesty check: Python is not "correct by design" here, it
got lucky with this specific input on this specific libm. ECMA-262
explicitly does not require exact precision for Math.pow/Math.log
across engines, so this is not a bug either engine is obligated to
fix, and a future glibc or a different Python build could round this
exact expression the other way. This is not a logic bug like the
other examples, it's proof that "same algorithm, same language
family" is not enough for determinism when the algorithm leans on a
transcendental function. Math.logX must not be implemented as
log(x)/log(b) division when a native base-N primitive exists, and
where it doesn't, needs a portable, non-native algorithm, precisely
because no target's native math library will sign a contract on the
last bit.
*/
/**
@contract
{
"cases": [
{
"in": { "$nLeaves": 27, "$nBranchingFactor": 3 },
"expect": 3
},
{
"in": { "$nLeaves": 9, "$nBranchingFactor": 3 },
"expect": 2
}
]
}
*/
const $nKaryTreeDepth = function ($nLeaves, $nBranchingFactor) {
return Math["ceil"](Math["logX"]($nLeaves, $nBranchingFactor));
};
window['$nKaryTreeDepth'] = $nKaryTreeDepth;
<?php
// @JSOL v0.2.97
/**
Test: depth of a perfectly balanced k-ary tree with n leaves, computed
as ceil(log_k(n)). With n=27 leaves and branching factor 3 (27 = 3^3),
the true answer is exactly 3.
Naive JavaScript (Node/V8), verified:
```js
function karyTreeDepth(leaves, branchingFactor) {
return Math.ceil(Math.log(leaves) / Math.log(branchingFactor));
}
karyTreeDepth(27, 3);
// -> 4
// Math.log(27)/Math.log(3) evaluates to 3.0000000000000004 in V8, one
// bit above the true value. ceil() of that silently returns one level
// too many.
```
Naive Python, verified, and here it lands exactly on 3:
```python
import math
def kary_tree_depth(leaves, branching_factor):
return math.ceil(math.log(leaves) / math.log(branching_factor))
kary_tree_depth(27, 3)
# -> 3 (glibc's log() happens to round this particular case cleanly)
```
Important honesty check: Python is not "correct by design" here, it
got lucky with this specific input on this specific libm. ECMA-262
explicitly does not require exact precision for Math.pow/Math.log
across engines, so this is not a bug either engine is obligated to
fix, and a future glibc or a different Python build could round this
exact expression the other way. This is not a logic bug like the
other examples, it's proof that "same algorithm, same language
family" is not enough for determinism when the algorithm leans on a
transcendental function. Math.logX must not be implemented as
log(x)/log(b) division when a native base-N primitive exists, and
where it doesn't, needs a portable, non-native algorithm, precisely
because no target's native math library will sign a contract on the
last bit.
*/
/**
@contract
{
"cases": [
{
"in": { "$nLeaves": 27, "$nBranchingFactor": 3 },
"expect": 3
},
{
"in": { "$nLeaves": 9, "$nBranchingFactor": 3 },
"expect": 2
}
]
}
*/
$nKaryTreeDepth = function ($nLeaves, $nBranchingFactor) {
return ceil(Math::logX($nLeaves, $nBranchingFactor));
};
declare var JSOL: any;
declare var Rgx: any;
declare var Str: any;
declare var Arr: any;
declare var Bool: any;
declare var Cast: any;
// @JSOL v0.2.97
/**
Test: depth of a perfectly balanced k-ary tree with n leaves, computed
as ceil(log_k(n)). With n=27 leaves and branching factor 3 (27 = 3^3),
the true answer is exactly 3.
Naive JavaScript (Node/V8), verified:
```js
function karyTreeDepth(leaves, branchingFactor) {
return Math.ceil(Math.log(leaves) / Math.log(branchingFactor));
}
karyTreeDepth(27, 3);
// -> 4
// Math.log(27)/Math.log(3) evaluates to 3.0000000000000004 in V8, one
// bit above the true value. ceil() of that silently returns one level
// too many.
```
Naive Python, verified, and here it lands exactly on 3:
```python
import math
def kary_tree_depth(leaves, branching_factor):
return math.ceil(math.log(leaves) / math.log(branching_factor))
kary_tree_depth(27, 3)
# -> 3 (glibc's log() happens to round this particular case cleanly)
```
Important honesty check: Python is not "correct by design" here, it
got lucky with this specific input on this specific libm. ECMA-262
explicitly does not require exact precision for Math.pow/Math.log
across engines, so this is not a bug either engine is obligated to
fix, and a future glibc or a different Python build could round this
exact expression the other way. This is not a logic bug like the
other examples, it's proof that "same algorithm, same language
family" is not enough for determinism when the algorithm leans on a
transcendental function. Math.logX must not be implemented as
log(x)/log(b) division when a native base-N primitive exists, and
where it doesn't, needs a portable, non-native algorithm, precisely
because no target's native math library will sign a contract on the
last bit.
*/
/**
@contract
{
"cases": [
{
"in": { "$nLeaves": 27, "$nBranchingFactor": 3 },
"expect": 3
},
{
"in": { "$nLeaves": 9, "$nBranchingFactor": 3 },
"expect": 2
}
]
}
*/
const $nKaryTreeDepth = function($nLeaves: any, $nBranchingFactor: any): number {
return Math["ceil"](Math["logX"]($nLeaves, $nBranchingFactor));
};
import math
import functools
from jsol_core import JSOL
# @JSOL v0.2.97
#*
#Test: depth of a perfectly balanced k-ary tree with n leaves, computed
#as ceil(log_k(n)). With n=27 leaves and branching factor 3 (27 = 3^3),
#the true answer is exactly 3.
#
#Naive JavaScript (Node/V8), verified:
#
#```js
#function karyTreeDepth(leaves, branchingFactor) {
# return Math.ceil(Math.log(leaves) / Math.log(branchingFactor));
#}
#karyTreeDepth(27, 3);
#// -> 4
#// Math.log(27)/Math.log(3) evaluates to 3.0000000000000004 in V8, one
#// bit above the true value. ceil() of that silently returns one level
#// too many.
#```
#
#Naive Python, verified, and here it lands exactly on 3:
#
#```python
#import math
#
#def kary_tree_depth(leaves, branching_factor):
# return math.ceil(math.log(leaves) / math.log(branching_factor))
#
#kary_tree_depth(27, 3)
## -> 3 (glibc's log() happens to round this particular case cleanly)
#```
#
#Important honesty check: Python is not "correct by design" here, it
#got lucky with this specific input on this specific libm. ECMA-262
#explicitly does not require exact precision for Math.pow/Math.log
#across engines, so this is not a bug either engine is obligated to
#fix, and a future glibc or a different Python build could round this
#exact expression the other way. This is not a logic bug like the
#other examples, it's proof that "same algorithm, same language
#family" is not enough for determinism when the algorithm leans on a
#transcendental function. Math.logX must not be implemented as
#log(x)/log(b) division when a native base-N primitive exists, and
#where it doesn't, needs a portable, non-native algorithm, precisely
#because no target's native math library will sign a contract on the
#last bit.
#
#*
#@contract
#{
# "cases": [
# {
# "in": { "$nLeaves": 27, "$nBranchingFactor": 3 },
# "expect": 3
# },
# {
# "in": { "$nLeaves": 9, "$nBranchingFactor": 3 },
# "expect": 2
# }
# ]
#}
#
def nKaryTreeDepth(nLeaves, nBranchingFactor):
return math.ceil(math.log(nLeaves, nBranchingFactor));
Every example is also a test.
To be released, every JSOL build has to pass every example correctly, with exactly the same results across every supported target. A "minor" change that resulted in a test giving out "8" in JavaScript and "8.0" in PHP? Rejected.
The language and compiler are continuosly improved because of what these 70+ examples demand. The CLRS examples are here for the same reason: if JSOL aims to be a language someone can read rather than just compile, it has to survive contact with computer science, not just invoicing.
Strict Validation
Finance & Rules
Computer Science
What JSOL is NOT
JSOL is not a full-stack framework, and it's not a general-purpose language. It is an isolated, pure, synchronous calculator.
It doesn't touch the DOM, it doesn't make network requests (no fetch or Async), and it doesn't talk to databases.
Every alternative to JSOL (like Haxe or WebAssembly) buys generality or performance at the cost of requiring a toolchain. JSOL buys zero-toolchain portability by aggressively restricting what you can write.
The Honest Tradeoffs (Where JSOL is worse)
JSOL is intentionally worse and slower than writing native code on any single target. It is currently validating its core hypotheses on portability first. These are the engine-level restrictions you accept when using it:
| Feature | Native JS / PHP / Python | JSOL | Why it was stripped |
|---|---|---|---|
| Developer Speed & Syntax | Fast (Syntactic sugar, modern abstractions) | Slower (Dumb, ugly, spartan & strictly constrained) | To eliminate the need for an AST compiler, JSOL severely restricts grammar to flat, lowest-common-denominator patterns. |
| Control Flow | Async, Promises, Threads | Strictly Synchronous (Single-thread blocking) | Async control flow has no shared syntax between JS, PHP, and Python. |
| State & Collections Performance | Classes, this, Reference Passing |
Flat Dicts & Value Semantics (Higher GC pressure) | Forbidding classes guarantees simple $O(1)$ property access, but forces copying for immutability across targets, making JSOL slower on large arrays. |
| Text Parsing | Native Regex (PCRE / V8 / RE2) | Restricted Regex subset & procedural loops | Regex engines differ across runtimes. Complex patterns, lookarounds, and backreferences can cause catastrophic backtracking (ReDoS) in one engine but not another. |
| Floating Point Precision | Native floating-point masking / coercion quirks | Strict IEEE-754 across all targets | For $n, JSOL enforces strict IEEE-754 behavior across all runtimes for predictable standardization. For exact accounting where IEEE-754 is unsuitable, future specs project incorporating other mature, mathematically proven standards. |
Design Pillars
Four principles shape every rule in the specification.
1. Clarity
A JSOL algorithm has to be readable by the person who owns the business logic, not just by a compiler.
This is also why JSOL doesn't standardize how you structure code (nested functions vs. flat scope, for instance) — that's implementation shape, not business logic.
2. Portability
The same source runs correctly on every proven target.
This is where Deterministic Parity comes from: given identical inputs, every target's output has to match, bit for bit.
3. Performance
The compiled output should be no heavier and no slower than it has to be.
This is where Zero Dead Code comes from: nothing gets shipped that a given file doesn't actually use.
4. Developer Experience
Writing, compiling, and debugging JSOL should be as frictionless as the constraints allow.
This is where the AST-free compiler pipeline and Zero Runtime Dependencies come from.
This is an open problem, not a finished product
JSOL works today for JavaScript, PHP, TypeScript and Python. The compiler is self-hosting (i.e., it compiles itself) and the fixed-point convergence tests prove that the output is stable across generations and hosts. But the really interesting work is what comes next.
The project's real bet is that the same approach can extend to other targets. TypeScript, Go, C#, Python, Rust, C: each one is a separate compiler backend, and each one teaches you something different about what "portable business logic" actually requires.
If you're a CS educator or student, EXTENDING.md lays out the feasibility matrix, the JSOL-C leverage effect, and the specific compiler design problems involved.
Fork it. Break it. Build a target. The compiler architecture is deliberately modular: adding a language means writing one compiler file, not rewriting the core.