Node.js入門」という書籍でした。執筆に使ったNode.jsのバージョンが古かったり、大勢の著者で分担して書いたので、各章に統一感がなかったりといったところで、著者としても若干不本意なところが残ってしまったんです。そこで、本の内容をフォローするために、著者がNode.jsについて教える勉強会をやろうということになったんですね。複数回に分けて開催し、参加者には全回への出席と課題提出が求められるという、わりとスパルタなものだったのですが、そこに古川さんが参加してくださったんです。古川:ええ、つまり僕はNode.jsを大津さんから教わったんですよ(笑)。Asiaでは、私と大津さんで「Node.jsの分裂と統合の行方」という発表をやりました。大津:懐かしいですね。SIer、ISPなどを経て現職。ヤフーでは、CDNチームに所属し、IETF標準化などにも参加。同社内で「特定分野について突出した知識とスキルを持っている第一人者」として実績を上げている優秀な人財に与えられる称号「黒帯(ネットワーク・セキュリティ)」保持者でもある。Node.jsのコミッターであり、TLS、Crypto周りの実装を数多く手がける。Node.js入門」(共著、アスキー・メディアワークス刊)がある。大津:ちょっと、今日の対談の参考になるかと思って、昔作ったNode.jsに関する簡単な年表を持ってきました。先ほどの書籍が出たのが2012年、「東京Node学園」が初めて開催されたのが2011年。Node.js自体は2009年に「v0.0.1」がリリースされていたのですが、この7年くらいの間に急激に盛り上がってきた感じなんですね。Node.jsの歩み(2012年の大津氏の勉強会発表資料より)白石:そう考えると、Node.jsの歴史も結構長いですね。正直なところ、私は最初のころ「サーバサイドJavaScriptなんて絶対流行らない」と思っていたんですよ(笑)。白石:というのも、それまでにもそういったサーバサイドJavaScriptのフレームワークって、いくつか出てきていたんですよ。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学園」やNode.jsの祭典「東京Node学園祭」の運営も行う。Node.jsに「Perl」をコミット?白石:この3人だと「Node.js昔話」だけで何時間も話せてしまいそうなので、少しずつ最近のことに話題を移しましょう。現在、お二人はNode.js上でどんな言語を使っておられますか。古川:JavaScriptです。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標準技術に関するコンサルティングや開発を手がける。Experts.jp」(https://html5experts.jp/)初代編集長。日本最大のHTML5開発者コミュニティ「html5j」ファウンダー、2014年7月までコミュニティリーダーを務める。Gearsスタートガイド」(技術評論社刊)など。Mobile」(オライリージャパン刊)など。「Node.js」のリリースサイクル、ロードマップはどうなっている?白石:大津さんも古川さんも、Node.jsの「中」に深く関わっていらっしゃるのですが、プロダクトの現状について簡単に説明をお願いします。Current」がリリースされましたね。Support)を行っていくという方針になっています。今後のロードマップとしては、後方互換性を保ちながら、エッジな技術もサポートしていくという形ですね。Modulesだとか、HTTP/2だとか、QUIC(クイック)などについても取り組んで行くだろうと思っています。白石:Node.jsには、公開されている正式なロードマップのようなものはあるんですか?大津:個々にやりたいことをまとめているものはあるのですが、公式なものはないですね。コミュニティが厳格に守ろうとしているのは「セマンティックバージョニング」についてです。後方互換性がないAPIの変更が入る場合にはメジャーバージョン、後方互換性が担保される機能追加が行われた場合にはマイナーバージョン、後方互換性のあるバグフィックスが行われた場合にはパッチバージョンがそれぞれ上がるというルールですね。以前は、頻繁にAPIが変更されていたのですが、セマンティックバージョニングが徹底されるようになってからは、ある程度、安心して使えるようになってきています。古川:今は以前に比べるとかなり落ち着いていますね。逆に、チャレンジングなことができなくなっているという側面もあって、そこに不満を感じる人もいるようですが。白石:たしかに、Node.jsを使っていて後方互換性の問題で悩まされることは、あまりないように感じます。古川:C/C++でネイティブモジュールを作るような人だと困ることがあるかもしれませんが、それ以外ではあまり大きな問題はないのではないでしょうか。大津:スモークテストもバックグラウンドで走っていますからね。必要なライブラリをすべてチェックして、後方互換が崩れることで、どこにどんな問題が出そうかというところまで把握した状態でリリースする体制になっています。あと、npmの中の人たちが、どのモジュールがどこでどのように使われているかというのもきっちり調べてレポートしてくれたりもしています。コミュニティベースになってからは、互換性について、とても気を遣っている印象があります。白石:ここで、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」に戻りました。Foundation傘下に収まったのは2014年でした。私がコミッターになって少し後のことです。Node.jsの登録商標自体は現在もJoyentが保有しているのですよ。白石:なるほど、そんな経緯だったのですね。した歴史を踏まえた上で、現状のNode.jsコミュニティの状況について、どのように感じていらっしゃるのかをお聞きしたいのですが。古川:コミュニティ規模の話で言えば、世界的には確実に大きくなっているし、日本でも、JavaScript関連のカンファレンスでは、必ずNode.jsについてのセッションがあるような状況です。Associationが運営している「東京Node学園祭」は、毎回400~500人規模の集客が見込めるイベントになっており、このまましばらく拡大傾向は続いていくだろうと見ています。フロントエンドとサーバサイドの垣根がなくなってきて、それがコミュニティの成長を後押ししている感じはあります。Apps」といったメジャーなPaaSが、こぞってNode.jsをサポートするようになったことが大きいですね。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を思い出してしまいます。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などとの大きな違いです。TweetCodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。