普及期を終え成熟期に入った「Node.js」はこれからどうなる？－コミッターが語る現状と未来【前編】

　サーバサイドJavaScriptのための環境として登場した「Node.js」は、今やクライアント環境でのJavaScriptランタイムとしてもポピュラーなものとなっています。その開発はどのようなプロセスで進められており、今後はどのような形で進化していくのでしょうか。今回、Node.jsのコミッターであるヤフーの大津繁樹氏と、「Japan Node.js Associations」の代表理事を務める、リクルートテクノロジーズの古川陽介氏に、それぞれの立場から「Node.js」の現状と未来について語っていただきました。モデレーターは、テックフィード代表取締役の白石俊平氏が務めます。本稿は2部構成の【前編】です。

日本の「Node.js」コミッターには実は意外なつながりが？

白石：今回は、Node.jsのコミッターである大津さんと古川さんに、Node.jsの現在と未来について語っていただきたいと思います。よろしくお願い致します。

大津：よろしくお願いします。お二人とは、知り合ってずいぶん経ちますね。ちなみに、白石さんと私が最初に会ったのって、いつだったか覚えていらっしゃいますか？

　実は私、2011年に「html5j」が開催した「第0回 HTML5プログラミング＆クリエイティブ コンテスト」に「HTML5 Radio」という作品を出しまして、最優秀賞をいただいたんです。その表彰式だった同年の4月15日が初対面でした。

白石：懐かしい！ イベントをやったのは覚えているのですが、それが大津さんと初めて会った日だというのはすっかり忘れていました（笑）。

大津：私がWeb系のことを本格的に始めて、勉強会などにも頻繁に顔を出すようになったのが、ちょうどその時期だったんですよ。Node.jsも、その少し前くらいに触り始めていました。その後、白石さんが関わってらっしゃった「Web先端味見部」や「とか勉（HTML5とか勉強会）」などでSPDYに関して話す機会があって、そのあたりが、その後のHTTP/2の標準化に関わることにもつながったんです。

白石：そうだったのですか。それは嬉しいなぁ。

古川：僕の中では「大津さんはNode.jsの人」というイメージなんですが、もともと、ネットワークやプロトコルに関してもお好きだったんですか。

大津：そのあたりは右往左往しているのですが（笑）、ネットワークについては昔から好きでしたね。そういえば、古川さんと初めてお会いしたのは「Node.js 道場」でした。

古川：はい。

大津：この勉強会は2012年にあったのですが、きっかけは、私が共著で書かせて頂いた「サーバサイドJavaScript Node.js入門」という書籍でした。執筆に使ったNode.jsのバージョンが古かったり、大勢の著者で分担して書いたので、各章に統一感がなかったりといったところで、著者としても若干不本意なところが残ってしまったんです。

　そこで、本の内容をフォローするために、著者がNode.jsについて教える勉強会をやろうということになったんですね。複数回に分けて開催し、参加者には全回への出席と課題提出が求められるという、わりとスパルタなものだったのですが、そこに古川さんが参加してくださったんです。

古川：ええ、つまり僕はNode.jsを大津さんから教わったんですよ（笑）。2015年のYAPC Asiaでは、私と大津さんで「Node.jsの分裂と統合の行方」という発表をやりました。

大津：懐かしいですね。

大津 繁樹（おおつ・しげき）氏

　ヤフー株式会社 システム統括本部 サイトオペレーション本部所属。大学教員から、SIer、ISPなどを経て現職。ヤフーでは、CDNチームに所属し、IETF標準化などにも参加。同社内で「特定分野について突出した知識とスキルを持っている第一人者」として実績を上げている優秀な人財に与えられる称号「黒帯（ネットワーク・セキュリティ）」保持者でもある。Node.jsのコミッターであり、TLS、Crypto周りの実装を数多く手がける。著書に「サーバサイドJavaScript Node.js入門」（共著、アスキー・メディアワークス刊）がある。

Node.jsのキラーアプリとなった「Socket.IO」

