JavaScript (ES2025)

This assessment applies the coupling account — coupling as access to a shared resource, and the coupling floor [1], [2] — and the knowledge-embodiment theorem [3]; the language is assessed against its official reference [4].

1 Assessment

This page assesses JavaScript in five parts: core coupling — what the language’s own constructs force; ecosystem coupling — what the surrounding platform, tooling, and community cost; engineering readiness — whether the artifact can be reproduced, verified, observed, worked in quickly, connected to other languages, and governed openly; the profile — the unscored facts a score cannot express; and the scoring detail — the mechanism marks and the arithmetic behind every score. A ✅ bullet marks a construct that helps. A ⚠️ or ❌ bullet marks a cost; the scoring model does not price every cost named here.

Core coupling 28/100 · Ecosystem coupling 73/100 · Engineering readiness 96/100

1.1 Core coupling

1.1.1 Type

• ❌ No static types: All coupling deferred to runtime
• ✅ Prototypes decouple: Can modify behavior without inheritance
• ⚠️ Duck typing: Structural at runtime, but no safety
• ❌ Type coercion couples: Implicit conversions hide intent
• ❌ Undefined/null confusion: Two absence types couple

1.1.2 Construction

• ✅ Object literals: Simple construction without classes
• ⚠️ Prototypes flexible: Can change after construction
• ❌ new keyword confusing: this binding couples to call context
• ⚠️ Factory functions decouple: Can avoid new entirely
• ❌ Global scope couples: window, globalThis everywhere
• ❌ Module side effects: Import order matters
• ❌ Prototype pollution: Can modify built-in prototypes globally

1.1.3 Memory

• ✅ Garbage collection decouples memory: Generational GC (implementation dependent)
• ✅ No manual memory management: Can’t have use-after-free
• ⚠️ GC pauses affect latency: V8, SpiderMonkey, etc. have different characteristics
• ❌ Closure captures create leaks: Easy to accidentally hold references
• ❌ Event listener leaks common: Forgotten listeners prevent collection
• ✅ Reference cycles are collected: A mark-and-sweep collector reclaims objects that point at each other, so a cycle alone is not a leak
• ⚠️ WeakMap/WeakRef help: Can create weak references, but not automatic

1.1.4 Error

• ❌ Exceptions unchecked: No type tracking
• ❌ Promise rejection unchecked: .catch() optional
• ⚠️ Result types possible: Libraries exist but uncommon
• ❌ Callbacks couple error/success: (err, result) mixes concerns

1.1.5 Concurrency

• ❌ Single-threaded event loop: A long task blocks every other callback, so no second core is available for CPU-bound work
• ✅ Async/await separates: Explicit async functions
• ❌ Promise errors untracked: Rejection type unknown
• ⚠️ Web Workers separate: Explicit message passing, but manual

1.1.6 Platform

• ✅ No vendor owns the language: ECMAScript is standardized by Ecma International as ECMA-262 and evolves through the public TC39 proposal process
• ✅ Independent engines implement it: V8, SpiderMonkey, and JavaScriptCore are separate implementations, so a program is not bound to one vendor’s runtime
• ✅ A runtime exists on every platform: Every web browser ships an engine, and Node.js, Deno, and Bun run the language outside the browser
• ✅ The source is portable between hosts: The same script runs in a browser and in Node.js; only the host API differs, not the language

1.1.7 Trade-offs (not coupling)

• Dynamic Typing vs. Predictability: All coupling deferred to runtime, no compile-time detection
• Flexibility vs. Correctness: Can modify anything at runtime, couples correctness to discipline
• Type Coercion: Implicit conversions couple values to contexts ("5" + 3 === "53", "5" - 3 === 2)
• This Binding: Function context couples to call site (.call(), .apply(), .bind() required)
• Callback Hell vs. Promises vs. Async/Await: Three async paradigms couple code to era written
• Module Systems: CommonJS vs. ES6 modules couples code to environment (Node vs. browser)
• Prototype Chain: Inheritance couples objects to prototype chain modifications

1.2 Ecosystem coupling

1.2.1 Performance

• ✅ JIT optimization: V8, SpiderMonkey fast
• ⚠️ Unpredictable: Performance depends on JIT behavior
• ⚠️ GC pauses: Non-deterministic
• ✅ Event loop: Efficient for I/O
• ❌ Single-threaded: Couples CPU-bound work to event loop

1.2.2 Ecosystem

• ✅ Massive ecosystem: Npm largest package ecosystem
• ✅ Excellent tooling: Webpack, Vite, ESBuild, Babel
• ✅ Great IDE support: VSCode, WebStorm
• ⚠️ Dependency hell: node_modules coupling
• ✅ Browser DevTools: Best-in-class debugging

1.2.3 Evolution

