こんにちは、KIYONOエンジニアです。
みなさん、普段当たり前に Node.js を使っていますよね。
npm install、ビルド、テスト、Next.jsの起動、CLIの実行……。
でも「Nodeってそもそも何？」「ランタイムって何？」を説明できますか？
この記事では、JavaScriptが“ブラウザの中だけの言語”だった時代から辿りながら、
なぜランタイムが必要になったのか、そして現在の代表的なランタイム（Node / Deno / Bun / Edge系）の違いと使い分けを整理します。
そもそも「ランタイム」とは何か？（よくある誤解から整理する）
まず最初に整理したいのは、ランタイムは「言語」でも「フレームワーク」でもないということです。
よくある誤解
- ❌ Node.js = JavaScriptという言語
- ❌ Node.js = Expressのようなフレームワーク
- ❌ Node.js = サーバーそのもの
これらはすべて微妙に違います。
言語・ランタイム・フレームワークの違い
| 概念 | 例 | 役割 |
| 言語 | JavaScript | 文法・書き方のルール |
| ランタイム | Node.js / Deno / Bun | その言語を「実行する環境」 |
| フレームワーク | Express / Next.js / NestJS | アプリを効率的に作るための設計テンプレート |
例えるなら、
- 言語 = レシピの書き方
- ランタイム = キッチン（コンロ・冷蔵庫・調理器具が揃っている場所）
- フレームワーク = よく使われる料理の型（テンプレート）
JavaScriptというレシピを書いても、
キッチン（ランタイム）がなければ実際には何も作れません。
ランタイムは「実行環境」である
ランタイムとは、コードを実際に「動かすために必要なもの一式」を指します。
JavaScriptの場合、ランタイムには大きく次の要素が含まれます。
- JavaScriptエンジン（コードを解釈・実行する部分）
- 標準API（ファイル操作、ネットワーク通信、タイマーなど）
- イベントループ（非同期処理を制御する仕組み）
- モジュール管理の仕組み
重要なのは、JavaScriptそのものには「ファイルを読む機能」は存在しないということです。
例えばこのコード：
const fs = require("fs");
fs.readFileSync("data.txt", "utf-8");
これは「JavaScriptの機能」ではありません。
これは Node.jsというランタイムが提供している機能 です。
つまり、
JavaScript = 言語仕様（ECMAScript）
Node.js = JavaScript + OSアクセスAPI + 実行基盤
という関係になります。
JavaScriptは“ブラウザでしか動かなかった”
JavaScriptは元々、ブラウザ上で動くことが前提の言語として普及しました。
ブラウザはHTML/CSS/JSを表示するために、次の機能を最初から持っています。
- DOM（画面）を操作するAPI
- HTTP通信（fetchなど）
- イベントループ（クリック、入力、非同期処理）
- セキュリティ制約（サンドボックス：ローカルファイルを勝手に触れない等）
つまり当時のJavaScriptは、「ブラウザという巨大なランタイムの上で動く言語」でした。
逆に言うと、ブラウザの外（サーバーやOS上）で動かすには、ブラウザ以外のランタイムが必要になります。
Node.jsとは何か（何がスゴいのか）
Node.jsは、ひとことで言うと 「サーバー/OS上でJavaScriptを動かすためのランタイム」です。
そしてNodeが革命だった点は、単に「JSがサーバーで動く」だけではありません。
Node.jsが提供した価値
- OS機能へアクセスできるAPI（ファイル、プロセス、TCP/HTTPなど）
- イベントループ + 非同期I/Oが得意（大量のI/O処理と相性が良い）
- npmによる巨大なエコシステム（依存管理が標準化）
- フロントと同じ言語でサーバーを書ける（人・知識・ライブラリが共有される）
Node.jsは何で動いている？（ざっくり構造）
- JavaScriptエンジン：V8
- 非同期I/O：libuv（イベントループやI/O抽象化）
- Node API：fs / http / crypto など
- パッケージ：npm（今はpnpm/yarnも含めた“文化”になっている）
ランタイムの種類：Node / Deno / Bun
現在の“サーバーサイドJavaScript”の代表的なランタイムは以下です。
| ランタイム | 思想/特徴 | 強み | 注意点 |
| Node.js | 最も普及。歴史・互換性・エコシステムの中心 | npm資産、情報量、ライブラリ/フレームワークの対応が圧倒的 | 設定やツールが増えがち（プロジェクト規模で複雑化） |
| Deno | “Web標準寄り” + セキュリティ志向。近年はNode互換も重視 | 標準でTypeScript、権限管理、ツール内蔵（fmt/lint/testなど） | Node互換は改善中（とはいえ動く範囲は年々広がる） |
| Bun | “速さ”と“全部入り”志向（runtime + bundler + test + package） | 高速起動/高速I/O、開発体験がシンプル、統合ツールが強い | 急速に成熟中。巨大プロダクトでは検証・運用ノウハウがまだ浅い領域も |
それぞれの強み・使うべき場面
Node.js を選ぶべき場面
- 既存のnpmライブラリに強く依存している
- チームの運用知見、デプロイ先、監視、トラブルシュートがNode前提
- Next.js/NestJS/Expressなど、Node中心のフレームワークを使う
- “まず確実に動く”ことが重要（採用・保守・長期運用）
Deno を選ぶべき場面
- Web標準API中心で実装したい（fetch, URL, Web Streams など）
- セキュリティ（権限）を強めたい（例：ファイルアクセスを明示的に許可）
- TS/フォーマット/テストなどを“標準装備”で揃えたい
- 将来的にNode互換も活かしつつ、DXを軽くしたい
Bun を選ぶべき場面
- 起動・ビルド・インストール速度を効かせたい（CI時間短縮など）
- “全部入り”で開発体験を簡略化したい（bundler/test/packageを統合）
- プロトタイプ〜中規模で、検証しながら速度メリットを取りにいきたい
結局どれが人気？（現状の立ち位置）
現時点の肌感としては、Node.jsが圧倒的にデファクトです。
一方で、BunやDenoは「Node互換を強めつつ、DXや性能で差別化」する流れが強く、特にBunは“2番手として存在感が増している”という見方もよく見ます。
- Node.js：当面は中心（エコシステムが巨大）
- Bun：速度と統合ツールで伸びやすい（採用検討が増える）
- Deno：Web標準 + セキュア設計、互換改善で使いどころが増える
まとめ
- JavaScriptは元々“ブラウザの中で動く言語”で、ブラウザ自体が巨大なランタイムだった
- サーバー/OS上でJSを動かすためにNode.jsが登場し、エコシステム（npm）と合わせて普及した
- 今は Node / Deno / Bun など選択肢が増え、目的に応じて使い分ける時代
ここまで読んでいただきありがとうございました！
