Recoilのアーカイブの背景
皆さんこんにちは。 雨宿りとWEBの小噺へようこそ。
Podcast配信者のkeethこと桑原です。 この番組は日々降り注ぐ情報の中でちょっと雨宿りしながら様々なWEBテクノロジーの成り立ちや裏話を小噺としてお届けする番組です。
今回の話題は、フロントエンドの状態管理ライブラリ「Recoil」リポジトリがアーカイブされた件についてお話ししようと思います。
すでに何名もブログに書かれていたりとか、Xで元メンテナーの方とやり取りをされているみたいなのも見かけました。
何名というか世界中でももう何人もブログ書かれていたりしますけど、ネットを調べる限り今回のRecoilリポジトリがアーカイブになった根本的な原因っていうのはレイオフだそうですね。
もともとメタ社っていうのは大量レイオフしたことが過去にありまして、その時にもRecoilの開発者及びメンテナーというのもレイオフされていたそうですね。
今回ついに最後の一人だった開発者の方がレイオフされることになり、アーカイブに至ったといった感じです。
Xでその本人の投稿も見ましたけど、多くの社内プロジェクトでまだRecoilを使っていたってにもかかわらず、誰もその責任を引き継ごうともしなかったっていう投稿をされていて、これを見る限りいろいろお察しはしますねって言ったところですね。
もともとOSSとして世界中で使われるってことも実はメタ社のメンバーの中でも想定はしていなかったらしくて、発端としてはとあるチームが独自に作っていた状態管理のツールだった。
これを他のチームも使うといいんじゃないのとか、これ便利だよねって思ったので公開をしてみたっていうのがこのRecoilというツールですと。
リアクトチームもこれが公式のライブラリーっていうふうに主張したことは一度もなくて、むしろ推奨する唯一の状態管理ライブラリーっていうのはリアクト本体が持っている状態管理の機構ですよっていうふうに言っています。
このRecoilリポジトリ見たんですけど、更新ずっと止まっていて、僕も久しぶりに見たんですけどね、なんか全然話聞かなくなったなと思ったらそういうことだったんですね。
リポジトリ最後の更新一応見たんですけど、2023年の9月8日に止まってまして、ブログの方も2023年の3月1日から更新がありませんでした。
後ほどリンクとかも概要欄に載せておきます。
そもそもブログのページについては一応ブログっていう風なリンクになってますけど、単なるリリースノートでした。
しかもリリースノートの更新も全然なかったので、あんまOSSとしてがっつりコミットしていくっていうのはモチベーションは中の人にもなかったというふうに捉えていいんじゃないかなっていうには感じました。
様々な意見も出てまして、一つは状態っていうライブラリーが別にあります。
アルファベット状態ですね。JOTAIっていうライブラリーがあって、こちらへの移行を促す良い機会だなっていうふうに捉える方もいらっしゃると。
これ言ってるのはJOTAIっていうライブラリーの開発者の一人は元々リコイルの開発者でもあった。
その方がそういうふうに言ってるよっていうので、これはそうだよねっていうのはわかります。
また良くも悪くもリコイルっていうのが公式の状態管理ライブラリーっていうふうに外では捉え方をされてしまっていて、
これがアーカイブされたことでリアクトのエコシステムの多様化っていうふうに繋がるんじゃないのっていうふうにも考えることができるなと思いましたね。
他には大企業によるOSSの持続可能性っていうのが皆さんもおっしゃっていて、コミュニティとの連携の重要性っていうのも改めて認識をして、逆に考えさせられるような事象だったなというふうにも思います。
一部ではメタ社のオープンソースコミュニティに対する姿勢っていうものに関して、ちょっと疑問を投げるような声もいくつか見ましたね。
一方でリコイルっていうのは安定していたと言えば安定はしていたんですよね。
その意味では枯れたと言った方がいいかもしれないです。更新止まってたからそれが枯れたというふうに言えるっちゃ言えるんですけど。
このライブラリーを利用していたプロジェクトっていうのは世界中たくさんあるわけで、こういうプロジェクトは新たにライブラリーの移行っていうのを検討しなきゃならない。
その構成を取られるし、今から調査をしてライブラリーの理解をして、乗せ替えて大丈夫というふうに意思決定をしなきゃいけない。
Zeduxの特長とモルキュラー概念
結構時間かかりそうだなというふうに思いましたね。
幸いにも選択肢っていうのはいくつもあって、それほどドラスティックなAPIとか書き方の違いはない。
思想にもそんなに違いはないので、意外とやってみたらサクッと終わるかもしれないですね。
とはいえ選択肢複数あることは変わりないので、しっかり吟味しなきゃいけない。
実際今プロダクションで動いているプロジェクトの状態管理ライブラリーとしてリコイルを使っている現場はたくさんありそうですから。
その代替としてどんなものがあるのっていうところですけど、
一応npmトレンズとかいろんなネットの情報を見る限りは、先ほど出ました状態っていうライブラリーがチュースタンド、ゼットいうスタンド。
これ俺ずっとザスタンドって呼んでましたけど、確かチュースタンドらしいです。正しい発音ちょっとわからないですけど。
この放送中はチュースタンドといきます。
大体この2択になるかなっていうのが僕の一端の見立てですかね。
他の方もおっしゃってましたけど、大体ここでしょうと。
元メンテナーの人のXのポストでは、状態の設計と思想っていうのがリコイルに非常に似ていると。
元仲の人が一人いますからね。この辺が一つ。
あとはZeduxっていう後継ライブラリーも作られているらしいですね。
Zedux。ZEDUX。ZeduxかZeduxかちょっとあれですけど、英語っぽく。
この配信ではZeduxにいたします。
こちらに関してもちょうど概要欄にリポジトリとか公式サイトのリンクも貼っておきますね。
ちょっと気になったんで、中見てみました。軽くですね。
中って言っても公式サイトとサンプルのソースコードを見たってところですけどね。
シンプルさとかハイパフォーマンス、柔軟性とかタイプスクリプトの親和性っていうのを謳ってました。
パフォーマンスって言ってるのは高速な状態の更新だったり、最小限のサイレンダリングみたいなところからパフォーマンスの高さっていうのを維持していると。
あとはモルキュラーっていう概念があります。モルキュラー、分子のとか分子からなるっていうやつですね。
Atomic Designやったことある方は聞きなしみのある言葉だと思います。
モルキュールってやつですね。それの名詞じゃない方の単語ですね。モルキュラー。
昨今の状態ライブラリにあるATOMSとかATOMICっていうような原子のってやつですね。
その概念の上位概念みたいなもんです。もちろんATOMICとかATOMSはDXにもあります。
思想的にはATOMS同士っていうのがコミュニケーションするように設計されていて、その繋がりがいわゆるグラフっていうものを形成していくと。
これがモルキュラーっていうことを表していって、エコシステム側でこのグラフをコントロールするようになるというふうに書かれてましたね。
他にもですね、いろいろ対応はきっちりされていて、僕がいくつか気になったというか、これいいなって思ったものだけをピックアップしますけど、たくさんあります。他にも。
一つはテスタブルですね。Completely Outside Reactっていうふうに書かれていて、
リアクト以外のフレームワークでも使ってテスタブルに書けるんだろうなっていうふうに思いました。 まあまだ触ってないからあれですけど、
Deduxの利点
Completelyと歌ってるぐらいなんで多分いけると思います。 あとはSSR互換とか、最小限のボイラープレートとか
この辺もしっかり対応されていて、割と良かったなと思います。 あとまぁいくつか気になったというか、興味深いなっていう話があって、一つ目ですね。
もしあなたが、僕らが、リアクトクエリとかチュースタント、リコイル状態、エックスステイトとかを組み合わせて使っていて、
そのセットアップで何の欠点とかももし感じていないんであれば、おそらくDeduxは必要ないだろうっていうふうに中の人もおっしゃってますと。
自分たちのものをぜひ使ってくれみたいなアピールすると思ってたんですけど、逆でした。 またですね、コードスプリッティングをもしプロジェクトで使っているんだったら
Deduxを使うのが楽しくなるかもしれないっていうふうにコメントしていて、 これちょっと気になるというかワクワクしましたね。
使ってみたくなりました、この一文だけでも。 あと興味深いのはRxJSのサポートを強調していて、
しっかりサポートしてますよというふうに一文書かれてたんで、僕はRx使わないですけど、この先も使うかわからないですけど、もし使っている方で
状態管理ライブラリ検討している方はDedux一つ選択肢としてありかなと思いました。 あとはですね、Deduxはすべてを処理できるように設計されていると、
Deduxがうまく扱えないアプリの要件っていうのは絶対にないはずだっていうふうに明記してましたね。 これ強いなと思いました。
いやびっくりですね。 基本的にはチュースタンドとか状態等を使っているんだったら、それで十分というでも姿勢は崩してないんですよね。
Deduxももちろん小規模なプロジェクトに最適だっていうふうに彼らも言っていて、 ただ一つだけ大きなボーナスがあると。
これはねスケールに強く設計されているので、アプリケーションってやっぱ時間を経つと開発が進んでいくとどんどん大きくなっていったり複雑化していくはずです。
そうなったとしてもDeduxはその複雑さっていうのをエレガントに管理することができるっていうふうに言ってました。
本当は外国人ってエレガントって言葉好きなんだなと思いました。 まあなんとなく言わんとしていることは伝わりますけどね。
そんなこんなでスケーリングに対して強く一緒にやっていけるよっていうのが一つのボーナスなので、これは確かにいいなと思いますよね。
どんどん大きくなっていくとちょっとこのライブラリーじゃもう耐えられないなってちょいちょい出てくるんで、 そこに関して考慮されているのはすごく素晴らしいと思いますね。
はいまあいろいろ言いましたけど気になったのでDeduxは僕も個人で触ってみようかなと思います。
軽く見た感じリアクトじゃなくても使えないかなっていうのは気になりますね。 使えなかったら仕方ないんですけど一応公式のサイト
for react と一応書いてあるのでリアクト向けではあると思いますけどね。 そんなことで興味ある人は触ってみてください。
プロジェクトの信頼性
長くなりましたのでそろそろ今回もエンディングに入りたいと思います。 いかがだったでしょうか。
リコイルのアーカイブ最近も全然使わなくなったのでそんなに僕個人としてインパクトはないし、 僕が関わってきた今までのプロジェクトでもリコイル使ってたプロジェクトそんな多くはなかった。
全職で1回か2回あったぐらいですかね。 なのでダメージはないんですけど使っているプロジェクトは世界中まだまだあると思うので
みなさん一気に今の世界を頑張っているんだろうなぁとは思います。 さっきのアトムズの思想が割とスタンダードになってきてはいるので
そんなでかいインパクトではない気もしていますね。でもちゃんと本番で耐えれるかっていうのは 割としっかり検討しなきゃいけないと思うんで
やるとなったらサクッと終わるんでしょうけど、どれでやるっていうところにしっかり時間を割かれるんだろうなっていう感触はありますね。
その意味でリアクトを使っている現場だったらさっき言ったトイレ状態とかチュースタンドとか 今出しましたディダックスですね。これらへんでも全然いいんじゃないかなと思います。
プロジェクトの歴としては十分長いですからね。 イニシャルコミットは2017年の12月19日
実に7年とちょっと前からこのプロジェクトは開始していますので 割としっかり作り込まれているところも信頼性に足るかなと思います。
リリースの飛びた感じはファーストリリースはバージョン0.5.7で、こちらは
2、3年前だったかな。2012、23年ですね。にリリースされているので ちゃんと使えるようになったのはここ最近だと思いますけど
プロジェクト自体は十分長いので その辺も安心していいんじゃないかなと思ったりはしてます。
興味ある人は本当に触ってみてくださいというところで終わりたいと思います。
この番組面白かったよという方はぜひチャンネル登録もお願いします。 もし聞いていて気になることや話してほしいトピック、感想などございましたら概要欄のフォームや
Xでハッシュタグウェブ小話でつぶやいてください。 ウェブはアルファベット、小話は漢字でもひらがなでも大丈夫です。
それではまた甘えどりしに来てください。今回もお聞きくださりありがとうございました。 甘えどりとウェブの小話、お相手はピースでした。さようなら