• ✅ TC39 process: Predictable evolution
• ✅ Backward compatible: Old code keeps working
• ✅ Transpilation: Babel enables future features
• ⚠️ ES6 adoption: Took years to become standard

1.2.4 Domain

• ✅ Excellent for frontend: Only native browser language
• ✅ Great for full-stack: Node.js backend
• ✅ Strong for scripting: Quick prototypes
• ❌ Poor for systems: No control, GC
• ⚠️ CPU-bound: Single-threaded limits

1.2.5 Learning

• ✅ Gentle start: Easy to begin
• ⚠️ Weird parts: this, prototypes, coercion
• ✅ Massive resources: Tutorials everywhere
• ❌ Mastery hard: Closure, async, event loop

1.2.6 Syntax

• ✅ Concise: Arrow functions, destructuring
• ✅ Flexible: Multiple paradigms
• ⚠️ Inconsistent: Many ways to do things
• ❌ Coercion surprises: [] + {} !== {} + []

1.2.7 Testing

• ✅ Jest, Mocha, Vitest: Mature frameworks
• ✅ Excellent debuggers: Chrome DevTools
• ✅ Source maps: Debug original code
• ⚠️ Async debugging: Promises/async can be tricky

1.2.8 Security

• ✅ Memory safe: GC prevents memory bugs
• ❌ Prototype pollution: Object mutation vulnerabilities
• ❌ XSS: DOM manipulation couples to security
• ⚠️ npm vulnerabilities: Dependency attack surface

1.3 Engineering readiness

1.3.1 Reproducibility

• ✅ No charged mechanism in this dimension.

1.3.2 Supply chain

• ⚠️ The package registry is a flat name space.

1.3.3 Observability

• ✅ No charged mechanism in this dimension.

1.3.4 Feedback

• ✅ No charged mechanism in this dimension.

1.3.5 Interop

• ✅ No charged mechanism in this dimension.

1.3.6 Governance

• ✅ No charged mechanism in this dimension.

1.4 Profile

Unscored, and kept separate from every score on purpose. The profile records what a mechanism price cannot express: what a running program costs, how well a coding model and an agent work in the language, and whether a safety-critical path exists.

1.4.1 Energy and cost

What this axis asks: what does a running program cost in energy and time?

• ⚠️ Runs on a virtual machine, above native code in the energy and time benchmarks [5]; a causal re-analysis attributes most of the gap to execution time [6].

1.4.2 AI and agent readiness

What this axis asks: how well does a coding model and an agent work in this language?

• ✅ A large training corpus and strong code-generation results: models write this language well [7], [8].

1.4.3 Safety certification

What this axis asks: is there a certified or standards-qualified path to a safety-critical system?

• ⚠️ No certified or standards-qualified path for safety-critical systems.

1.5 Scoring detail

1.5.1 Core coupling Dimensions

Dimension	Mechanism	Description	Present	Cost
Type	T1	dynamic no static check	✅	−15
	T2	weak static	—	0
	T3	dynamic/duck dispatch	✅	−8
	T4	no sum types	✅	−4
	T5	no generics	✅	−4
	T6	no namespaces	—	0
	T7	type erasure/reflection	—	0
	T8	operator overloading	—	0
	T9	inheritance required for polymorphism	—	0
	T10	no null-safety	✅	−8
	T11	no module boundary	—	0
	T12	no effect tracking	✅	−8
	T13	async/sync colouring	✅	−8
	T14	unchecked foreign boundary	✅	−4
Type subtotal				−15 (−59)
Construction	C1	global mutable state by default	✅	−15
	C2	no immutability by default	✅	−4
	C3	constructors coupled to allocation	—	0
	C4	no constructor/validation	—	0
Construction subtotal				−15 (−19)
Memory	M1	manual deallocation	—	0
	M2	GC non-deterministic pauses	✅	−8
	M3	no RAII	✅	−4
	M4	no ownership model	✅	−8
Memory subtotal				−15 (−20)
Error	Er1	no structured path	—	0
	Er2	unchecked exceptions only	✅	−8
	Er3	errors ignored/non-exhaustive	✅	−4
	Er4	no composable result type	—	0
Error subtotal				−12
Concurrency	K1	GIL/no parallel	✅	−15
	K2	shared mutable state default	✅	−8
	K3	manual sync no race detection	✅	−8
	K4	no structured concurrency	—	0
	K5	no primitives	—	0
Concurrency subtotal				−15 (−31)
Platform	P1	cannot function outside one vendor/domain	—	0
	P2	single-vendor but other uses	—	0
	P3	legacy/discontinued platform	—	0
Platform subtotal				0

Core Dimensions score: 28/100 — total cost = −72 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.2 Ecosystem coupling Dimensions

Dimension	Mechanism	Description	Present	Cost
Performance	R1	interpreted no AOT/JIT	—	0
	R2	GC pauses	✅	−8
	R3	JIT warmup	—	0
