The Next Generation of Server-Side JavaScript Runtimes: Node.js, Deno and Bun
Metadane
- Autorzy: Juuso Laakso
- Rok: 2025
- Źródło: Bachelor’s Thesis UAS, Turku University of Applied Sciences (Turku AMK), Business Information Technology
- URL: http://www.theseus.fi/bitstream/10024/905982/2/Laakso_Juuso.pdf
- Strony: 43
- Status: read
- Kategoria główna: Systems
- Podkategorie: JavaScript Runtimes, Benchmarking, Performance, Software Engineering
- Tagi:
#javascript#nodejs#deno#bun#runtime#benchmark#performance#typescript#serverless#edge-computing#project:js-runtime-energy
Streszczenie
Praca licencjacka badająca ewolucję i przyszłość serwerowych środowisk uruchomieniowych JavaScript — Node.js, Deno i Bun. Łączy przegląd literatury z praktycznymi benchmarkami (MacBook Air M2, 16GB) w 4 kategoriach: HTTP throughput, File I/O, JSON stringify/parse, CPU-bound operations.
Kluczowe wnioski: Bun konsekwentnie dominuje we wszystkich benchmarkach (JavaScriptCore engine, napisany w Zig), Deno przy native API osiąga poziom Node.js (V8, Rust/Tokio), brak jednej “najlepszej” opcji — wybór zależy od priorytetów projektu. State of JavaScript 2024: Node.js 90.8%, Bun 16.4%, Deno 11.8% użycia.
Ważne zastrzeżenie: To praca licencjacka (UAS), nie recenzowany artykuł naukowy. Metodologia benchmarkingu jest uproszczona (10 powtórzeń, best result). Dane traktować jako punkt wyjścia, nie jako autorytatywne wyniki badań.
Kluczowe Wnioski
- Bun lider wydajności we wszystkich testach: HTTP (+42% vs Node.js), File I/O (-32% czasu), JSON (-49% czasu), CPU-bound (-34% czasu)
- Deno ≈ Node.js przy native API; overhead kompatybilności Node.js w Deno widoczny w HTTP (-16% vs Node.js przy node:http API)
- JavaScriptCore (Bun) vs V8 (Node.js, Deno): różne silniki JS to kluczowy czynnik wydajności
- Bun 1.2 (Jan 2025): 99% kompatybilności z Node.js API → drop-in replacement możliwy
- Deno 2 (Oct 2024): NPM specifiers, lepsza kompatybilność z ekosystemem Node.js
- State of JavaScript 2024 (11,576 respondentów): Node.js 90.8%, Browser 83.2%, Bun 16.4%, Service Workers 15.6%, Deno 11.8%
- Deno: bezpieczeństwo-first (permission model —allow-*), ale overhead sprawdzania uprawnień minimalny dla większości workloadów
- Bun: napisany w Zig (low-level, manual memory mgmt, max speed), 20× szybszy package manager vs NPM
Metodologia (benchmarki)
Środowisko: MacBook Air M2 (Apple Silicon), 16GB RAM, brak aplikacji w tle
Protokół (nieformalne): 10 powtórzeń na test, zapisywany najlepszy wynik
Narzędzie HTTP: autocannon (NPM package), 10 klientów, 10 sekund
Testy:
- HTTP requests/sec — simple JSON server (node:http API)
- HTTP requests/sec — Deno native API (Deno.serve)
- File I/O — 1000 plików po 1KB (read + write)
- JSON — stringify + parse obiektów user data (wiele iteracji)
- CPU-bound — Fibonacci(35) + sort array (100 przebiegów)
Ograniczenia: Best-of-10 (nie median), Apple M2 (JavaScriptCore = silnik Safari = Bun na własnym podwórku?), bez izolacji procesów, bez PowerJoular/energii.
Główne Koncepcje
- Node.js: Created 2009 by Ryan Dahl; V8 engine (Google); event-driven non-blocking I/O; NPM ecosystem (largest package registry); C++ core
- Deno: Created 2020 by Ryan Dahl; V8 engine; Rust + Tokio async runtime; permission-based sandbox (—allow-read/write/net/env); native TypeScript; URL imports → JSR (2025)
- Bun: Created 2021 by Jarred Sumner (Oven.sh); JavaScriptCore (Apple Safari engine); Zig language; built-in test runner, bundler, transpiler, package manager; 99% Node.js API compat (v1.2)
- JavaScriptCore vs V8: Apple Safari vs Google Chrome engine — różne charakterystyki JIT compilation → Bun ma inne (często lepsze) performance profile
- Zig: Low-level systems language — manual memory management, brak GC overhead, kompiluje do native code
- JSR (JavaScript Registry): Nowy rejestr Deno (2025) — TypeScript-first, type-checked packages, alternatywa dla NPM
- Deno.serve API: Natywne HTTP API Deno (vs kompatybilność node:http) — wyraźnie szybsze, bo brak warstwy translacji
- PLATYPUS mitigation: Kernel ograniczył RAPL access — nie wspomniany w tej pracy (brak pomiaru energii)
Wyniki (dane liczbowe)
HTTP Requests per Second (autocannon, 10 clients, 10s):
| Runtime | node:http API | Native API |
|---|---|---|
| Bun | 103,821 | 103,821 |
| Node.js | 73,009 | 73,009 |
| Deno | 61,446 | 72,941 |
Deno native API (Deno.serve) ≈ Node.js (73,009 vs 72,941).
File I/O (1000 plików, 1KB each):
| Runtime | Read [ms] | Write [ms] | Total [ms] |
|---|---|---|---|
| Bun | 8.51 | 28.48 | 37.67 |
| Node.js | 18.26 | 47.28 | 55.86 |
| Deno | 9.05 | 54.07 | 72.49 |
Uwaga: Deno wolny zapis (54ms) vs szybki odczyt (9ms) — prawdopodobnie overhead uprawnień przy write.
JSON Stringify + Parse:
| Runtime | Stringify [s] | Parse [s] | Total [s] |
|---|---|---|---|
| Bun | 1.80 | 3.80 | 5.60 |
| Deno | 2.05 | 5.49 | 7.53 |
| Node.js | 4.80 | 6.19 | 10.99 |
JSON: Bun > Deno > Node.js — Deno i Bun oba lepsze od Node.js.
CPU-bound (Fibonacci 35 + sort 100×):
| Runtime | Fibonacci [ms] | Sort 100× [ms] | Total [ms] |
|---|---|---|---|
| Bun | 44.22 | 146.34 | 190.57 |
| Node.js | 67.68 | 219.71 | 287.49 |
| Deno | 68.16 | 237.33 | 305.57 |
CPU: Bun wyraźnie szybszy (JavaScriptCore), Node.js ≈ Deno (oba V8).
Przydatne Cytaty
“Node.js remains the established industry standard, its position earned through a long track record of use, a vast and mature ecosystem, and a large global talent pool.” (Chapter 6)
“Bun has clearly established itself as the clear leader in performance, consistently outperforming both Node.js and Deno across benchmarks.” (Chapter 6)
“Deno started from a direct critique of Node.js’s original design, successfully delivering on its promise of a more secure by default and modern development experience.” (Chapter 6)
“Bun 1.2 had achieved ninety-nine percent compatibility with Node.js built-in modules.” (Section 2.4, citing Partovi 2025)
“The results show that Bun could achieve startup times approximately three times faster than Node.js.” (Section 2.4, citing Ahmod 2023)
“Can runtime-level performance continue improving, or are gains primarily limited by the underlying JavaScript engines (V8, JavaScriptCore)?” (Section 6.1 Future Work)
Datasety
- Własne benchmarki (MacBook Air M2), kod: https://github.com/Ducky07/js-runtime-snapshot/tree/11-2025
- State of JavaScript 2024 survey (11,576 respondents): https://2024.stateofjs.com/en-US/other-tools/#runtimes
- W3Techs Node.js usage statistics 2025: https://w3techs.com/technologies/details/ws-nodejs
Powiązane Tematy
- Kontekst dla JE-2 (Bun vs Deno vs Node.js wydajność): benchmark data jako punkt wyjścia
- Gap energetyczny (bezpośredni): praca nie mierzy energii — luka badawcza JE-1 identyczna z naszą tezą
- JavaScriptCore vs V8 → hipoteza: Bun może być energetycznie efektywniejszy dzięki różnemu engine (ale M2 = Apple Silicon = JavaScriptCore advantage na własnej platformie)
- Deno native API vs node:http compatibility layer → implikacja: benchmarki muszą używać native API każdego runtime, nie wspólnego compatibility wrapper
- Future work w tej pracy → dokładnie pytania badawcze projektu js-runtime-energy: energy, długoterminowa stabilność, production case studies
- Albonico 2025 — analogiczna metodologia (ale brak energii w Laakso); wzorzec do ulepszenia
- Smirnov 2024 (w references/) — podobny zakres porównania, prawdopodobnie rosyjski journal
Notatki
Praca licencjacka (nie peer-reviewed). Użyj danych jako punktu odniesienia dla benchmark design i jako motywację dla energy gap. Cytuj jako “grey literature” lub unikaj cytowania w favor of peer-reviewed sources (Ahmod 2023, Smirnov 2024).