StrictJS

Dr Codewell — Sun, 25 Jan 2026 09:30:02 +0000

StrictJS Part 1: Rethinking Numbers and Strings in JavaScript

JavaScript is one of the most successful programming languages ever created.
It runs everywhere, scales from small scripts to massive systems, and powers the modern web.

But its success came with a trade-off.

Over the years, we’ve normalized silent coercions, implicit conversions, and runtime surprises as “just how JavaScript works.” We write defensive code, add endless checks, and hope bugs don’t surface in production.

StrictJS is my attempt to step back and ask a simple question:

What if JavaScript values actually meant what they said?

In this first post, I’ll start at the foundation: numbers and strings.

The Problem With JavaScript Numbers

JavaScript has only one numeric type: Number.

That decision simplified the language early on, but it also introduced behavior that most developers eventually learn to work around instead of trust.

Consider this:

"5" + 1   // "51"
"5" - 1   // 4
0.1 + 0.2 // 0.30000000000000004

None of these are bugs. They are design decisions.

But they also mean:

Values silently change meaning
Types lie about intent
Errors show up late, not early

In real systems—financial calculations, counters, async pipelines—this is dangerous.

StrictJS does not try to “fix” JavaScript.
It simply refuses to guess.

Strict Numbers in StrictJS

In StrictJS, a number is not just a value.
It is a contract.

Core principles:

No implicit coercion
Explicit creation only
Operations fail fast
Intent matters more than convenience

Example:

const a = StrictNumber(5)
const b = StrictNumber("5") // ❌ Error

If something is a string, it stays a string.
If something is a number, it behaves like one.

Operations are explicit:

a.add(1)        // ✅ StrictNumber(6)
a.add("1")      // ❌ Type error

This might feel strict at first—but that’s the point.

I would rather see an error while writing code than debug it months later in production.

Why This Matters in Real Systems

Silent numeric coercion doesn’t usually break small demos.
It breaks long-lived systems.

Financial calculations drift
Counters misreport
API boundaries blur
Async pipelines amplify small mistakes

Strict numbers move these failures to the surface, where they belong.

Early errors are cheaper than late surprises.

The Problem With JavaScript Strings

Strings in JavaScript often pretend to be something else.

"5" == 5        // true
"true" == true // false

Strings cross system boundaries:

User input
JSON payloads
Network responses

Yet JavaScript frequently treats them as almost numbers, almost booleans, or almost anything.

In practice, this leads to ambiguity.

A string that looks like data is not data.

Strict Strings in StrictJS

In StrictJS, a string is always just a string.

No automatic casting.
No silent parsing.
No assumptions.

const name = StrictString("Kenneth")
const age  = StrictString("25")

age + 1        // ❌ Error
age.toNumber() // ✅ Explicit conversion

Parsing is not an accident.
It is a decision.

By forcing explicit conversion, StrictJS makes intent visible in code. When someone reads it months later, there is no ambiguity about what is happening.

JavaScript vs StrictJS (Quick Comparison)

Operation	JavaScript	StrictJS
`"5" + 1`	`"51"`	❌ Error
`"5" - 1`	`4`	❌ Error
`0.1 + 0.2`	Precision loss	Explicit handling
String → Number	Implicit	Explicit only

StrictJS doesn’t try to be clever.
It tries to be honest.

What’s Next

This post only covers the foundation.

In the next parts, I’ll dive into:

Strict booleans
Strict objects and schemas
Async execution with guarantees
Memory-aware JavaScript

StrictJS is not about replacing JavaScript.

It’s about disciplining it—bringing back clarity, intent, and trust in our code.

"Acquire Proficiency in JavaScript Code Integration Through the Development of a Task Manager Application."

Dr Codewell — Sun, 10 Sep 2023 13:55:30 +0000

DEV Community: Dr Codewell