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

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

（前編はこちら）

---

フロントエンドにも広がる「Node.js」のエコシステムをどう生かす？

白石：では、このあたりから実際にNode.jsを開発現場でどのように使っていらっしゃるかについてお伺いしたいと思います。古川さんは、フロントエンド開発者としての立場で、現在Node.jsをどのように見ていらっしゃいますか。

古川：フロントエンド側でも、Node.jsを利用しているフレームワークやライブラリはどんどん増えていますね。実際にWebpackやReactを使っているというところも増えてきている印象です。

　昔、サーバサイドでNode.jsにSocket.IOを入れていたのと同じような感覚で、クライアントサイドのライブラリの一部に、Node.jsのエコシステムを組み入れて使うといったことがとても一般的になってきています。「npm」も、旧来の「Node Package Manager」としての枠を超えて、今後はフロントエンドを含めたJavaScript環境全体の管理ツールになるという方針を打ち出していますし、今後、こうした使い方はさらにポピュラーになるのではないでしょうか。

白石：古川さんは、Reactを使ったSSR（Server Side Rendering）をやっておられましたよね。数年前にお話しを伺った時には、SSR時にブロッキングがかかってしまい、レンダリング時間が長くなるのがツライとおっしゃっていたような気がするのですが、その後状況は変わりましたか。

古川：ReactによるSSR自体はまだメジャーではないですが、僕らはその後も続けています。

　これまで、Reactではレンダリングに関して、サーバもクライアントもまったく同じコードで処理をしていました。しかし、V16からは、APIは同一ながら、内部の実装が大きく変わり、サーバで動かす場合には、できる限りシンプルな形で処理をするようになりました。そのおかげで、SSRのパフォーマンスはかなり良くなりましたね。

白石：Reactそのものが、SSRを想定した実装に変わってきているということですね。

古川：ええ。ただ、以前より良くなっているとはいうものの、やはりHTMLを合成するというのはCPUに負荷がかかる作業です。本質的にNode.jsというのは、CPUヘビーな処理には向いていないので、負荷に対してサーバ台数が増やせなかったり、ちょっとピーキーな処理をしたいという場合には、キャッシュを作ったり、CDNを置いたりといった対策は必要になってしまいますね。

　とはいえ、以前はそうした対策が必須だったのと比べて、そういうことをしなくても、ある程度までは戦える環境になってきていると思います。

白石：SSRは、これからさらにメジャーなテクニックになっていくべきだと思いますか。

古川：そうですね。ユーザー体験を考える上で、電車での移動中など、あまりリッチにリクエストが投げられない環境においても、高いパフォーマンスで意味のあるコンテンツを届けられるという点でメリットは大きいと思います。

　あと、SEO的にも有利になります。Googleの「Lighthouse」という監査ツールがあるのですが、このツールではスコアリングにあたって、初期レンダリングがどれくらい高速に行われるかというのを見ています。従来のSPA（Single Page Application）の手法だと、どうしてもこの部分でのスコアが頭打ちになってしまうので、よりGoogle向けのSEOを強化したいということであれば、SSRを使っていくのがいいのではないでしょうか。

白石：古川さんのところでは、サーバサイドとクライアントサイドでのコード共有のようなこともやっておられるんですか。

古川：バリデーションのような部分では共有もしていますね。ただ、一口にバリデーションと言っても、サーバサイドとクライアントサイドでは、必要な要件が違ってくるケースもあるんですよ。

　例えば、サーバサイドではデータベースへの問い合わせにあたって、クライアント側よりも深いバリデーションが必要になってくることがある。その場合、あくまでも両方で共通するレベルでの共有しかできないということになるのですが、僕らが作っているものは、そのレベルで十分なことが多いです。

大津：「Node.jsでサーバとフロントのコード共有ができるのか」という質問はよくされるのですが、今、古川さんがおっしゃったような例も踏まえながら、基本的には「同じスキルセットでフロントとサーバの両方を見られる人間が増えて、コンテキストスイッチによるコストが減ります」という答え方をします。