大津：ちょっと、今日の対談の参考になるかと思って、昔作ったNode.jsに関する簡単な年表を持ってきました。先ほどの書籍が出たのが2012年、「東京Node学園」が初めて開催されたのが2011年。Node.js自体は2009年に「v0.0.1」がリリースされていたのですが、この7年くらいの間に急激に盛り上がってきた感じなんですね。

白石：そう考えると、Node.jsの歴史も結構長いですね。正直なところ、私は最初のころ「サーバサイドJavaScriptなんて絶対流行らない」と思っていたんですよ（笑）。

一同：（笑）。

白石：というのも、それまでにもそういったサーバサイドJavaScriptのフレームワークって、いくつか出てきていたんですよ。「Rhino」とか「Aptana Jaxer」とか。Jaxerなんかは、Geckoをベースにしていて、サーバサイドでブラウザを使ってレンダリングし、DOMの文字列を返すという、無茶苦茶マニアックな仕組みで動いていたんです。

大津：スゴイですね（笑）。

白石：そうなんです。Ajaxなんかにも対応していて、スゴイことはスゴかったのですが、全然流行らなかったんです（笑）。そんな感じでサーバサイドJavaScriptが次々と討ち死にしていく様子を見ていて、Node.jsについても同じような末路をたどるだろうと感じてしまったんですね。当時は、イベントドリブンだったり、非同期処理でパフォーマンスにも優れていたりといったNode.jsの特長を知らなかったというのもあるのですが。

大津：2011年あたりを境に急に盛り上がり始めたのは、WebSocketの仕様が決まって、Node.js上で動くSocket.IOが出てきたのが大きかったと思いますね。あの仕組み、Node.jsと相性がバッチリだったんです。

古川：たしかに、Socket.IOはキラーアプリでした。

白石：フロントエンドでHTML5を扱っているエンジニアの視点だと「WebSocketという新しい仕様が面白そうなんだけれど、サーバ側でいろいろやることがあって面倒だな」という思いがあったんです。あと、ブラウザ側でのWebSocket対応状況がまちまちだったというのも、すぐにWebSocketに手を出せない理由の一つだったように思います。

　そこにSocket.IOが出てきたことで、フロントもサーバも、どちらもJavaScriptで何とかできるという世界ができたのが、ユーザーを増やす上では大きかったですね。

古川 陽介（ふるかわ・ようすけ）氏

　大手複合機メーカー、大手携帯ゲーム会社を経て、2016年より株式会社リクルートテクノロジーズに参加。現在はグループマネージャーとしてメンバー教育、Webアプリ作成用のユーティリティツールやフレームワークの開発を手がける。Node.js Evangelism/Collaborator/benchmark Working Group所属。日本やアジア地域におけるNode.js普及を目的とした組織「Japan Node.js Associations」の代表理事であり、海外での公演活動、勉強会「東京Node学園」やNode.jsの祭典「東京Node学園祭」の運営も行う。

Node.jsに「Perl」をコミット？

白石：この3人だと「Node.js昔話」だけで何時間も話せてしまいそうなので、少しずつ最近のことに話題を移しましょう。現在、お二人はNode.js上でどんな言語を使っておられますか。

古川：JavaScriptです。最近では、Reactを使ったSSR（Server Side Rendering）などもやっているのですが、その際は、メンバーの要望もあってflowtypeとBabelなどを組み合わせて使っています。

大津：私はNode.jsの「上」では、JavaScriptしか使っていないです。しかも、ES2015にまだ慣れていなくて、ほぼES5世代の書き方です。

　あと、私の場合はNode.jsの「中」も書くのですが、その場合はC/C++。たまにPython、Perlといった感じです。この間、勉強会でも話したのですが、Node.jsにPerlをコミットしたのは、たぶん私だけです（笑）。

白石：Perlで何を書いたんですか？

大津：Node.jsではOpenSSLのバインディングを担当しているのですが、それがPerlベースのビルドなんですよ。そのため、PerlからNode.jsのビルドシステムに書きかえるツールを中に組み込んでいます。OpenSSLに脆弱性が見つかってバージョンアップされると、Node.js側でのバージョンアップ作業を私がやっています。

