00:05
6月6日、月曜日ですね。時刻は朝の9時8分を回ってしまいました。
ちょっと遅くなって申し訳ないようですね。
朝活を始めていきたいと思います。
おはようございます。ゆめみのキース孤独は払ってです。
では本日も朝活を始めていきたいと思います。
早速、お二方、けいさんとわくわくさんですね。
ご参加いただきありがとうございます。
佐々木様ですね。ありがとうございます。
今日からまた朝活を始めていきたいと思います。
昨日まで、3日連続でちょっと
パーソナルコーチングの研修を受けていて、
それが朝9時から夕方5時までみっちり埋まっていたので、
すみませんが朝活できなかったんですけどね。
はい、というわけで今日も始めていきたいと思います。
タイトルにある通り、
Svelte vs. React in 2022の記事ですね。
Choosing the best match for youという記事を、
前回も確か読んでいたと思うんですけど、
それの続きですね。前回、
ダイジェストバーって書いてあって、
で、面積事項みたいなところまでガッと読んだんですね。
面積事項、これは投票じゃないよって話。
人気投票じゃなくて単純に自分の比較ですよっていう記事を読んでるって話をしましたね。
で、ざっくりダウンロード数の比較とかを見ていたと思いました。
Svelteは大体1週間で10万ダウンロードいってるけど、
Reactは6ミリオンなんで600万ぐらいですね。
Reactはやっぱりデカいよって話をずっと読んでいたと思います。
で、ここから本題の方に入っていくという感じです。
全文英語ですので、
また都度都度翻訳しながら読んでいくので、
ダラダラって読んでいこうと思いますので。
各ツールで折り畳み式のナビメニューを作ってみようということで、
一旦この筆者の方は、
折り畳みのツール、ナビメニューですね。
ナビゲーションのメニューを一旦作ってみようという感じです。
折り畳みっていわゆるアコーディオン的なやつですね。
なんですけど、
アニメーション的には単純に
開閉とかではなくて、見える見えないに
ちょっとだけアニメーションを付けとっているだけの感じですね。
じゃあまず、ReactとAsphaltの同じUIの問題に対するアプローチを比較してみましょう。
それはインタラクションの表示、また非表示になります。
例えば今回のナビメニューの方を考えてみたいと思います。
一応この人がフルガイドという別の記事を書いているらしいんですけど、
それは英語なのと長そうなのでそこは割愛しますね。
一応説明書いてあるんですけど、
私はこのためにスタイルとかキーボードナビゲーション、
スクリーンリーダーのアクセシビリティを考慮した完全なガイドを一旦書いてますよと。
しかしわかりやすくするために、
ハンバーガートグルだけに焦点を当てて話してみたいと思います。
まずはレッツトライリアクトというところで、最初にリアクトの話からですね。
TLDRというのはToo Long Don't Readの略だと思います。
ところがあるのでそこを読んでいくと、
この素晴らしいチュートリアルを読む時間がない場合に備えて、
03:02
このチュートリアルで明らかになることを簡単にまとめましょう。
リアクトはプログラマーのために作られました。
リアクトはプログラマーのために作られているので、
関数型プログラミングの原則に支えられています。
リアクトはプラットフォームに依存しません。
プロップスからUIというところの流れであれば、
コンポーネントはブラウザーの中でも外でも動きます。
またリアクトというのは予測可能性もありますよと言ってますね。
全てのコンポーネントはいわゆる純粋と見なされているので、
結果として得られるUIはあなたが渡したプロパティにもどづくものになります。
最後ですね。リアクトはテスタブルですよと言ってます。
全ての不純物。不純物ってなんだ。
ちょっと文脈的に難しいな。
不純物なんだろう。何を見せるかわからないですね。
全ての不純物はユーズエフェクトに包まれて、
全ての状態変化というのはユーズステートに包まれるよと。
これによって1つ、外部依存のモッキングが容易になって、
2つ、純粋で不純物の境界線が高度から明らかになることが保証されますよと言ってますね。
外部要素とかそういうリソースの話な気がしてますね。
リアクトのメリットはその辺にありますよと。
じゃあ実際にビルディング。
Our First React Componentsってところですね。
ここからコンポーネントを実際に作っていくって感じで、
ここからコードがちょっと多いんですけども、すみません。
ふーんってぐらいに想像してもらえるとありがたいと思います。
じゃあ最初にリアクトコンポーネントを構築するというところで、
このセクションではあなたが初心者の知識を持っていることを前提とします。
リアクト的な基本的なものは持っていてくださいねって感じでした。
もしリアクトをすでにがっつり知っているのであれば、
リアクトの関数型プログラミングを飛ぶこともできますと。
サンドボックスが用意されていて、そこのリンクも貼られてますよってことですね。
で、あ、なるほど。
関数型コンポーネントの章があって、そこに飛べばいいよって言っているので。
なるほどですね。
ざっくり今ソースコードとかコメントを見ているんですけど、
本当にリアクトのコンポーネントの基本的な作り方っていうところが紹介されているので、
そこの部分は簡単にしますね。
続きのファンクショナルコンポーネントのところをざっと見ていこうかなと思いますね。
じゃあ、あそこまでジャンプします。
では行きますね。
リアクトは関数型プログラミングを推奨しています。
リアクトのコンポーネントと復活っていうのは、
コンピューターサイエンスの概念である関数型プログラミングにインスパイアされています。
リアクトは例えばハスケルのような厳密な関数型プログラミングパラダイムではないですよ。
しかしリアクトはいくつかの重要な関数型プログラミングの原則を推奨しています。
06:01
まずコンポーネントは純粋な関数であるべきですと言っています。
はいはい、これは今の関数型コンポーネントの話ですね。
これは与えられた入力に対して常に同じ出力を受け取ることを意味します。
例えば次のような単純なコンポーネントを考えてみましょう。
これソースコードなんですけど、
ファンクション、メイクファンっていう名前で関数定義して、
引数にボワリングテキストっていうのを受け取るようになっています。
で、リターンで単純にJSXでPタグに受け取った中身を返すだけのコンポーネントですね。
っていうのを返しています。
はい、ものすごくシンプルなコンポーネントですね。
で、これを書いておいてコメントが、
はい、今回はPタグなので段落なんですけど、
段落がドキュメントに存在するかどうか、
外部の依存関係が存在するかどうかなどを気にする必要は全くないと。
はい、ソースコード的にはそうですね。
例えば引数にリアクトって文字を受け取ったらそのまま、
リアクトってそのまま返せばいいだけの話ってことですね。
で、それは常にそのものが返されるので、
テッタブルだなって感じは確かにあります。
で、コメントが切れて、
この順度っていうのはリアクトをプラットフォーム非依存型にするものでもありますと。
はい、例えばリアクトネイティブっていうのが、
これらの同じコンポーネントを適用して、
iOSとかAndroid用のネイティブアプリを構築しますと。
で、その場合でも単なるブラウザで包まれたアプリではなくて、
本当にネイティブになるっていうことですね。
それも魅力ではありますが。
はい、関数を呼び出してUIを返すことができれば、
それがどこで実行されているかなんて気にする必要はないんですよって話をしてますね。
なおかつ、レスポンスも必ず固定されたものが返ってくるってことですよね。
渡した値によって返ってくるものはもちろん値は違うんですけども、
中身っていうのは結局一緒になってくるので。
第2に、不純なものをすべて取り除くことですよって言ってます。
リアクトがコンポーネント関数を呼び出す目的がただ一つしかなくて、
当たられたプロプスのセットに対してどのようなUIを表示するべきかっていうのを把握することになります。
その目的以外のもの、例えばAPIからコンテンツ取得したり、
ブラウザのドキュメントを参照したりとか、
プログラム的に状態を変更するなどなどっていうのは基本的には不純物、
もしくは副作用というふうにリアクトは見出しています。
最後、リアクトはユーズエフェクトと呼ばれるこのためのヘルパーを提供しています。
例えばDATJOKES APIっていうのがあるらしくて、
そのDATJOKES APIから面白いジョークを取得するとしますと、
このAPI、僕もちょっと後で見てみます。
面白そうだったらTwitterでも流しますね。
そのAPIから値を取得するっていう、またソースコード例になってしまうんですけど、
口頭で申し訳ないです。
インポートリアクトでとりあえずリアクト読み込んどいて、
関数定義しますと。
関数コンポーネント定義、ファンクションのMakeMeRoughっていうものを定義しておいて、
引数にネームっていう値を受け取りますと。
一番最初、冒頭でユーズステイトを使ってますね。
ユーズステイトで初期値は適当な文言を渡してあげて、
09:02
レスポンスのところでジョークとセットジョークっていうのをハイレートとして受け取ってますと。
やることはもちろんユーズエフェクトを使って、
さっき言ったAPIから値を取ってきてますよと。
変更検知っていうところには、
第2引数にさっきセットした、受け取ったやつですね。
この関数コンポーネントで受け取ったネームっていう値を第2引数に与えていて、
その受け取った値が変化したらまたユーズエフェクト発火しましょうっていう感じですね。
最後はリターンでJSXのPタグですね。
受け取ったネームっていうのとジョークっていう値ですね。
APIから受け取ったジョークっていうものをセットして返してあげてるだけですよと。
一応これのサンプルフォームはどうもスタックブリッジにあるっていうところなので、
記事のリンクからこれはちょっと見ていただくのが良いのかなと思います。
そんな関数定義をしたとして、
その前のコンポーネントですけど、
このコンポーネントをMakeMeRoughでName="Ben",みたいなプロプトとして渡して、
ページに配置しておくとリアクトは次のように動作しますと。
とりあえずまずはレンダーしますと。
レンダーで初期値の文言がレンダリングされますと。
レンダリング中に見つかった副作用っていうのは全てタスク級に追加をされます。
この場合はいわゆるフェッチコールっていうのがタスク級に追加されてますね。
APIコールのところです。
続いてフェッチコールが実行されますと。
SetJokeっていうUseStateのセッター関数が呼び出されて、
リアクトにこのコンポーネントを再レンダリングしろっていうふうに命令が発火されるよという感じです。
続いて先ほどのAPIコールから受け取った値、Jokeですね。
っていうのはJoke文言がセットされていきますと。
この辺の値は何だっけ。これはただのJokeか。
じゃあ続いて。
Jokeのステップ1っていうのはAPIを呼び出すっていうことではないことに注意をしてくださいっていう感じですね。
今のステップの中、一番最初にレンダリングで初期指紋言がバーッと追加された。
レンダリングされたんですよね。
UIを先にレンダリングしてAPIコールを後で予約するっていうものがリアクトのやっている順番なんですね。
いきなりAPIコールするわけではないところに注意です。
これにはいくつかの利点があるよって述べていて、
最初のレンダリングは常に予測可能になりますっていうのが一つのメリットだと。
これは複雑なWebアプリケーションを構築する際には不可欠でありますよね。
なぜならユーザーは副作用が実行される前に常に同じ初期コンテンツを目にすることになるからですっていうことですね。
またこの予測可能性によってコンポーネントはテスタブルになります。
コンポーネントが最初に何を表示するかを検証するユニットテストを作成して
リアクトテスティングライバリーのようなもので副作用をMockすることもできます。
ユーズエフェクトは不純物をカプセル化することになるので
フェッチの呼び出し自体もMockにする必要もないですよってことですね。
確かにこれはメリットですよね。
12:13
続いてリアクトがハスケルのような真の関数型プログラミングケースからほど遠いことは先に述べた通りですが
ユーズステイトとかユーズエフェクトの存在っていうのは
全てのリアクトコンポーネントを不純なものにしてしまいます。
これがリアクトをライブラリーから真のプログラミング言語へ進化させたいという開発者がいる理由になります。
もし興味があれば
アブラモフのエフェクトやプログラミング言語のリースクリプトについての考えをチェックしてくださいと
そういう記事がまた別途貼られてますね。
っていうのを見てくれると結構いいかもしれないねって言ってました。
一応今のがリアクトの話でした。
では続いてスベルトの話ですね。
Now let's try スベルトっていうところで
同じような、全く同じものを作るので
ソースコード的にはバリバリと割愛していきたいと思いますが
リアクトの方法と理由、HowとWhyっていうところを見ていったので
今度はスベルトっていうのを見てみましょうと。
ここでもまずはTLDRですね。
ここでもチュートリアルで明らかになったことをとりあえず簡単に説明していきましょうと。
一つ目、スベルトってのはとにかくシンプルであります。
スベルトはシンプルで、より早くデリバリーできるように作られていて
状態管理っていうのを中小化することができますよと。
スベルトってのはバッテリーを搭載していますと。
バッテリー?バッテリーってなんだ?
原文もバッテリーズインクルディーって書いてあるのでバッテリーだな。
すいません、僕がスベルトよくわかってないのでそういうのがあるらしいですね。
スタイルとアニメーションにはすぐに使えるソリューションっていうのがスベルトには提供されてますよと。
前回の記事でも言いましたね。
スベルトは結構アニメーションとかスタイリングに強いエンジニアには結構適してるよって話をしてたと思います。
続いてスベルトってのはUIファーストになりますと。
例えばナビゲーションっていうものをコンポーネントとして定義するとき
リアクトは関数コンポーネントで定義したかもしれないですね。
JSXでNavっていう、例えばHTMLを返すかもしれないですけど
スベルトは単純にNavっていうコンポーネントで定義をしていくっていう
本当にUIファーストの形になりますと。
ラスト、スベルトっていうのはウェブのために作られていますと。
これらのバッテリーを搭載するためにスベルトは既存のウェブAPIを採用することを選択しましたと。
そのためスベルトはモバイルやデスクトップのネイティブアプリケーションへの移植性がかなり低くなってますと。
これはデメリットという人もいるでしょうけどね。
しかしこれはシンプルにするための秘密のソースの一部なんですよということです。
とにかくウェブのためっていうのに特化しているということですね。
リアクトは確かにプラットフォームを超えたいなっていう人たちのためには全然いいと思いますけども。
15:00
また同じようにソースコードが入っていくんですけど
やり方としてはさっきのリアクトと同じように
最初に単純なナビゲーションのコンポーネントを作っていくんですけど
これもスベルトの書き方を知っている人に対しては釈迦に説法な感じがするので
ここもざっくり愛しようかなと思います。
見てもらったらこんな風にスベルトって書くんだねっていうのが多分わかると思うんで
わりかしその辺は飛ばしてもいい気がしてます。
比較記事まで飛びすぎるな。
どこから読もうかな。
スベルトヘルプスユースイップファスター
この辺から読もうかな。
そこから読んでいきましょう。
スベルトの話ですけども
スベルトはそのデリバリーのところをより早くなるように支援しています。
どこから読んでいきます。
これはリッチハリス。スベルトの作者がリッチハリスという方ですね。
この方が最近使っているマントラだという風に言ってますね。
リアクトが関数型プログラミングの原則とJavaScript Firstの考え方を好むに対して
スベルトは全く新しいテンプレート構文のためにその原則
いわゆるその関数型みたいなところとかJavaScript Firstという原則を捨てました。
これによってスベルトはあらゆる種類の組み込み機能をバンドルすることができます。
例えば一つ目がBuilt-in Style Scopingというやつですね。
名前の通りですね。スコープドのスタイルというのが最初から実装されてますよという感じです。
ソースコード的にガッと見ていくとちょっと口頭で申し訳ないですけど
スベルトって最初にスタイルとかスクリプトタグを書くことが習慣化になっているんですけど
冒頭スタイルタグが入っていてその中に.コンテナーみたいなのをくらすと
.ボタンに疑似セレクターでbeforeというのがついてますね。
疑似要素でセレクターが入っていてその下にHTMLにナビゲーションタグがあってボタンとUIというのがありますね。
ナビゲーションのところにクラスコンテナという枠の方ですね。
中の方にボタンの方のクラスが振られてますけど。
っていうよくある書き方をしてるんですけど
こう書いたときに
これらのスタイルというのはドロップダウンに適用されるだけじゃなくて
我々のコンポーネントに特別にスコープされている形になりますと。
例えばさっき言ったコンテナークラスですね。
のようなセレクターがコンポーネント外側のクラスコンテナというのを持つ他の要素には影響を及ぼさないことにしますと。
なのでスベルトというのはコンポーネントにした瞬間にスコープはちゃんと絞られているので
スタイリングも同じクラス名とかがあったとしても他の方の要素には影響しないよってことを言ってますね。
古いプロジェクトからCSSのカスケード管理の悪夢を持っているんだったら
ぜひリアクトを使ってみてくださいと。めちゃめちゃ喜びますよって話をしてますね。
続いてのメリットですけども
やっぱり先ほどもありましたビルトインのアニメーションヘルパーというのがやっぱりスベルトにありますと言ってますね。
18:03
よりUIを魅力的にするためのトランジッションライブラリというのも実はバンドルされていて
ドラップダウンを1行の変更で簡単に拡大縮小させるようなアニメーションもできますよと言ってますね。
これもこの記事の中にはデモの動画が貼られているので
これも記事見てもらうのが多分一番いいのかなと思ってます。
コメントが来てますね。
コメントはこれは私が見た中でアニメーションを第一級市民とした
原文もそういう英語を使ってますね。
第一級市民とした初めての一般的なUIフレームワークでございます。
さらに独自のトランジッションディレクトビューを記述して
アプリの他の場所で使用することももちろん可能ですよと。
持続時間とかその他のカスタムパラメーターを受け取って
トランジッションとして適用するCSSを出力するだけでいいんですよと。
詳しくはチュートリアルを見てくださいという感じですね。
Svelteの公式サイトを見ていただくとチュートリアルがものすごく丁寧に
ステップバイステップで学べるようになっていて
かなりキャッチアップは早く簡単になっているので
一回本当に手を貸していただいてもいいのかなと思います。
パパパパッと手を貸せるので本当にリズムをよく学べて結構気持ちよかったですね。
では今のがSvelteの話だったので
ここから本題っぽい話がスタートしますけど
一旦ちょっとレッツストップ&コンペアということですね
立ち止まってちょっと比べてみましょうと
ReactとSvelteの比較をここからちょっとしていきましょうということですが
Reactのセクションではどのように動くかについて
Svelteのセクションでは何ができるのかについて
基本的にはほとんど時間を費やしていることに気づくでしょうと
これには理由がありますと
両者の指針は全く異なるから違うんですよということでしたね
ちょっと大事そうなので繰り返しますね
Reactはどのように動くのか
Svelteは何ができるのかに注目をしているということですね
ReactはJavaScriptでUIを管理することに強い意思を持つライブラリーになるので
UIそのものに対する意見というのは実はあんまりないんですよと
これはもちろんデザインによるもので
デザインとは設計の方のデザインということですね
Reactの関数型プログラミングのアプローチというのは
ブラウザやネイティブアプリなどにデプロイしたいプログラマーにとって
最適な選択となりますと
しかしスタイルやアニメーションを扱いにあれば
もっと多くのNVMパッケージを探してもいいんじゃないかなと思いますと言ってますね
SvelteはUIそのものに強い注目を持っているフレームワークであって
そこに至るJavaScriptというのは結構隠蔽されてますよと
ウェブサイトの構築の必需品が組み込まれていることが多いので
ウェブサイトを高速に作ってデリバリーしたいという
ウェブ開発者にはもちろん最適ですよと
プログラミングのパラダイムは入り口で確認し
htmlをちょっと書いてくださいということですね
これらのターゲット層というのは
重なる部分が多いのでしょうかという質問があるんですけども
21:03
もちろんそれはその通りだよという話で
それぞれのコンポーネントベースのウェブ開発アプローチなので
それぞれ画家がコンポーネントベースの開発アプローチなので
私自身はリアクトドスベルトを気まぐれに切り替えても構わないと実は思ってます
結構強いこと言うな
気まぐれでもいいんだ
しかしそのhtmlファーストのウェブ開発者と
UIにこだわるバックエンドエンジニアの端くれである読者というのは
どちらか一方に引き寄せられるかもしれないのですと
それもまあそうですよね
バックエンド上がりの人とは多分リアクトドスベルトの方が
親和性が高いんじゃないかなと思ったりしますね
しかし私が引いたこれらの線について
あなたがゆけつか疑問を持っているかもしれません
もしかしたら彼らの原点が役立つかもしれませんというところで
原点の記事のリンクがまたここに書いてあるんですね
Twitterのリンクが貼ってありますけど
とか見るといいかもしれないですね
では続いて時間が結構迫ってきたんですけど
今日の開始が僕遅かったので若干後ろ倒しにします
時間可能な人は全然残っていただいてって感じですね
では続いて異なる原点というところですね
それぞれのツールの起源について触れておくと
それが全体の設計決定に影響を与えたことには間違いありませんよという話をしています
まずリアクトですね
リアクトはスケールの大きな状態管理を解決するために
まずそもそも作られましたよと
確かにフラックスでガイドも作りましたしね
超ダイナミックなウェブアプリケーションとしての
Facebookのニーズを解決するために作られました
そして今もそれはその通りですと
それらの課題のほとんどは可能な限りスマートにデータを取得して
ユーザーがアプリをナビゲートする際に
そのデータを管理することに集約されていますよと
一方のSvelteというのは
インタラクティブ性を安価に
良いUXですね
かつシンプルに
これも良いDXですねと
を実現するために作られましたよと
良いUXと良いDXを生み出すために作られましたよと
でリッチハリスっていうのは
そのニューヨークタイムズの開発者として
Svelteをメンテナンスしていました
そうなの?ニューヨークタイムズの開発者として
Svelteをメンテナンスしたんだ
それはちょっとごめんなさい知らなかった
ニュース記事っていうのは
一般的にCMSから来る静的なコンテンツでしたが
しばしばインタラクティブなビジュアルも実現していましたと
そこでリッチは
HTMLのコンポーネントを埋め込んで
JSCudoのデータビジュアライゼーションを
十分なヘルパーで結合して
ニュースのスピードに合わせて
出荷するクリーンな方法を発見したんだと
なるほどねそんなことをやってたんですね
でリアクトが常にアプリに
Webアプリに最適で
Svelteは主に静的なサイトに適していると
言っていいでしょうかっていうのが
ちょっと問いがあるんですね
そういう今の話を聞いたの
それの問いに対して答えはノーですと
SWIXはそうかもしれませんがと言ってますね
SWIXはすみません
僕はちょっとよくわかってないのでごめんなさい
個人的にはそれぞれが同じ問題セットを
24:00
解決できると実は考えています
ただ開発者の人工工学
人間工学っていうのは
私が挙げたユースケースによって
もたらされることを理解してください
ですからあなたのチームがニューヨークタイムズに
近いサイトを作っているんだ
もしくはあるいは
Facebookに近いサイトを作っているんだったら
どちらかの数に偏るのかもしれませんと
なるほどね作りたいものをニューヨークタイムズか
Facebookかっていうのにちょっと比較してみたら
いいんじゃないかなってところですよね
続いてのコメントをどんどん読んでいきますが
状態とUIどちらが先ですかっていうことを
先っていうのは優先かな的な観点だと思いますが
っていう章に入りますね
このセクションですけど
これはモダンフロントエンドの
鶏と卵の問題になりますねって話をしています
そしてそれぞれのツールは異なる答えを持っています
ReactはJavaScriptを記述してその結果のUIを返す
いわゆるステートからUIというところですね
SvelteではまずUIを記述して
必要に応じてインタラクティブ性をバインドしますと
UI.bindのコロンステートって感じです
これによってJavaScriptを使用しない場合
例えばファンクションの何たらかんたらみたいな
で定義してJSXを返すみたいな
っていうものを使わない場合ですね
その場合は結構シンプルとなって
Svelteがよりシンプルさを感じるんじゃないかなと思いますね
単純にコンポーネントを書くだけですので
でテンプレートのところですね
テンプレートのバックグラウンドを持つ開発者ですね
例えばNanjaxとかVueとかAndroidとか
PlayHTMLとか
PHPだったらTweakとかSmartyとかあったりしたと思いますけど
そういうようなバックグラウンドを持っている会社としては
割と馴染みを実はSvelteの方があるんじゃないのって話をしてますね
HTMLのテンプレートっていうのをやったことある人は
しかしより複雑なステートマネジメントを行うには
Svelteの方が実は適してるかもしれないって言ってましたね
へーそうなんだ
制御された入力っていうのはその典型的な例ですよと
例えばそのテキスト入力があって
その入力に含まれるものをサイトの見出しに設定したいと
しましょうと
つまりユーザーが入力するたびにテキストが更新されることになりますと
これはリアクトのソリューションの一つで
ソースコードですね
リアクトのソースコードと今Svelteのソースコード
2つ記述されていて比較してますと
リアクトは一般的にUseStateを使っていて
入力があったらSetInputを使って
自動で更新をかけてますと
Svelteっていうのは同じようにHTMLを書いて
スクリプトを書いてるんですけど
変数を書いて単純にインプットのところにBindValueっていうのをやってるだけですね
とてもシンプルですね
っていう2つの比較をしてて
どっちが適してるかってのは結構ユーザーに
27:00
依存する形ではありますけど
一旦2つのソリューションの例を見せておりますと
それについてコメントがありますね
コードの大部分はJavaScript駆動で
想像に任せる部分はほとんど実はないですと
ここではSvelteが魔法のように
インプットプロパティを設定してくれていることに注目してください
またSvelteのシンプルさが好きで
魔法を受け入れる人にもいるかもしれませんが
リアクトは徹底していて
記述のところを細かく
ソースコードはその代わりリアクトのほうが長かったりしますけど
見た瞬間パッと分かるし
暗黙的なものがないっていう意味ではリアクトのほうがすごいかもしれないですね
リアクトのほうが最初に書かれるというのは予備知識として言いますけど
Svelteはそういうのを書かなくても
そもそも変更があったら勝手に変更されるっていうの
自動で変更されるっていうのも分かっているので
規律量は確かに少なくてちょっと魔法っぽい感じがあって
それを受け入れる人は全然Svelteでいいんじゃないのって話をしてました
開発者は多分リアクトのほうが好きなんじゃないかなっていう
勝手な僕の憶測ですけどね
今ので比較をガッと読んでいって
最終的なまとめのところです
一応昨日前回でも読んだんですけど
改めて今のバッと見ていってまとめを読んで終わりにしようかなと思います
どちらを読むのがいいんですかっていうところですけど
ここまでリアクトSvelteの対比を見てきたんですけど
もちろんこれはモーラ的なリストではないですし
チームがどちらのツールをも好むかっていうところについての
参考程度の理由をちょっと列挙してみましょうというところです
リアクトが適している場合ってところですけど
新たなチームがより強力なプログラミングのバックグラウンドを
持っているっていうチームですね
バックエンド技術に成立したフルスタックエンジニアとか
関数型プログラミングのマニアとかいるのかな
ジャバスクリプトの達人などがいる場合は
リアクトのほうが合ってるんじゃないのって言ってますね
もしくはプロジェクトが非常にダイナミックでデータドリブンである場合ですね
リアクトっていうのは大規模な状態管理を解決するために
構築されてるんでツールとかですね
ファーストパーティーかサードパーティーの両方ですけど
ツールっていうののレベルはどこにも引き劣りません
またプラットフォームを超えて
自分の仕事を再利用する予定があるという場合ですね
リアクトはもともとフレームワークに依存しないようになっているので
モバイルとかデスクトップアプリケーション
もしくはリアクトネイティブとウェブのリアクトJSみたいなところですね
っていうのは結構いい組み合わせじゃないのっていう話をしてました
続いてスベルトのほうの良さの話をします
スベルトが適してる場合っていうのは
まずフロントエンドに強いチームであると
テンプレートの言語の開発経験とかあったりとか
CSSページアニメーションなどに結構自信があるフロントエンドの開発者がいる場合とかは
スベルトのほうがいいんじゃないのって言ってますね
またプロジェクトがUI中心でウェブ用に構築されている
スベルトはそのCSSとかアニメーション3Dソリューションまでも組み込まれている
いわゆるそのマッテリ内蔵のフレームワークになりますと
30:01
リアクトっていうのはこれらのそれぞれについて
サードパーティーのソリューションを必要とするので
NPMでバーっと探さないといけないねって感じですね
もしくはあなたのチームが
より早くデリバリーする必要があるよっていうところですね
とにかくやっぱりスベルトっていうのは徹底したシンプルさと引き換えに
日々各行動をやっぱり減らすので
それでも減らしてるんですけどちゃんと人間が読める
過読性は維持しつつそのシンプルさを徹底してるんで
デリバリー早いほうがいいっていうのは
リアクトとスベルトだって話をしてましたね
でIf you are undecidedってところですね
もし決められない場合という話をしてます
場合はチームに両方のサンプルを提供しましょうと話をしてます
リソースがあればですねこれは
僕前も同じこと言った気がするけど
プロジェクトごとにリアクトとスベルトを切り替えると
特に便利だと思うかもしれないですね
またこの記事をシェアして
ウェブ開発者ってのはコンピューターにコードを打ち込むことだけじゃなくて
人々が自分の考えを伝えるための言語にもなっていることですよね
とにかく仕事に適した言語を見つけるために
議論を巻き起こすことはお勧めするので記事をシェアしたりとか
この記事自体もシェアして議論をしてみるっていうのは
結構いいんじゃないのって話でございました
自分で決められなかったら周りに答えを問うてくださいって
いうような意見ですね
すみません今日もだらだらと読んできたんですけど
この記事は一旦こちらで以上にしたいと思います
参考になったら幸いですけどね
僕も読んだ感じ性的なサイトっていうほうが
ニュースフィックスみたいな
フェイスブックのアプリとの比較っていうのが
一つの例として確かに分かりやすかったので
その辺を比較するといいかもしれないですね
とはいえ別にスベルトでフェイスブックみたいなアプリケーションを
どっちがいいかっていうのは好みに分かれる可能性も
もちろんありますけど
僕としては面白い記事だったなと思います
じゃあだらだらと読んだんですけど
今日の朝活はこちらで一旦以上にしたいと思います
お付き合いいただいた皆さん本当にありがとうございました
今日からまた月曜日ですね頑張っていけたらなと思います
お疲れ様です
