BFF

2021年6月27日

気になる技術スタックをハイプ・サイクルの視点で見る(ポエム)

ハイプ・サイクルという視点から気になる技術スタックを見てみる

前回は「最近のWeb界隈のトレンドで個人的に興味があるもの」という話題で、前回は主にフロントエンド、そしてそれに対するバックエンドについて書きましたが、今回は前回あまり取り上げなかった技術スタックについて、主にハイプ・サイクルという視点から見て書きたいと思います。
まあ、ポエムだと思っていただければいいと思います。

ハイプ・サイクルとは

ハイプ・サイクルとは、詳しくはWikipediaとかで調べていただきたいのですが、新技術の登場によって生じる過度の興奮や誇張それに続く失望のサイクルのことです。

黎明期・流行期・幻滅期・回復期・安定期 というサイクルです。

黎明期や流行期では、その技術スタックを絶賛するブログ記事が多くなります。
古い技術やそれ以前のやり方をディスる記事が増えるのもこの時期です。

幻滅期では、「やっぱり大したことなかった」とか「早くもオワコン」的なブログ記事が多くなります。

回復期から安定期で、改めて見直された後、話題性に乏しくなる(でも利用者は安定している)感じになります。

技術スタックの情報を集める際は、「その情報がいつ書かれたのか?」と「それはハイプ・サイクルとしていつ頃にあたるものなのか?」に留意した方がいいと思います。

ハイプ・サイクルの判断基準は?

何を持ってこのサイクルを判断するか?ですが、前回の記事にも書いたように、

  • Google Trends
  • npm trends
  • GitHubのスター数
  • 転職サイトの求人件数
  • ビジネスマッチングの案件数

これら情報である程度の判断がつきますが、指標の重み付けはそれぞれの立ち位置によって違いますので、何か絶対の基準があるわけではありません。

ここ最近動向を追いかけていた技術スタックで、とくに流行期から幻滅期に差し掛かってきたのではないか?というものと、
これから流行期に入っていくのでは?というものをいくつかあげたいと思います。

※各技術スタックについての説明は省きます。それを書き出すと、技術スタックごとに記事を書く必要があるためです。

気になる技術スタックとそのハイプ・サイクル

Golang(Go言語)

語弊を生みそうですがあえて書かせていただくと、Golangは幻滅期に差し掛かっているのか、新規採用が増えず安定期に入っているような気がします。
Google Trendsで見ると一貫して右肩下がりなのが気がかりです。npm trendsは新バージョンが出るごとに跳ね上がるのでそこは安心できそうですが、注目度合いとしては安定もしく下降気味という感じです。
これはおそらくバックエンドを何でもかでもGoで書こう!みたいなブームが落ち着いたのではないかと思います。
何年か前ぐらいですとRuby on RailsなどからGoでリプレイスした事例が検索でヒットするケースが多かったのですが、それも落ち着いた感がしています。
個人的にもサーバーサイドの言語として、GolangからNode.js(or Deno※後述)に興味が移行しつつありますね。

TypeScript

間違いなく流行期ですね。
こちらは完全な右肩上がり。TypeScriptはまるで宗教の信者に近いようなブログ記事も多く、型・型・型・・・TypeScriptを使わずJavaScriptを使い続けている人は人間じゃないみたいな扱いをしている人もいますね(苦笑)。
少しでもTypeScriptに否定的な意見を書いている人を見かけると脊椎反射で短絡的な反論をしている論調も多々見かけます。
しかしこれもアサインするメンバーと要件次第で、コストやリスクを鑑みて技術選択すべきです。使っているライブラリ全てがTypeScriptに対応しているとは限りませんし、TypeScriptへの移行に伴うトラブルも少なくないからです。
しかしフロントエンド・エンジニアにとっては必須科目に近い位置付けになりつつあることは事実です。

GraphQL

ハイプ・サイクルとしては完全な右肩上がり(しかも急上昇に近い)で、流行期に入っていると思います。
GraphQLはクエリ言語で、REST(RESTful Web API)とは使い所が違うものです。
よく、GraphQLを絶賛する記事では、なんでもかでもRESTからGraphQLに移行すべきみたいな論調を見かけますが、それは間違いで、そもそも向き不向きが違うので、要件定義次第で選択すべきです。
GraphQLもフロント側にクエリの選択権・決定権を持たせようとする潮流の一つだと思っています。
フロント側はともかく、DBと接続するバックエンド側の実装については、セキュリティ面やN+1問題等も含めて、決してRESTと比較して楽になるかというとそうでもなさそうで、RESTかGraphQLどちらが適切か?については、流行に流されることなく吟味した方がいいと思いました。

WebAssembly(WASM)