　Pythonもビルド関連ですね。Node.jsをビルドするためのツールである「GYP」がPythonで動くので、そのための仕組みをコミットしてます。割と「縁の下」のような地味な仕事ですけれど。

白石：はー。スゴイ作業をやっておられるんですね。

古川：Node.jsの「中」という意味だと、僕は中でもJavaScriptですね。Node.jsの標準APIの仕様について「これ、おかしくない？」みたいな議論をしていることが多いです。あ、あとNode.jsにESLintを入れたのは僕です。

白石：あ、そうなんですか。それもスゴいですね。

大津：だから、Node.jsをmakeしてLintエラーが出てきたら、古川さんのせいです（笑）。

古川：以前のNode.jsって、Googleのコーディングスタイルを採用していて、ES5しか書けなかったんです。そのあたりを何とかしたいと思ってESLintを入れ、ES2015でも書けるようにしたんですね。

　ESLintを使って、Googleのコーディングスタイルを置き換えていくという作業を1つずつやっていったんですが、書き方に対するそれぞれの「思い」を調整してまとめていく作業に、非常に手間がかかったのを覚えています。

白石 俊平（しらいし・しゅんぺい）氏

　株式会社テックフィード代表取締役。Web標準技術に関するコンサルティングや開発を手がける。Web技術者向け情報メディア「HTML5 Experts.jp」（https://html5experts.jp/）初代編集長。 日本最大のHTML5開発者コミュニティ「html5j」ファウンダー、2014年7月までコミュニティリーダーを務める。Google 社公認 Developer Expert (HTML5)、Microsoft 社公認 Most Valuable Professional (IE)などを歴任。著書に「HTML5＆API入門」（日経BP刊）、「Google Gearsスタートガイド」（技術評論社刊）など。監訳に「実践 jQuery Mobile」（オライリージャパン刊）など。

「Node.js」のリリースサイクル、ロードマップはどうなっている？

白石：大津さんも古川さんも、Node.jsの「中」に深く関わっていらっしゃるのですが、プロダクトの現状について簡単に説明をお願いします。

古川：バージョンで言うと、つい最近「10.5.0 Current」がリリースされましたね。リリースサイクルとしては、半年に1回、メジャーバージョンアップを行って、メジャーバージョンが偶数番号のものについてはリリース後2年間のLTS（Long Term Support）を行っていくという方針になっています。

　今後のロードマップとしては、後方互換性を保ちながら、エッジな技術もサポートしていくという形ですね。ES Modulesだとか、HTTP/2だとか、QUIC（クイック）などについても取り組んで行くだろうと思っています。

白石：Node.jsには、公開されている正式なロードマップのようなものはあるんですか？

大津：個々にやりたいことをまとめているものはあるのですが、公式なものはないですね。コミュニティが厳格に守ろうとしているのは「セマンティックバージョニング」についてです。

　後方互換性がないAPIの変更が入る場合にはメジャーバージョン、後方互換性が担保される機能追加が行われた場合にはマイナーバージョン、後方互換性のあるバグフィックスが行われた場合にはパッチバージョンがそれぞれ上がるというルールですね。

　以前は、頻繁にAPIが変更されていたのですが、セマンティックバージョニングが徹底されるようになってからは、ある程度、安心して使えるようになってきています。

古川：今は以前に比べるとかなり落ち着いていますね。逆に、チャレンジングなことができなくなっているという側面もあって、そこに不満を感じる人もいるようですが。

白石：たしかに、Node.jsを使っていて後方互換性の問題で悩まされることは、あまりないように感じます。

古川：C/C++でネイティブモジュールを作るような人だと困ることがあるかもしれませんが、それ以外ではあまり大きな問題はないのではないでしょうか。

大津：スモークテストもバックグラウンドで走っていますからね。必要なライブラリをすべてチェックして、後方互換が崩れることで、どこにどんな問題が出そうかというところまで把握した状態でリリースする体制になっています。