Performance subtotal				−8
Ecosystem	Ec1	no package manager	—	0
	Ec2	fragmented tooling	—	0
	Ec3	small/niche/discontinued	—	0
	Ec4	proprietary	—	0
	Ec5	platform-locked tooling	—	0
	Ec6	monoculture	—	0
	Ec7	legacy burden	—	0
Ecosystem subtotal				0
Evolution	V1	breaking changes	—	0
	V2	frozen	—	0
	V3	discontinued	—	0
	V4	glacial standards	—	0
Evolution subtotal				0
Domain	D1	domain/vendor lock-in	—	0
	D2	poor domain fit	—	0
	D3	framework forces architecture	—	0
Domain subtotal				0
Learning	L1	steep	—	0
	L2	large surface/multi-paradigm	—	0
	L3	sparse docs	—	0
Learning subtotal				0
Syntax	S1	verbose	—	0
	S2	inconsistent	—	0
	S3	punctuation-heavy	—	0
Syntax subtotal				0
Testing	G1	weak tooling	—	0
	G2	poor debugging	—	0
	G3	runtime-only errors	✅	−4
Testing subtotal				−4
Security	Q1	memory-unsafe	—	0
	Q2	dynamic/weak typing risk	✅	−8
	Q3	known vulnerability/injection	✅	−8
Security subtotal				−15 (−16)

Meta Dimensions score: 73/100 — total cost = −27 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.3 Engineering readiness Dimensions

Dimension	Mechanism	Description	Present	Cost
Reproducibility	Y1	build not reproducible	—	0
	Y2	dependencies not pinned	—	0
Reproducibility subtotal				0
Supply chain	Y3	no signed provenance	—	0
	Y4	registry without namespacing	✅	−4
Supply chain subtotal				−4
Observability	Y5	no stable tracing standard	—	0
	Y6	no structured logging	—	0
Observability subtotal				0
Feedback	Y7	slow build	—	0
	Y8	no fast in-editor analysis	—	0
Feedback subtotal				0
Interop	Y9	no foreign-function interface	—	0
	Y10	no portable target	—	0
Interop subtotal				0
Governance	Y11	single-vendor governance	—	0
	Y12	closed specification	—	0
Governance subtotal				0

Readiness Dimensions score: 96/100 — total cost = −4 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

Verdict: JavaScript’s dynamic nature defers all coupling detection to runtime. Prototypes and object literals provide flexibility but no guarantees. Global scope and unchecked errors create pervasive coupling. Main strength: object literals and prototypes are simple. Main weakness: no type system means coupling invisible until runtime.

---

The formal development. The definitions, theorems, and proofs behind this page are published in:

• On the Nature of Coupling: All Coupling as Shared Resource Access — Zenodo, 2026 — doi:10.5281/zenodo.21925122
• Coupling as a Consequence of Cohesion: Decomposition, the Coupling Floor, and Domain-Imposed Coupling — Zenodo, 2026 — doi:10.5281/zenodo.21925201
• On the Nature of Cohesion: Cohesion as Correctness Relative to a Partitioning Rule — Zenodo, 2026 — doi:10.5281/zenodo.21703193

All published papers

References

[1]

Y. Loth, “On the nature of coupling: All coupling as shared resource access.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925122.

[2]

Y. Loth, “Coupling as a consequence of cohesion: Decomposition, the coupling floor, and domain-imposed coupling.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925201.

[3]

Y. Loth, “On the nature of cohesion: Cohesion as correctness relative to a partitioning rule.” Zenodo, Jul. 2026. doi: 10.5281/zenodo.21703193.

[4]

ECMA International, “ECMAScript language specification.” ECMA International; Standard ECMA-262 (Edition 14), Geneva, Switzerland, 2023.

[5]

R. Pereira et al., “Energy efficiency across programming languages: How do energy, time, and memory relate?” in Proceedings of the 10th ACM SIGPLAN international conference on software language engineering (SLE), 2017, pp. 256–267. doi: 10.1145/3136014.3136031.

[6]

N. van Kempen, H.-J. Kwon, D. T. Nguyen, and E. D. Berger, “It’s not easy being green: On the energy efficiency of programming languages,” in Proceedings of the 40th IEEE/ACM international conference on automated software engineering (ASE), 2025. doi: 10.1109/ASE63991.2025.00131.

[7]

S. Joel, J. J. Wu, and F. H. Fard, “A survey on LLM-based code generation for low-resource and domain-specific programming languages,” ACM Transactions on Software Engineering and Methodology, 2025, doi: 10.1145/3770084.

[8]

Y. Qing et al., “EffiBench-x: A multi-language benchmark for measuring efficiency of LLM-generated code,” in Advances in neural information processing systems 38 (NeurIPS), datasets and benchmarks track, 2025. doi: 10.48550/arXiv.2505.13004.