　コードが共有できるというよりも、JavaScriptのスキルを持った「人」が共有できるという感じ。つまり、人間のアイソモーフィックが可能になるということです（笑）。

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

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

大規模サービスへの「Node.js」適用時に考慮すべきポイントは？

白石：では、大津さんに「大規模サービスでのNode.jsの活用」という側面で伺いたいと思います。ヤフーでは、Node.jsのサービスへの適用を進めておられると伺っていますが、例えばパフォーマンス面などで、気になっているようなことはありますか。

大津：うーん。うちに限らず、大規模サービスをやっているところはどこもそうだと思うのですが、パフォーマンスが足りなくなったら「とりあえずサーバを増やす」といった対応をすることが多くて、現状では、あまりNode.jsに由来するボトルネックを個別に気に掛けるというのはないですね。

古川：うちもそうです。もちろん、パフォーマンスは気にしておかなければいけないんですが、最悪の場合は「サーバ増やせば何とかなる」といった感じで（笑）。

大津：ですよね。うちの場合は、より基本的なエラー処理や、メモリリークなんかで苦労することが多いです。特にメモリリークなどは、コードの書き方によって出てきてしまうこともあるんですね。Node.jsのよりコアに近い技術が分かっていれば解決できる問題もあるんですけれど、利用規模が大規模になればなるほど、エッジケースでそういった問題が発生しがちになり、トラッキングの方法がないので現場が困るといった状況です。

　パフォーマンスについて見ていきたいという思いがある一方で、その前段階で解決が必要な課題もまだ残っているので、少しずつ取り組んでいきたいですね。

白石：あと、大規模サイトは基本的に長く運用が続くじゃないですか。その中で、JavaScriptは言語仕様も含めて次々と進化していきますよね。例えば、かつてはコールバックだったものが、Promiseになり、今やasync/awaitになって、try/catchなども普通にできるようになっているわけです。

　こういった、言語側の進化によるコーディングパターンの変化には対応できているのか。もし、現状で古いものと新しいものが混在しているのであれば、それをどのように管理しているのかについてお聞きしたかったのですが。

大津：われわれとしては、今まさにPromiseベースにしていこうとしています。「今やっておかないと、この先絶対マズいことになる」という危機意識駆動で絶賛作業中です（笑）。

　今、Node.jsの社内セミナーなどでも、カリキュラムの半分くらいを使ってPromise、async/awaitをどう扱うかを教えるというのが主流になっています。新しい人が「Promise、async/awaitじゃないと書けない」という時代もすぐにやってくるでしょう。

　一方で、現状では、コールバックベースの古いライブラリやAPIもNode.js上で多く使われています。そこで混乱が生じないように、うまくコントロールしていこうというのは考えていますね。恐らく、数年くらいのうちに、このあたりの問題が顕在化するだろうと見ています。

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

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

「モジュールシステム」や「ChakraCore」はNode.jsをどう変える？

白石：ここで、Node.jsに関して、私が気になっているいくつかのテーマについて、お二人のご意見を伺いたいと思います。1つめは新しい「モジュールシステム」についてです。私はまだ「.mjs」は使ったことがないのですが、実際にはどんな感じなんでしょうか。

古川：一応、新しいモジュールシステムが出てきた経緯から説明すると、もともとNode.jsにはCommonJSという昔ながらのモジュールの仕組みがあったんですね。これは、requireを使って特定のファイルやフォルダを取ってくるというものです。

　これまではずっとそれを使ってモジュールの仕組みを実現していたんですが、ES2015からES Modulesという仕様が新しく定義されて、言語側の機能でモジュールのimport/exportができるようになりました。

　requireによる従来からのやり方と、ES Modulesによる新しいやり方は、設計思想から違っていて、まったく互換性がありません。Node.jsでは、コンテクストの違うこれらのやり方を並存させようと考えたのですが、その落としどころとして、一番シンプルだったのが「js」と「mjs」とに拡張子を分けて扱うようにするという方法だったんですね。

大津：このやり方が正解かどうかは、まだ分かりません。内部でも非常に議論があるところです。

