00:06
11月20日、日曜日ですね。時刻は朝9時を回りました。
えー、昨日も大変申し訳ないです。昨日はですね、あのー、フロントエンドカンファレンス沖縄がありましてですね。
まあ、それの登壇があって、朝9時のリハーサルだったってことを思い出してですね、すみません。朝活を急遽スキップしてしまいました。
はい、今日はやっていきたいと思います。
おはようございます。ユメミのkeethこと桑原です。
では、本日も朝活を始めていきたいなと思います。
で、えっとですね、相変わらずちょっと朝寝坊しまって遅くなってしまって申し訳ないんですけど、
昨今ですね、JavaScriptのフレームワークで、なんか比較対象がものすごく増えましたねっていうのがすごく思ってます。
まあ、数年後には消えるものもどうせあるんでしょうねというのは前提の上で、ただ、どんなコンセプトとか、新しい機能とか、
はい、なんか新しい概念とかがもし入ってるんだったらそれは気になるところで、
まあその設計だったり思想だったりコンセプトっていうのをちょっと勉強したいなっていうのがあって、
とりあえず、ざっくりと比較記事を読んでいこうかなと思いました。
で、今日はastroとnextとremixの比較対象の記事を見つけたので、それを読もうかなと思ってます。
まあ、最近その比較対象のJavaScriptフレームワークで言うと、
まあ、next3ももう出ましたので、next3がホットな話題の一つだと思います。
で、あとはnextの13ですね。13が出て、なんかゲットサーバーサイドプロプスがなくなったんですよ。
配信になったみたいな噂を聞いて、僕まだnext13の更新リリースを読んでなくてですね、
ちょっと大変に申し訳ないって感じですけど。
で、その2つがまあやっぱりその比較対象の2大巨頭ですけど、
そこから今日タイトルがありましたけど、astroってものとあとはremixですね。
これも最近すごい話題ですし、なんかちょいちょい名前を聞きますね。
あの、いろんな記事が出てるってのも見てますので、この辺と、
あとは仮想ドムを辞めたっていうそのsvelteと、
svelteはあのsvelteキットがとても熟成してきたなっていう感じが、
昨日のフロントエンスカンファレンス沖縄でも何本も登壇があってですね。
svelteキットというよりもなんかビートの話が結構多かったイメージはありますけど、
でもsvelteキットの話も2,3本出てて、やっぱすごく話題なんだなっていうか、
いいフレームワークだなと思いました。
で、あとはsolidjsですね。
solidjsもそのなんかいわゆるリアクトにおけるnextjsみたいなやつがあって、
まあそれのような、名前忘れましたけどsolidjsのやつもあると。
で、まあその2つが仮想ドムを辞めましたっていう系のフレームワークでの
なんかなんとなく僕の中で2大共闘なのかなと思ってました。
で、最後、なんだっけ、
僕が最近注目している既存のプロジェクトのjsをかなり削減できるし、
とにかく高速だっていうquickっていうフレームワークがありますね。
はい、というところで、本当に最近比較するものが多すぎてですね、
キャッチアップ追いつかんし、本当に手伝ってほしいっていうか、
みな、誰か、全部の比較記事みなさん書いてくれって感じの気分です。
はい、こんな同時にJavascriptフレームワーク6個、7個、
比較対象が出るとは想像しなかったので大変なんですけど、はい。
まあそんなところで、今日はそのうちの3つですね、
比較の記事を読んでいこうと思います。
で、この記事はですね、
03:01
2027年6月2日なのでちょっと古いかもしれないですね。
5ヶ月前、約半年いかないかぐらいの前の記事なので、
ちょっと古いかもしれないですし、
JSのフレームワークってやっぱり進化とか変化がとても早いものなので、
せっかく今の仕様で作ったっていうのに、
気づいたら新しい機能入ったとか、
これもう必須以上になったよとか結構あるので、
あくまで参考として今1回読んでいこうかなと思っています。
はい、まあちょっと前置き長くなったんですけど、
じゃあ早速書いていきたいと思います。
まずはサマリーTLDRですね。
この記事ではWebアプリを構築するための3つの人気フレームワーク、
Astro、Next、Remixの3つを比較します。
パフォーマンス、ハイドレーション、ユースケース、サーバーサイドレンダリング、
使いやすさ、コードスプリッティング、統合などの側面を比較していこうかなと思っています。
あなたのプロジェクトに最適なフレームワークはどれかというのをぜひご覧ください。
この記事でおそらく結論は言わないと思いますし、
これがあなたにとってベストというわけではなく、
それぞれの用紙箱と語ってみなさんの気味でという話だと思いますけど、
読んでいきたいと思います。
モダンなフレームワークの導入というのは、
高速なウェブサイトを構築する上で革命的なことでした。
これらのフレームワークの多くはリアクトの素晴らしさを活用し、
ルーティング、サーバーサイドレンダリング、SEOなどの
リアクトの制限を一切受けない優れた製品を作り出しています。
どのフレームワークが最適かを知ることとは、
フレームワークの徹底的な研究が不可欠です。
この記事ではリアクト上に構築された3つのフレームワークの比較について
深く掘り下げていこうと思います。
パフォーマンス、ハイトレーション、ユースケースなどのメタリックさを見ていきます。
確かASTROもそうですし、
NEXTは言わずもがなで、REMIXも確かそうですよね。
要はリアクトをベースとしたフレームワークでしたよね。
記事上ではリアクト上にという、リアクトの上に乗っかった
フレームワークみたいな感じの言い方をしますけど、
リアクトの拡張というかラッパーだったような気がしますね。
だからこそ話題になるというか比較対象になるというのはよくあると思いますね。
ASTROとREMIXは言われそうです。
ASTROは確かリアクトをベースというわけではなくて、
リアクトだけじゃなくてVueでも動かして、
メインとなるJSフレームワークは別に何でもいいよ
みたいなところが記載あったような記憶です。
ちょっと漠然としますけど、もしかして間違ったらごめんなさい。
でも一応リアクトでも使えるというところで
今回の比較対象に上がったんだろうなと思います。
ここからTABLE OF CONTENTSはどうせ読んでいくのでいいと思いますけど、
このウェブアプリケーションにあって、
NEXT、REMIX、ASTROのそれ何ぞやという話をして、
実際に比較の記事に入っていくと。
比較のベースとなる考え方はまずパフォーマンス、
続いてハイドレーション、続いてユースケース、
4つ目にサーバーサイトレンダリング、最後は使い勝手ですね。
Ease of Useです。
ラストがコードスプリッティングですね。
この6個の項目に分けているというところですね。
あとはエクステンシビリティ、拡張性だったりとか。
06:01
最後、テイクアウェイズのところのキーを離して終わりというところですね。
そんなところのTABLE OF CONTENTSでした。
今日朝で申し立てるのもありますけど、
今日中に読み切れるかちょっと分からないんですが、
長くなったら明日に続こうと思います。
では行きましょう。イントロダクショントゥウェブアプリケーションですね。
まずは入門ですけども、ウェブアプリケーションというのは
インターネット上の多くの人にとってコミュニケーションの中核となっています。
リアクトのようなライブラリの登場により、
ウェブアプリケーションと開発者のワークフローというのを改善するために
作成されたフロントエンドフレームワークの数が急増しています。
この記事ではアプリケーションですね。
ウェブアプリを構築するための3つの人気フレームワークである
Remix、Astro、Nextを取り上げ、
それらの類似点だったり相違点だったり、
次のウェブアプリケーションでそれぞれを検討すべき理由というのも
ちょっと見ていこうかなという話です。
日本ではまだそんな人気というほど流行っていないので、
やっぱり海外と日本で時差があるなというのは
すごく感じる一言だと思いますね。
では一つずつ見ていきましょう。
まずWhat is Next.jsです。
それぞれのWhat isはとても短くシンプルに書かれていますね。
Next.jsというのはウェブアプリケーションを構築するための
オープンソースのリアクトフレームワークになります。
リアクトをベースに構築され、
シームレスで高速なエクスペリエンスというのを提供しますよと。
ページベースのルーティング、サーバーサイドレンダリング、
静的生成ですね、
スタティックジェネレーターとかのサイトを構築するための
作れた方法などをすぐに使える機能を備えています。
またタイプスクリプトのサポートだったり、
豊富な開発者のエクスペリエンス、
あとスマートなバンドルも備えていますよと。
これらの機能によりNext.jsというのは
Webアプリケーションを構築するために
最も広く使用されているリアクトフレームワークの
一つとなっていますよというところです。
リアクトのフレームワークというともう完全に第1位というか
第1級なのはNextなんだろうなというのはつくづく感じますね。
それ以外もいくつか出ているでしょうけども、
あんまり知らないなという感じですね。
続いて、次リミックスですね。
リミックスというのはリアクトベースのリッチな
ユーザーインターフェースを構築するためのフレームワークで
サーバーサイドレンダリング機能を備えています。
リミックスを使うと開発者はフルスタックアプリケーションを
構築することができます。
これ何か一昨日の記事で読んだかな。
読んだ記事でも似たようなことをおっしゃってましたね。
フロントエンドでリアクトを使ってバックエンドの方もサーバーを実行します。
キャッシュバリデーションだったりタイプスクリプトのサポートだったり
ダイナミックルートのようなボックスの機能というのは
付属していません。
キャッシュバリデーションとかTSサポートをしていないという
これ結構ネガティブポイントじゃないですかね。
現代のフロントエンドの中ではタイプスクリプトはほぼ必須だろう
みたいな流れがあると思うので。
なるほどでした。
ダイナミックルーティングもないのはちょっとどうなんだろうな。
09:01
そういう意味ではまだ進行というか若いフレームワークなので
まだまだ機能拡張が足りないというか
そこの辺が今後の期待なんだろうなと思います。
備わってきたときにリミックスはどういう姿になるかというと
ネクストとの比較というか差別化をどこで図るかは結構難しい気がします。
では続いていきましょう。
Astroです。
Astroというのはフロントエンドエコシステムにおける
最新のフレームワークになります。
Astroはリアクトの上に構築され
ウェブアプリケーションのためのより合理的なアプローチを提供します。
アプリケーションを利用されるシングルページアーキテクチャの代わりに
アイランドアーキテクチャのアプローチを使用しています。
この辺で常にモダンですね。
アイランドアーキテクチャアプローチというのはサーバーサイドでレンダリングされた
ウェブページの小さなチャンクに集中した
インタラクティブを即席にします。
Astroで構築されたサイトというのはよりパフォーマンスが高く
全体的に優れたユーザーエクスペリエンスでUXを提供します。
ユニークな機能としては
テンプレート言語とフレームワークに依存しないことが挙げられます。
フレームワークにとらわれないということは
ビューやスベルトなど様々なJavaScriptフレームワークの
UIコンポーネントを使ったウェブページの構築をサポートするということです。
なるほどですね。
どんなフレームワークでも使えるというのは
厳密に言うと各フレームワークのテンプレートとかに
依存しないということです。
根本的にはリアクトベースなんですけど
他のフレームワークで作られたコンポーネントとかも
使えるようにサポートしているということですかね。
それはそれでまたいい話ですね。
フレームワークごと乗り換えなくていいというのは結構いい話ですね。
既存の資源をそのまま導入できると言うと
それは熱いですけど
中のソースコードを見てみたくなりましたね。
なんか改造してそうだなという感じがしますけど。
続いてAstroのユニークな機能のもう一個というのは
ビルドプロセスでサイトを静的HTMLにバンドルすることです。
つまりAstroで構築されたサイトでは
最終的なページにはほとんどJavaScriptが使用されないということです。
いやこれすげえな。
なるほどね。
静的なファイルにビルドをする。
いろんなもので書かれたものが最後CSS、HTML、JavaScriptに
変換されるんでしょうけど
ここで注目するのは静的HTMLにバンドルをしているということですね。
これは結構デカいですね。
いろいろなものを計算して終わって
アクションのためだけのもの、イベントハンドラーとか
だけ残してそれ以外はほぼほぼJSO読み込まないということですよね。
それは速くなるわという感じがしますね。
まあ人気だろうなそれはな。
昨今のWebフロントエンドって複雑さが増していくし
パフォーマンスがより求められているので
パフォーマンスが速くなるよって言われたら
ではここから実際のコンペアリングですね。
比較をやっていこうということでした。
このセクションではAstro、Limix、Next.jsの
もちろん比較します。
12:02
この比較はどちらが優れているかどちらが速いかを示すものではなく
どのフレームワークが最適か十分な情報を得た上で
選択できるようにするためにそれぞれのフレームワークについて
見ていきましょう。
パフォーマンス、ハイドレーション、ユースケース、使いやすさなどの
テーブルコンテンツとそのままでした。
サクッと今読んでいるんですけど
一個一個の項目に関してただのテキストベースで
メトリクスを取ったとかソースコード的な比較をするとか
わけではないので書簡を語られている感じですね。
これはあくまで参考程度に聞いて
自分で手を動かしてみないと分からないかもしれないですね。
ではまず、ベーストオンパフォーマンス
性能で比較しましょうということです。
アストロっていうのはスピード重視で作られているため
それなりに早いですよと。
アイランドアーキテクチャーのアプローチっていうのは
オンサイトエンジンで非常に上位に表示されるため
SU対策にも強いと。
優れたユーズエクスペリエンスを提供し定型的なコードを削除しますと。
ほとんどのCSSライブラリとフレームワークをサポートしているため
スタイルサポートのための優れた基盤が付属していると。
なんか夢のようなフレームワークに聞こえますね。
実際使ってみたら
開発体験ってどうなんだろうって気になりますけど
エンドユーザー、本当にユーザーエクスペリエンス、UXに関することに
かなりフォーカスを置いたフレームワークだなって感じがしますね。
それはとてもいい話で
ただ実装する僕らが意外と時間がかかるとか
闇があるなっていう感じなフレームワークは
多分僕らが経営しがちなので
それはそれでどうなのっていう感はありますが
続いてリミックスですね。
リミックスはサーバー上で並列にデータをロードすることによって
より高速なデータ取得を誇ります。
リミックスはサーバーサイドレンダリングをサポートしていて
サーバー上でページをプリレンダリングします。
ネクストで持っているプリレンダリングの概念もこっちに組み込まれてるんですね。
アストロではJavaScriptをほとんど使わずに
静的バンドルされたHTMLドキュメントが得られますが
リミックスではそうではないと。
Java側の方に面倒なこととか重い処理を全部バッとぶち投げると。
フロントエンドは計算されたものが返ってくるという。
サーバーサイドレンダリングベースのことをやる。
もしくはプリレンダリングのことをやるということですね。
これはこれでいいんですけど
リアクトの次期機能の目玉である
リアクトサーバーコンポーネンツの話
どうするんだろうってちょっと僕思ってるんですけど
かなりバッティングするという。
リアクト上に乗っかったものなので
それを踏まえた上でのサーバーサイドのレンダリングをサポートしているような機能になっているんだったら
それはそれでいい話ではあるけど
そしたらもうNextで良くないっていう気がしてくるので
ここが比較対象なんでしょうね。
続いてNext.jsですね。
Next.jsは静的ビルドとサーバーサイドレンダリング機能というのが誇ります。
またNext.jsはデータを取得するための
様々なメソッドをすぐに利用することができます。
15:03
ISR、インクリメンタル静的生成ですね。
CSR、いわゆるクライアントサイドレンダリングですね。
SSG、またはスタティックサイトジェネレーションですね。
ラストはSSR、サーバーサイドレンダリングなどがあります。
4つのレンダリングの方法というのをサポートしていますよと。
またCSSフレームワークや
ライブラリーというのも全然サポートしているということで
かなりサポートしやすいフレームワークだというのは
皆さんも既に使われていると思うのでご存知だと思います。
比較というかそれぞれの良さを語ったような感じに聞こえましたね。
ちょっと物足りん。
続いてはベースドオンハイドレーションですね。
昨今ハイドレーションの話は結構重要な話なのでね。
ハイドレーションに基づく比較です。
ハイドレーションというのはクライアントサイドのJavaScriptが
静的なHTMLページを動的なページに変換する技術になります。
これによってユーザーというのは
ページ上にレンダリングされたコンポーネントを見ることができますが
イベントハンドラーが付属していたため
素晴らしいユーザーエクスペリエンスを得ることができます。
静的なページではユーザーとの
インタラクションの前にハイドレーションが発生します。
そのためユーザーエクスペリエンスが低下しますよと。
またシステム的ないわゆるオーバーヘッド的なものも
発生するというところですよね。
できればハイドレーションが少ないほうが本当はいいとは
僕は思っていたりしますし。
ハイドレーションがあっても仕方ないんですけど
それがどれだけ早いのかというのが結構重要かと思ったりしますね。
一方でどこに良いUXを実装するかという意味では
ハイドレーションがあってもいいんじゃないかと
いうところもあったりするので
ここは結構設計とか腕のミスどころ感はあるかなと思いますね。
今のが一旦ハイドレーションの話で
アストロというのは部分的なハイドレーションと呼ばれる処理によって
解決していると。
パーシャルハイドレーションと言ったりするらしいですね。
パーシャルハイドレーションというのはページの残りの部分を
静的なHTMLままにしておいて
個々のコンポーネントを必要なときだけロードする処理のことですと。
アイランドアーキテクチャはその小さなチャンクの
インタラクティビティを促進するためこのプロセスの鍵となるものです。
要はアイランドアーキテクチャということですね。
僕これまだやったことがないんですけど
やり取りとか通信が増えるので
果たしてそれはそれでどうなのという気はしていますけどね。
もちろん必要なものを取りに行くので
画面の方では
初期のレンダリングがそんなに遅くならないという
メリットが大きいですよね。
全部が一旦全部取ってきてそれを中でHTMLとか
わちゃわちゃ計算処理をして最後レンダリングするときは
画面上のものだけになったら結果そのオーバーヘッドの処理が
オーバーヘッドが発生するので重いよねというのがあるので
いいんですけどその辺通信周りはどうなんだろうが
やっぱり僕はどうしても気になりますね。
早いことは正義ではありますが
じゃあユーザーのギガを使っていいのかというのは別の議論な気がしました。
18:01
今のがアストラルの話で
リミックスですね。リミックスは部分的なハイドレーションを
実はサポートしておりませんよーっと。
リミックスはリアクト18の新しいサスペンス機能と連携することが
推測されますがやっぱりそうだよね。
リミックスでは部分的なハイドレーションをサポートされていません。
なるほどですね。じゃあもう独自路線を走るってことなこれは。
ちょっとこうやって聞くとリミックス
ちょっと前に読んだ記事ではかなり
魅力的な話をずっとしていて
なんでリミックスに乗り換えたかっていう話もそこで語られていたので
わかるんですけどこうやって読むと
まだまだ熟識ってないというか
穴がいっぱいありそうだなっていう感じには聞こえるので
まあまあ触ってみることはわからないが
予測の域は超えないにしても僕の中で
マイナスになってきたなって感じですね。
こうやっていろんな人の記事とか
感想とか思想を読んでみないと
比較はむずいですね。触ってみるのがもちろん一番でしょうけど
自分個人の観点だけで
このJSRもこんなもんだなっていうか
改めて反省する次第ですね。
またこうやっていろんな記事を書いてくださっていることに本当に感謝なので
やっぱり皆さんどんなちっちゃかったり
全然個人の感覚ですっていいので
アウトプットしていただけるのすごくありがたいなと思いますね。
いろんな観点とか僕が足りてないしざっていうのが見えたりするのでね。
そうやってOSSは成り立っているんだなっていう大きい話になっちゃいますけど
まあいいや。
ハストラリミックスの比較をしたので次はNEXTJSですね。
NEXTJSも部分的にはハイドレーションには実は対応していないと。
NEXTJSっていうのは非JavaScriptのウェブサイトを
実験的にサポートは一応していますが
コンポーネントのハイドレーションはサポートしていません。
これでも今後サポートするんじゃないですかね。
リアクトサーバーコンポーネントが出るっていう話なので
結局NEXTもそのへん対応しなきゃいけなくなると。
確か見た気がしますよね。レイアウトRFCも読んだし
その後のリアクトサーバーコンポーネントのRFCも
過去に読んだんですけど、確かそのへんNEXTと連携してるみたいなことを
中の人がブログで書いてた記憶があるので
結果はやると思いますけどね。
そうやって見るとリミックスだけ外れ者感があって
さあどうするんだろうっていうのが次の気になる観点ではありますね。
多分このユースケースですね。
ユースケースの比較を読んだら今日は多分終わりにして
明日はここから続き読んで
結論のとこまでいっていきたいなと思います。
ベースと本ユースケースです。
シングルページのアプリケーションを構築するNEXTとASTRO
っていうのはシングルページのアプリケーションを構築するのにすごく適しています。
リミックスは動的なデータを扱うサイトの構築に適しています。
まあまあそうね。
サーバーとと22366ってことはたぶんそうですね。動的なもの。
リアルタイムまでいくかわかんないですけど
基本的には動的なデータ変更ってところに重きがあると。
セッションとクッキーセッションとクッキーですね。
はいはい。
21:00
いわゆるセキュリティもあると思いますけど
情報を保存するために使用されるものですよと。
クッキーはクライアント側のマシンで使用され
セッションというのはサーバーとクライアントの両方で保存されますと。
ASTROとNEXT.jsっていうのは
セッションとクッキーをサポートしていないと。
じゃあ僕らでガリガリやるしかないと。
しかしリミックスのセッションとクッキーのサポートを組み合わせると
以下のようなライブラリーがありますと。
リアルタイムのマルチユーザーサイトというのがまず一つ目ですと。
あ、これなんだ。
よく元々の記事を見ると全部一個一個がドットになっているので
そういう項目ごとに分けているということですね。
はあ、なるほどでした。
一つ目の項目がシングルページのアプリケーションを構築する
という意味でまず比較をしていたということですね。
続いての比較がセッションとクッキーというのが比較だったんですね。
次の比較がリアルタイムのマルチユーザーサイトというところは
次の比較だそうですね。
Next.jsとAstroというのはポートフォリオサイトのような
ブログのような静的サイトを構築するのには向いていますと。
また認証や異なるユーザーへの対応などにも実は最適です。
リミックスは動的なデータにフォーカスをした
アプリケーションを構築するのに適しています。
サーバーサイトレンダリングのみをサポートしているので
ビルド時に静的ファイルにバンドルされることはありませんと。
このフィッシャーは割とリミックスについてあんまり語られていないので
実はそんなに好きじゃないのかなというふうに見えますね。
最後4つ目ですね。
4つ目はCSSのサポートについてですけど
AstroとNextはCSSフレームワークとライブラリの
アウトオブボックスというのをサポートしていますと。
リミックスのスタイリングは少し異なっていて
ほとんどのスタイリングフレームワークはサポートされていない。
しかしリミックスはCSS組込みのスタイルシートというのを
リンクするためにリンクタグを使います。
ということは素のCSSを書く方に
リミックスは重きを置いているような感じですね。
こうやってみると開発体験リミックス
すごく僕は低いようにどうしても聞こえちゃいますね。
皆さんどう思うか分からないし
別にフレームワークを使わなくても良くないという。
SASとかオールドCSSを使ってガリガリ書く方が良いというのだったら別に良いと思いますし
これを聞くとTailwindは相性が良いじゃないですかね。
要は単純にユーティリティクラスの塊ですからね。
なのでそれだけを導入するんだったら
意外といけるのかなという気もしました。
もちろんNextとAstroはTailwindをサポートしていると思うので
そんな比較はできないと思いますけど
サポートしていないからその代わり自分たちで書くということになる。
大きなメリットとしてはCSSのUIフレームワークを
読み込まなくて良くなる。
リソースが軽くなるというメリットはあるかもしれないなと思います。
Astro Nextもビルドするときに色々なものを削除するとか
削減するみたいな機能は確かあったはずなので
どれだけ差が出るかはちょっと分からないですけど
CSSはサーバー性が悪いだけに特化して
それ以外は排除しているというところで
確か入門のしやすさというか覚えるものとか勉強するものは少なそうですし
読み込むものが少ない分それは軽いし
24:02
速いんだろうなというのがあって
速さをどう再現するのかという意味で
リミックスは削ぎ落としたという感じに聞こえましたね。
これは好み分かれるだろうなと思いますね。
リミックスは僕は今のところ
衰退する感じがすごく強いとは思いましたね。
Astroはその代わりにNextとの比較で負けて
Nextになるんじゃないかという気もしていますが
この辺は結局歴史が答えをくれると思うので
ちょっと眺めてみようという感じですね。
ではここで一旦区切らせていただいて
明日続き読んでいきたいなと思っています。
途中今日は雑談が多すぎて本記事
そんな長くないのに全然終わらなかったので申し訳ないですけど
明日もゆるく読んでいきますので
ご興味あれば参加いただければ幸いです。
というところでやっぱり昨今のJavaScriptフレームワークは
比較対象が本当に多いのでどれがいいか分からないですけど
昨日のフロントエンドカンファレンス沖縄に参加した感じだと
スベルトキットの話とビートの話がすごくいっぱいあって
そうかそうかって感じですけど
スベルトキットは最近だとしても
スベルト自体は海外では結構すでに出てきて
日本にはやっぱり若干遅れて入ってきた。
今こうやってカンファレンスで実例が語られているので
やっぱり時差あるんだろうなっていうのは繰り返しになりますけど
すごく感じました。海外の記事を読んでいくって本当にいいなと思いましたし
海外の方が書いているものが今のトレンドになるかもしれないし
他の人たちの語られているものってすごくいいので
そこを見るといいなと思いました。
もう一個情報のキャッチアップの仕方としては
それぞれのフレームワークとかその界隈の
海外の人のツイッターをフォローして
その人のツイートを見るのがいいんだろうなってつくづく思いました。
海外の方ってリプでめちゃめちゃコメントしたりとか
いろんな人たちが始めましただろうか関係なく
どんどんコメントしていくんですよね。そこで議論が進んでたりするので
もちろんGitHubのリポジトリ集だったり
そこで議論するのも全然参考になるし勉強になるんですけど
本音ベースとか感想レベルというところで言うと
僕はツイッターの方が一律の長があると思っているので
ツイッターを追うと結構いいのかなと思っていました。
そんなところで今日の朝方は以上にしたいと思います。
今日はイカノコさんご参加いただきありがとうございました。
また明日も読んでいきますのでよろしければ参加してみてください。
では日曜日ですね。今日も一日ゆっくり休んでいただければなと思います。
終了いたします。
お疲れ様でした。