　あと、npmの中の人たちが、どのモジュールがどこでどのように使われているかというのもきっちり調べてレポートしてくれたりもしています。コミュニティベースになってからは、互換性について、とても気を遣っている印象があります。

「Node.js」コミュニティがたどってきた紆余曲折

白石：ここで、Node.jsがコミュニティベースになったあたりの経緯を整理しておきましょうか。最初はクラウド事業をやっている「Joyent」という企業が作っていたのでしたっけ。

古川：ライアン・ダールが最初に作ったときは、彼自身のプロダクトですね。その後、ダールがJoyentに就職して開発を続けたので、Joyentが主幹としてバックアップするプロダクトになりました。

　そのまましばらく開発が続いていたのですが、2014年の12月に「io.js」というforkが生まれて、「Joyent傘下のNode.js」と「コミュニティベースのio.js」に分裂してしまったんですね。

白石：そこでちょっと混乱がありましたね。

大津：分裂の原因ですが、Joyent傘下でのNode.jsが保守的すぎることに対する開発者たちの不満があったようです。3代目の管理者はJoyentの社員だったのですが、この管理者に変わってから、しばらくNode.jsのリリースが停滞してしまったんです。

　Joyentは企業ですから、既存のお客さんを重要視します。そのため、許されるのはバグフィックスだけで、後方互換性を壊すような新機能のリリースがまったく認められなくなったんですね。バージョン0.10のころですが、開発は続いているものの、次のメジャーバージョンがリリースがされないという時期が2年近く続きました。

　コミッターも増やさず、リリースもされず、リポジトリにはIssueとプルリクエストがどんどん積み上がっていくという状況に業を煮やしたコミッターたちがforkでio.jsを作ってしまったというのが、当時の経緯です。

古川：結局、バージョン1は「io.js」としてリリースされたんですよね。その後、再合流後のバージョン4で「Node.js」に戻りました。

大津：両者が合流して、Linux Foundation傘下に収まったのは2014年でした。私がコミッターになって少し後のことです。ただ、Node.jsの登録商標自体は現在もJoyentが保有しているのですよ。

白石：なるほど、そんな経緯だったのですね。そうした歴史を踏まえた上で、現状のNode.jsコミュニティの状況について、どのように感じていらっしゃるのかをお聞きしたいのですが。

古川：コミュニティ規模の話で言えば、世界的には確実に大きくなっているし、日本でも、JavaScript関連のカンファレンスでは、必ずNode.jsについてのセッションがあるような状況です。

　Japan Node.js Associationが運営している「東京Node学園祭」は、毎回400～500人規模の集客が見込めるイベントになっており、このまましばらく拡大傾向は続いていくだろうと見ています。だんだんと、フロントエンドとサーバサイドの垣根がなくなってきて、それがコミュニティの成長を後押ししている感じはあります。

大津：ユーザーベースの拡大という観点では、「Google App Engine」「AWS Lambda」「Azure Web Apps」といったメジャーなPaaSが、こぞってNode.jsをサポートするようになったことが大きいですね。Joyentという特定企業のプロダクトをサポートするのには腰が引けていたベンダーが、Linux Foundationの傘下に入り「自分たちもものが言える」体制になったことで積極的にサポートするようになったという流れです。

　こうした流れは、Node.js自体の開発にも良い影響を与えています。現在、GoogleがNode.jsをファーストクラスでサポートしているのですが、これによってV8エンジンのバージョンアップ作業が以前よりも効率的になりました。前はV8のバージョンを上げるのがとても大変だったんですよ。V8がリリースされる直前の段階になってから、Node.jsのほうが後追いで変更による影響範囲を確認して対応するといったことをやっていたんですね。

　今はV8の開発者もコミッターに入っているので、リアルタイムでCIを回して、影響がありそうなAPIの変更を事前にバックポートしてくれるようになっています。開発体制が一体化してきていることで、V8に対するNode.js側のオーバーヘッドはほぼなくなっています。