白石：ES Modulesについて「mjs」という拡張子で扱うことについては決定事項なのでしょうか。

大津：現状では、Experimentalな実装で「とりあえず使えるようになった」という初期の段階です。アーリーアダプターであれば、mjsを使っていろいろやってみるとよいでしょうし、もしそうでないなら、まだ使うべきではないだろうと思います。

　すでにCommonJSをベースとしたモジュールのエコシステムができあがっているので、ES Modulesをどのような形で相互運用性を確保しながら組み込んでいくのかについては、その方法を含めて、これからの議論を待っている段階です。

白石：なるほど。モジュールシステムについては、今後のコミュニティの動向に注目しておいたほうがよさそうですね。

　次のテーマとして「今後、Node.jsにV8以外のエンジンが使われる可能性」についてどう見ていらっしゃるかについてお聞かせください。

古川：マイクロソフトのブラウザに使われているJavaScriptエンジンをOSS化した「ChakraCore」を採用したものについては、すでにExperimentalとして別リポジトリができていますね。マイクロソフトのほうで、本体のリリースに合わせてアップデートをかけているようです。公式ページのリンクから、ダウンロードは可能だけれど、Node.js側が正式にサポートしているという形ではないと思います。

　ChakraCoreを公開した経緯としては、Windowsアプリケーションとして、よりOSとの親和性が高いJavaScriptエンジンを提供したいという意図があったと聞いています。

大津：ChakraCoreについては、OSS化されてはいるものの、現状、最適化されたライブラリについては非公開なんですよね。でも、Windows上で、そのライブラリと組み合わせて動かす分には、たしかにパフォーマンスが出ているようです。

　Node.jsのコアは、V8にガチガチに最適化されたAPIなので、仕組みとしては、ChakraCoreのランタイムにV8のAPIをシミュレーションする層が噛ませてあります。抽象化の仕組みがNode.js側に入っているわけではありません。

白石：Windows上で動かす場合には、ChakraCore版Node.jsのほうがV8版よりもパフォーマンスが良くなる可能性も出てきているということなんですね。マイクロソフト、がんばっていますね。

大津：ただ、V8以外のエンジンがNode.jsのデフォルトになる可能性は、今のところ低いだろうと思います。V8に依存した作りというのは、以前はリスクの一つだったのですが、Foundationベースに移行したことで、Google側も開発に積極的に関わるようになり、そのリスクはかなり後退しています。

　何より、すでにNode.jsではV8ベースでさまざまなものが書かれているので、それを別のものに置き換えようとすると、Node.jsそのものを別のものに書き直すのと等しい作業が必要になるんですね。それに見合うメリットが認められなければ、ほかのエンジンがデフォルトになることはないだろうと思います。

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

　株式会社テックフィード代表取締役。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」（オライリージャパン刊）など。

「Deno」は「Node.js」を脅かす存在になるのか？

白石：最後のトピックなんですが、最近、Node.jsのオリジナルの作者であるライアン・ダールが「Deno」という新しいプロダクトを発表しましたよね。古川さんもブログを書いていらっしゃいました（参考リンク：Node.js における設計ミス By Ryan Dahl）。

　これは、再びNode.jsコミュニティが分裂する前触れになるのではないのかと危惧する見方もあるのですが…。

大津：私の見方では、それは「コミュニティの分裂」とは違うと思います。Denoについては、「Node.jsのオリジナルオーサーが、自分が昔作ったプロダクトを、反省しながら今の知見で作り直してみた」という話以上のものではないと思いますし、それ以外の派生プロダクトについても、先ほどちょっと触れたように、「fork」して自分たちのやりたいことを試してみるというGitHub文化の一部だと理解しています。

白石：分かりました（笑）。では、Denoは「分裂ではない」という前提で、プロダクト自体についてはどのように評価されていますか。

古川：ライアン・ダールが「jsconf.eu 2018」で、自分が2009年に発表したオリジナルのNode.jsを振り返りながら、今になって感じている「10個の後悔」について話してくれたんです。