長い黎明期という感じです。幻滅期に行かずにそのまま停滞中な感じです。
ですが、個人的に遠い未来に期待している技術スタックです。
現在、ブラウザで実行できるプログラム言語はJavaScriptのみと思われがちですが、もう一つの選択肢としてWebAssemblyがあります。(HTMLやCSSはプログラム言語に含まないとして)
実際には、C#(Blazor)Rustなどの各言語をWebAssemblyにコンパイルして使用します。
現時点では、DOMツリーの操作などJavaScriptを介する必要がある点や、初動の速度が遅くなるなどの問題点もあります。どちらもいずれは解決すると思います。
それ以外の懸念点は、現在のこの技術は正しく使用されてないケースが多いという点です。
ユーザーに内緒で、ブラウザから暗号通貨(仮想通貨)のマイニングさせるツールに使用されるなど、悪意を持って不正利用されているためです。
これはJavaScriptと違って実行スクリプトを解析されにくいため、こういったことが可能だからです。
これらの不正利用を防ぐ手を打たないと、WebAssembly=不正ツール・バックドアツールといった悪いイメージがつきまといかねません(実際そうなりつつあり、WebAssemblyを使ったサイトの半数が仮想通貨マイニングが仕込まれていたそうです)
ですが、JavaScriptではなく別のプログラム言語でブラウザから高速で実行できるアプリケーション開発ができることは技術選択としてはプラスだと思っています。
技術的な問題、そして不正利用といった悪いイメージの払拭できれば、大変期待できる技術スタックだと思っています。

Deno

ちょっとおまけとしてDenoをあげます。ハイプ・サイクルとしては黎明期でしょう。
Node.jsの作者Ryan Dahl氏が、Node.jsの反省点を踏まえて開発したJavaScriptのランタイムですが、個人的に非常に期待しているというか普及してほしいと願っている、でもNode.jsに取って変わるかと言われたら厳しいと考えている技術スタックです。
node_modulesに大量のファイルをアップされることが個人的に大嫌いで、これが解消されるだけでもNode.jsではなくDenoを採用したくなります。
ただ、現時点ではnpmの豊富な資産も含めて、Node.jsからDenoへ完全移行できるプロジェクトは限られていると思います。
個人的な興味としては、Golangへの関心が下がりつつあり、逆にDenoを使ったライブラリやフレームワークでバックエンド側を構築してみたい衝動に駆られています。

Node.js / Deno のバックエンドフレームワーク全般

フロントエンド側(ReactやVue.js)ではなく、ここではバックエンド側で動く、あるいはフルスタックなフレームワークについてです。
Node.jsのExpressがメジャーですが、逆にそれ以外は、すでにオワコン化したり、マイナーなままのものなど、デフェクトスタンダードなものが決まらないまま安定期になってしまった感があります。(逆に言えば長い長い黎明期を抜け出してないとも言えます)
個人的にはNestJSあたりが気になりますが、やはり情報量が少なく、決して普及しているとも言えません。(間違いやすいですがNext.jsNuxt.jsではありません)
今回、バックエンド(もしくはフロントエンドも両方兼ねているフルスタック)なNode.jsやDenoのフレームワークを改めて調査したのですが、Golangのフレームワーク以上に乱立状態といった感じでした。逆に最古参のExpressがいまだに最有力候補とも言える状態です。
フロントエンド側がNext.jsやNuxt.jsなど固定化してきているのに対して、バックエンド側は混戦状態ですね。
Expressでもいいのですが、開発メンバーがKoaに移行してしまったため、これから大きな発展が望めるか微妙ですし、そのKoaも乱立する中の一つでしかない状態です。
いいか悪いかは別として、フロントエンドもバックエンドもどちらもJavaScript / TypeScriptでやってみたいとは誰しも一度は考えるのではないでしょうか?
ちょうど私が今その時期で、バックエンド側をPHPやGoやRubyではなくNode.jsかDenoでやってみたかったりするのですが、バックエンド側の候補が模索状態ですね。

React Server Components

React Server Componentsは最近のReact界隈の話題で、実装どころかまだ概念的なものです。
ですのでハイプ・サイクルすら始まっていないとも言えます。強いて言えば黎明期の始まりです。
まあざっくりと言えば、Fetcha API などでサーバーと連携が必要なコンポーネントはサーバーサイドに移そう!という感じで、その理想を実現できれば、そもそも上にあげたRESTやGraphQLを使わずに連携できるようになるかもしれません。
ReactもGraphQLもFacebookが開発しているものですが、このところのFacebookの勢いと、その目指す方向性は注目すべきところがあり、これも遠い未来においてどう実現するのか興味があります。
バックエンド側もPHPやGoやRubyではなくNode.jsかDenoでやってみたいと最近思う理由も、これらJavaScript / TypeScriptを使った技術スタックの勢いを肌で感じるためです。

締めくくり

今回、気になっている技術のいくつかをハイプ・サイクルの視点も入れつつ、改めて見直しました。
最近この手の話題を書いている理由として、ここらで次の5年、10年の技術スタックを選定をしたいと考えているからです。
何が正解かは、5年後10年後の技術トレンド、会社のビジネス環境、広くは経済情勢にもよりますので、現時点ではわかりません。
ですが技術トレンドの変遷に追従できるようにアンテナをはっておくことは無駄ではないですし、技術的負債が溜まりまくって身動きが取れなくなる前に、路線変更できるようにするのも重要だと考えています。

TypeScriptは必須条件に近いので言わずもがな、GraphQLは要件が合致したら挑戦したいですね。
Denoはモジュールやライブラリが充実してきたら、Node.jsから移行を検討。
WebAssemblyは動向を見ながらこれも利用するチャンスがあれば・・・という感じでしょうか。

また1年後あるいは3年後とかに答え合わせをしたいですね。
今回は以上になります。

LINEで送る
Pocket

label

Written by
isaka

バックエンドエンジニア

CONTACT

お問い合わせ、ご依頼などは下記電話番号かメールアドレスまでご連絡ください。
※内容により回答までお時間をいただく場合がございます、予めご了承ください。

tel. 06-6534-9333

10:00-19:00(※土日祝を除く)