00:10
はい、みなさんこんにちは。kkeethことくわはらです。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネル。
この番組では、ウェブ業界やエンジニアリング、いろんな技術についての情報を、
雑談形式で発信していきたいと思います。
で、本日はタイトルにあります通り、RiotJSですね。
JavaScriptのライブラリーの一つです。
SPA作るためのものぐらいのものに、思っていただければと思いますが、
こちらと最近また遊び始めた、戯れ始めたっていうところですね。
自分で言うのもなんですけど、僕のラベルで、
一応、Riot兄さんと昔呼ばれていたことがありまして、
今はもう年齢的におじさんだなっていうところありますけど、
RiotJSの日本のコミッターとして、数少ない、3名確かいたかな、
の1名としていろいろやってて、
RiotJS Japan User Groupっていうのがあって、
スラックコミュニティもあるんですけど、そこのオーガナイザーやったりしてます。
最近全然活発じゃないっていうのが悲しいところではありますけど、
をやったりとか、RiotJSに関する商業史ですね。
C&R研究所から出版させていただきました。
書籍書いたりもしているので、一応RiotJSというと、
僕の名前も少しは上がるんじゃないかなっていうところで、
いたんですけど、全然ここ数年は書いてなくても、
やっぱりリアクトのキャッチアップにずっと時間を使ったってところですね。
ビューは実はあんまり僕キャッチアップできてなくて、
Nextも一応案件で書いたことはありますけども、
あんまりちゃんと理解できてなかったなっていうのが今も思います。
今はリアクトのほうが圧倒的に理解度が高いんじゃないかなというところですね。
ただ、NextJSもやったり、
NextJSのアップルーターはまだまだ追い切れてなかったりして、
一応リアクトのサスペンスとかサーバーコンポーネントのところまでは一応追ってはいますけど、
Nextもしっかりやらなきゃなっていうところはありつつ、
時間がなくてとか、いろんな業務があったりしてとか、
そもそもお仕事で案件から離れた、
現場ですね、一線で書く仕事から離れたっていうのもあるからこそ、
技術がちょっと錆びついたっていうのもあると思うんですけど、
最近また技術について触れたくなってきて、
いろいろ錆び落としも兼ねてキャッチアップをしてます。
その中で、僕のラベルといえばRiotJSのところもあって、
いや本当にですね、RiotJSっていいライブラリーなんですよ、個人的には。
Viewよりはわかりやすい印象があって、
いや、どんな、比較しても仕方ないですし、
それはもう個人の思想なんで、あんまり比較してないほうがいいですね。
はい、忘れてください。
ただ、昔言った言い方をすると、
Viewとかリアクトいきなり入門すると難しかったっていう方もいらっしゃると思いますし、
落とし穴たくさんあると思うんで、
そういう方のためにRiotJSでまず、
JavaScriptのライブラリとかフレームワークってこんな風に書くんだなっていうのを踏み台にしていただいて、
では本当のリアクトとかにいくのも一つじゃないのっていうような使い方を進めてました。
03:03
最初からもうリアクトにいくんだってわかってるんだったら、
RiotJSじゃなくてリアクトを触り始めてもいいと思いますけどもね。
思想的にはリアクトとかView.jsのちょいちょいコンセプトをパクったような感じのものになってます。
今バージョン9まできましたね、メジャーバージョンが。
4の時にView.jsを確か参考にしていろいろガラッと変えたって感じですね。
ちょっと3と4ではもう完全に別物になったっていう印象はありますけども。
で、4からずっとコンセプト自体あんまり変わってなくて、
パフォーマンス周りだったり中の細かな改善というところでバージョン9まで今きてます。
今はどのフレームワークもそうですけどJSXベースで書いたりとか、
フックスの概念ですね、が入るのが当たり前になってきてますけど、
Riotはフックスの概念がないんですね。
なんですけど、MU-FUXっていうライブラリーがありまして、
NPMにはU-FUXですけど、正式名称はイリシャ語のMUですね。
MU-FUXっていう名前だった気がしますけど。
なので、ないんだったらそういうのを組み込んでいいですよみたいなライブラリーがあります。
FUXを導入するためのライブラリーがあって、
それと組み合わせていけばRiotにもFUXは一応使えるんですよね。
いわゆるUseStateとか。
とはいえ、そもそも使わなくてもよかったりしますし、
Riot.jsにはObservableというライブラリーがあって、
もともとは本体に組み込まれてたんですけど、
モジュールとして切り出された。
わかりやすく言うとシングルトンみたいなイメージで持ってもらったらいいんじゃないですかね。
僕はそういうふうな使い方をしてますけど。
あれがすごくシンプルで、僕はわかりやすかったんですよね。
リアクトってちゃんとリアクトの思想を理解して、
それに乗っかれば綺麗に書けるし、早く書けるし、
パフォーマンスも高く書けるみたいなところ。
本当に強みだと思いますし、
適当性をちゃんとコンポーネントで担保するという思想が僕は大好きですね。
なんですけど、落とし穴が割と多かったり、
しっかり作り込むためのフレームワークと思っています。
リアクトは今、ライブラリーとは言えないぐらいの機能が備わってきますし、
対応範囲がちょっとバックエンド寄りにもなってきたりするので、
そこまでいくともはやフレームワークだろうと僕は思っています。
本人たちはライブラリーと名乗ってますけど。
そこまでいくと学習コストも高かったり、
難易度が高くなっているという印象がすごくあって、
かつ、さっきも言いましたけど、ちょっとバックエンド寄りの思想も
しっかり理解していかなきゃいけないというところで、
欲しかったのがフロント側の方だけでSPA作りつつ、
状態管理したりゴニョゴニョしたいという、
あくまで側の方の処理を簡単にしたいというのであれば、
ライオットJSは僕もう一回需要ないのかなと思ったらしてます。
ビュージェンスもありますのでビューに行くという人ももちろんあると思いますけども、
リアクトで言うところの復活みたいな概念がビューにもあるんですけど、
名前出てこない。最近書いてないとすごく忘れますね。
そういうものがあるので、ビュー使うかもっていう人の方が多いかもしれないですね。
ですけど僕はライオット本当に好きですし、
最近また改めてキャッチアップをやり始めたんですけど、
06:01
書籍書いておきながらもう数年書いてないとやっぱ忘れるんですね。
ライオットの書き方どうなのかっていうのを、
改めて自分でも公式ドキュメント見ながら書いてるんですけど、
公式ドキュメントわかりづらくて自分で思いましたね。
やはりそりゃ良くないわっていうので、
自分なりの入門向けの書籍を全ブックに書こうかなと思ったりはしてるところですね。
公式ドキュメントはあくまでリファレンスとして使ってもらうということで、
最初どんな風に書けばいいかみたいなのは入門向けなのを僕が書こうかなみたいなところがあったりしますね。
一応何度か考えたことはあって、
参考にしているのはアンギュラーですね。
ご存知、Google社が作ったJavaScriptフレームワークアンギュラーってやつです。
そのアンギュラーが出しているチュートリアルみたいなやつがあるんですね。
Tour of Heroesって言って、ヒーローの名前をSPAで表示するみたいなウェブアプリケーションがあるんですけど、
あのチュートリアルがすごくわかりやすくて、
もちろんアンギュラーのフレームワークの概念とか機能を使った実装になってるんですけど、
あれをライオット用に転用して、ライオットで同じものを作ってみようみたいなことをやろうとしてて、
それのドキュメントも実は全ブック途中まで書いてて、
いろんな忙しさの理由にかまけて書いてなかったんですけど、
あれも続き書いていきたいなと思ったりしてて、
まさて、そんな風にやろうと思ってて、
ライオットを最近触ってます。
ライオットJSの魅力っていうのは、本当に捨てやすさだと僕は思ってます。
書きやすさとか入門のしやすさは絶対あると思います。
スクリプトをちょっと理解した人、
少なくともリファレンス見ながらでも書けるようになったっていう人が、
次にちゃんとフレームワーク使いたいっていうんであれば、
ライオットJSはすごく入門向けでオススメしてます。
かつ、ライオットで書いたメソッドとかコンポーネントって、
普通に他のライブラリーにも転用しやすいぐらいの軽量動作であって、
そういう意味で捨てやすいというか乗り換えやすいって言ったほうがいいかもしれないですね。
資源がそのまま使えるっていうところが強いと思います。
最近はアストロみたいなものができて、
リミックスじゃなくてアストロですよ。
リアクトとかビューのコンポーネントも全部実は使えますよと、
そのままの書き方で書けるらしいですね。
そんな魔改造みたいなフレームワークも出たんですけど、
個人的にはちょっと気持ち悪い感はあるんですけど、
リアクトにちゃんと乗り換えたいんであれば、
ライオットで書いたコンポーネントとか書くメソッド、
ユーティルズ的なのは全然使いまわせるよっていうところがやはり強いと思って、
そういう意味でも入門向けでいいんじゃないのっていうところはあります。
ライトなのが欲しいフロント側のフレームワークで、
ってなったらオススメですね。
書きやすさとか書き方もとてもシンプルですし、
従来のHTML、JavaScript、CSSの書き方、
そのまんまだなっていう感じはありますので。
単一コンポーネントの書き方が今、
昨今どうなのっていう話はあったり、
関数コンポーネントで書き慣れた方からすると、
見た目に違和感があるなっていうところはあります。
慣れた方はリアクト使えばいいんじゃないのっていうところも、
もちろんゼロではないと思ってますけど。
ただ、フロントエンドっていうところに入門する方向けだという風に僕は思ってて、
それを改めてオススメしたいし、
09:01
強めていきたいなっていうところはあるねっていう感じはしますね。
でまたライオットのドキュメントを調べるとですね、
リアクトとマジでかぶるんすよ。
名前が少し似てるっていうのもあるんで、
ライオットでなんかこんな機能ないですかってググると、
もしかしてリアクトのこれですかってグーグルから言ってきて、
いや違ぇんだよって話をずっと戦ってて、
なかなか辛いなっていうのがあるんですけど。
まぁそこはもう今チャットGPTにかなりお世話になってます。
いやぁ彼らもだいぶクオリティ上がりましたね。
ちゃんとライオットのことも学んでんじゃんっていうのがちょっとびっくりしましたけど。
はい、というのでまぁいくつか、
今リポジトリを作って、
今やってるのはライオットとタイプスクリプトとテイルウィンドとビートですね。
で組み合わせて開発環境を作って、
いわゆるXみたいなSNS風のアプリを今作ってます。
まぁ参考程度にって感じですね。
まぁそんな感じで自分の苔落としを今やってるんですけど。
やっぱライトなものであったり、
そんなにこう機能がたくさんあるものじゃないフレームワークであればあるほど、
ウェブ標準の仕様とか技術に乗っからなきゃいけないので、
ちゃんとウェブの勉強ができるなっていう意味でも、
やはりライトなフレームワークはそういう魅力的なとこはあるかな。
いわゆる教育的な観点で僕はやっぱ好きだなと思いました。
で本当にお仕事とかアプリケーション開発っていう意味だと、
それは絶対リアクトに軍配はありますよ。
エコシステムの充実さもそうですし、
機能の多さというところも絶対あります。
大規模なアプリケーション開発でもちゃんとタフだし、
耐えれるなっていうのはあるので、
仕事では僕もリアクト書くと思います。
じゃないものだったら、個人開発だったり、
ウェブだけをほんと欲しいっていうのであれば、
ライオットいいかなと思ったりしますね。
わかりやすく、JQueryから脱却したかったらどうぞとかはあったりします。
はいっていうような印象で、
今最近いろんなものを書いてますし、
またライオットのなんかおすすめがしたくて、
前にちょこちょこまた記事書き始めようかなと思ってるっていう、
そういうお話でした。
はい、参考になれば幸いです。
まあ興味あれば触ってみてください。
最近本当はJavaScriptのフレームワークたくさん生まれてきて、
もうキャッチアップマジで追いつかないんですけど、
私はちなみに速度中の人間なので、
今ライオット以外で触っているものはあれですね、
Quickですね。QWIK Quick。
まあ去年からもずっと言ってますけど、
最近なんか水口さんがQuickについて結構発表したり、
ライブラリガンガン作って発表してくれてるので、
いやありがたいなと思ってて、
あれに僕も乗っかりたいですね。
あとQuick Cityでしたっけ?
ラッパーフレームワークも出てるっぽいので、
あれをなんかライオットでも使えるようにちょっと今、
各作しようと思ってます。
彼がいくつかリアクト用とかスベルト用みたいなのを書いてくれたので、
それを真似しながらライオット用も書いていきたいと思いました。
ライオットの最大の弱点はラッパーフレームワークがないとこだったので、
Quick Cityがそれに乗っかれるんだったら乗っかりたいなっていうので、
頑張って書いていこうなと思ってます。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