　「動的型付けをやめたい」とか「Promiseベースにしたい」とか、結構いろいろなことを言っていたのですが、僕が面白いと思ったのは「セキュリティモデル」についてですね。

　Denoではsandboxモデルを採用していて、デフォルトではネットワークアクセスも、ファイル書き込みの権限もありません。また、ダイレクトに任意のネイティブコードを実行することも許しておらず、すべてプロトコルバッファを経由して間接的に実行されるようになっています。OSのカーネルのように、特権モードとユーザー空間を明示的に分けるデザインなんです。実際に流行るかどうかは別にして（笑）、ここまでしっかりしたセキュリティモデルを持ち込もうとしているのは興味深いと思いました。

白石：そもそも、どうしてそういったモデルが必要だと考えたんですかね。

古川：Node.jsの場合、Linterのような小さなプログラムをちょっと走らせたいくらいの時でもフルで権限を与えてしまうので、それを悪用したマルウェア的なものが実際に出てきてしまっているのですね。そのあたりを防ぐための仕組みとして、こういったモデルが必要だと考えたんだろうと思います。

大津：僕はDenoに関しては、どちらかというとネガティブなんです。何というか「おいしいとこ取り過ぎる」感じがするんですよ（笑）。

　セキュリティモデルについても、スマホなどでOSが「アプリがこの機能を使いたいと言っていますが許可しますか？」と聞いてくるのと、基本的には同じ仕組みですよね。使うアプリが増えると、結局、スマホと同じように、ユーザー側が面倒くさくなって全部認めるか、拒否するかくらいの使われ方しかしなくなるんじゃないかと思います。結局、別のコンテクストにセキュリティの問題を渡すだけになってしまうので、渡した先のコンテクストで、今よりも良いモデルがなければ、同じことです。

　ただ、Denoには、2018年の知見に基づいているだけあって、アイデアとしては良いものが含まれていますよね。ゴルーチンの扱いなどは、しっかりとスレッド管理していてうまいなぁと思いました。

白石：この先、Node.jsがDenoに食われてしまうようなことはないでしょうか。

古川：それは考えにくいです。あくまでも現状のDenoは本当に初期のコンセプトモデルでしかありませんし。

大津：それに対して、Node.jsにはすでに作り上げられたエコシステムがあります。簡単に食われてしまうようなことはないでしょう。

　ただ、今後、Node.jsのほうで、アンチテーゼとしてのDenoが提示したアイデアについて議論したり、何らかの形で取り入れていったりという可能性はあるかもしれません。

ユーザーとデベロッパーが共に広げていく「Node.js」の世界

白石：お二人にはまだ、いろいろとお伺いしたいことがあるのですが、そろそろお時間のようです。最後に、Node.jsのこれからについての思いを、それぞれ一言ずつお願いします。

古川：Node.jsに関わってきた中で、おかげさまでユーザーはとても増えたと思っているのですが、特に日本では、まだまだサーバを書いたり、Node.jsそのものの開発プロセスに関わったりするような活動をしているデベロッパーは少ないです。

　僕は今、そうした人たちが増えるように、間口を広げる活動をしています。少しでも関心があれば、ユーザーからコミュニティへと、活動の幅を広げることも視野に入れて頂きたいと思います。

大津：Node.jsは、みんなが知っていて、使っているプロダクトになりました。「普及期」を終え、いよいよ「成熟期」に入ったわけです。当初はサーバサイドJavaScriptの環境として出てきたわけですが、現在ではサーバとクライアントの垣根を越えた、汎用的なJavaScriptランタイムとなっています。

　いろんなOSやディストリビューションで、標準で「node」コマンドが使えるような世界もすでに見え始めています。そうした状況の中で、Node.js自体にはあまりドラスティックな変化は望めないかもしれませんが、あらゆるコンピューティング環境で、最新の標準仕様に準拠した技術を動かせるプラットフォームとしてのNode.jsの魅力はますます増していくと思います。

白石：本日は興味深いお話しを聞かせていただき、本当にありがとうございました。

---

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