「安定」と「進化」の両立は難しい？－Node.jsのコミュニティプロセス

白石：今のNode.jsに対して良いと思っていること、逆に不満に感じていることを特に挙げるとしたら何でしょう。

古川：先ほども少し話に出ましたが、安定した形でバージョンアップが行われているのは良い点でしょうね。ビルドやCI周辺のプロセスがしっかりしていることで、リリース時にバグが混入する割合も、以前より減っていると思います。

　JavaScript系のコミュニティには、あまり安定性や後方互換性を重視しないところもあるじゃないですか（笑）。そうしたプロダクトと比べると、Node.jsは安定しているほうだと思います。

大津：それには、これまでのNode.jsの歴史も影響していますよね。ただ、安定性や互換性を重視するそうした体制が、ひずみを生んでいる側面もあるように感じます。例えば、現状のNode.jsでは、APIを1つ変えるのにも、かなり大がかりなプロセスが必要なんですよ。

古川：たしかに、「不満」を挙げるとすれば、そういった部分かもしれません。1つ変更しようと思うとかなりのエネルギーが必要になるんです。

　「これ、本質的におかしくない？」みたいなことを言っても、「うーん、それを変えるとメジャーバージョンアップになっちゃうし…」「ユースケースがそれほど多くないなら無理して変えなくてもよくない？」みたいな意見が出てきて、最終的に黙ってしまうみたいな（笑）。何かを変えるために必要な議論のコストが、変えた結果から得られるベネフィットに見合わなくなっているようなところは、あちこちに出てきていますね。

白石：それは、議論のプロセスに何らかの問題があるということなのですか。

大津：いや、違いますね。そういう「文化」なんですよ。

古川：他のプロジェクトの場合、どちらかというと「優しい独裁者」が存在するケースが多いと思うのですが、Node.jsは、それらに比べると徹底した「民主主義」に近く感じます。

大津：例えば、あるテーマについて、コミッター同士の意見が分かれると、判断が上位組織に委ねられて、それでも結論が出なければ投票で決定するというように「話し合って決定する」ためのプロセスが、ガバナンスが保てる形でかなりきっちり決まっていますね。

白石：コミュニティプロセスの問題というと、私はどうしても、以前関わっていたJavaを思い出してしまいます。サン・マイクロシステムズのオラクルによる買収などがあった影響で、Java 6以降、しばらくの間、完全にコミュニティプロセスが停止してしまったんですね。Node.jsにはああいったことは起こってほしくないと願っているのですが。

大津：Node.jsのような最近のOSSと昔のOSSの違いとしては、GitHubをベースとしてコミュニティが形成されてきたかどうかというのが大きい気がします。issueやプルリクエスト、コミットやフォークというGitHubの使い方が、そのまま、コミュニティのプロセスと文化を形成しているのです。

　例えば先ほどの「Node.jsとio.jsの分裂」なども、GitHub上では単に「fork」で新たなリポジトリが生まれたに過ぎず、そちらで開発は続いていったわけです。その意味で、壊滅的なコミュニティプロセスの破綻は、以前よりも起こりにくくなっているのではないでしょうか。

白石：先ほど、Node.jsのプロセスは「民主主義」だというお話しが出ましたが、それは進化の停滞にはつながりませんか。

大津：Node.jsそのものが、この先ドラスティックに変わるかと聞かれれば、たしかにそれはないかもしれないです。ただ、進化は今後、Node.jsの周辺で生まれていくだろうと思います。

　さらに、Node.jsのベースとなる言語、つまりJavaScript（ECMAScript）は、そちらで別の進化を続けていますよね。それに合わせて進化していくプラットフォームという意味で、Node.jsの魅力はなくならないと思います。

白石：言われてみると、言語はECMAが仕様を作り、エンジンはGoogleが作っていて、その上に乗るプラットフォームという意味で、Node.jsはとてもユニークな立ち位置にいますよね。

大津：ええ。そこが、PerlやPythonなどとの大きな違いです。

（後編へ続く）

---

著：高橋美津
写真：小倉亜沙子