00:07
はい、6月26日日曜日ですね。
地獄朝9時半をちょっと待ってしまいました。
ごめんなさい。僕が寝坊してしまいまして、
昨日、本当に疲れていたようです。
はい、おはようございます。
AMMのkkeethこと桑原です。
では本日までと、朝活を始めていきたいと思います。
はい、えっとですね。
前回っていうか、昨日ですけども、
あ、ちなみに一昨日ですね。
昨日ちょっとスキップさせていただきますけど、
一昨日に、読もうという風に話をしていた、
リアクトのコンポーネントの設計周りの記事ですね。
翌の記事があって、
それを読んでいこうと思っていたんですけども、
ちょっと今朝、ツイッターをダラダラと見ていたら、
面白そうな記事が出てきて、
タイトルになりますね。
Vue 3 was a mistake that we should not repeat
って書いてありまして、
ちょっと言葉の強いというか、
悪の強そうな記事だったんですけど、
そのメンテナーの人たちも結構それに対してコメントしたりとか、
理解できる部分もあるけど、
ちょっと考え方が違ったりというか、
言葉が違うんじゃないのみたいなところがあって、
のがありました。
タイトルね、普通に日本語に訳すと、
Vue 3 was a mistake that we should not repeat
っていうのが全文に訳せて、
ちょっと強いなっていうのもあるんですけど、
実際でもVue 3に移行するへのコストがすごく高そうな
みたいなところの記事だったので、
これを読んでいこうかなと思いました。
はい。
やめたらさんですね。
おはようございます。
ご参加ありがとうございます。
ちょっとめっちゃ寝坊してしまいました。
タイトルの記事をダラダラと読んでいこうと思います。
はい。
タイトルに本文入ってますね。
Vue 3の最初の導入から4年以上が経ちましたと。
いくつかのRFCを通じた多くの議論と、
リアクトやベルトを含む他のモダンなフレームワークからの
多くの影響により、
Vueはおそらく最も強力で充実したフレームワークとなり、
あらゆる規模とアーキテクチャのアプリケーションを
徐々にサポートすることができるようになったのです。
エキサイティングに聞こえますね。
しかし真実はそれほど遠いものです。
それとはほぼ遠いものです。
それ以来多くの遅延とデスコープが起こりました。
Vue 3が最近新しいデフォルトになったとはいえ、
多くの重要なサポートライブラリは準備できておらず、
両方のバージョンに互換性を持たせる予定さえありません。
つまり多くのコードベースはVue 2から抜け出せず、
Vue 3のバージョンへの移行は簡単でも
容易でもないものになりましたよということですね。
エコシステムが追いつかないのは当然の話で、
今回Vue 2からVue 3は確かにすごい
破壊的な変更ですよね。かなり大きいと思います。
なのでVue 2のときにもコンポジションAPIを
導入できるようにしましたし、
Vue 3の機能のバックポートをいろいろ考慮して、
Vue 2にも使えるようにしていて、
なるべく移行コストも下がるように、
なるべくVue 2でもVue 3と同じようなことを
できるようにいろいろ対応していた、
03:00
予定していたつもりだと思うんですよね。
エヴァユーもそういうことをおっしゃっていましたしね。
なんですけど、この人はそういうことも
加味してもそういうふうに感じるというふうに
おっしゃっていますね。
容易でもないし簡単でもないのは当然だと思います。
こんだけ破壊的な変更があるというので、
僕らもその辺はある程度理解していますけど、
とはいえなかなか強いなという印象はありますよ。
ちょっと読んでいきましょうか。
誤解しないでください。Vue 3は素晴らしいです。
おそらく最高のフレームワークです。
しかしV2からの簡単な移行パスがないという事実は、
今後繰り返しにならない過ちですというふうに言っています。
なるほどですね。
やってはいけない、繰り返してはいけない失敗というのは
そこにあるというふうに言っていますね。
途中、この後多分出てくるはずですけど、
確かにアンギュラー感があるなと思いました。
アンギュラーJSとアンギュラーの移行というのは
確かに大変だったというか、完全別フレームワークなので
ほぼアプリケーション作り直しに近いんじゃないか
というところが正直あったと思います。
一応アンギュラーのACLAがいろいろマイグレーションの
サポートをしたりとか、割とコストかからないように
Google社も既にその辺は考慮して実装を進めていたとはいえ、
なんだかんだやっぱり作り直しに近いところがあるので
そこは結構大変だったんじゃないかなと思いますけど、
それの話とかなり僕は似たような感じがありますね。
ちょっとアンギュラーの騎士感を感じました。
はい。
もうぐらさんですね。
おはようございます。ご参加ありがとうございます。
タイトルのある記事をたらたら読んでいます。
はい、ビュー2の問題点ですね。
ビューというのは常に進歩的なフレームワークと考えられました。
進歩的というかプログレッシブですね。
フレームワークと考えられましたと。
オプショナルAPIか。
オプショナルAPIというのはすごい理解しやすく、
必要に応じてより複雑なパターンやライブラリを学習して
投入することもできましたと。
確かにここが結構強みだと思うんですけど、
学習曲線とは本当に小さくて、
ドキュメントもすごい充実していて、
好まれる理由というふうにされていたというのもありますよね。
投入コストと分かりやすさというのはかなり大きくて、
一気に広まった大きな要因になったんじゃないかなと思いますね。
そういうときもやっぱり素晴らしかったと思うと思います。
一方で共通ロジックをミックスインとかに抽象化する際に、
合成とかよりも継承を用いるというアーキテクチャの欠陥というのが
スケーラビリティの問題を引き起こしていて、
クリーンなコンポーネントの宣言とか原則の多くを
壊してしまっていたというところですね。
その解決策として導入されたのがコンポジションAPIであります。
やっぱりリアクトフックスの設計思想から
すごくインスパイアされたと思うんですけど、
やっぱり設計というか思想というのがものすごく素晴らしくて、
よりクリーンなコンポーネントというのが作れるようになったし、
制御とかいろんなロジックがあるようなことも、
細かいところまで制御がうまいことできるようになったというので、
06:00
いわゆるかゆいところに手が届くみたいなところですけど、
未来のところもできるようになったのが本当に大きいと思っていますね。
それと同じようなことをビューでもしたいというので、
コンポジションAPIが入ったと思うんですけど。
これは素晴らしい話だと思います。
素晴らしいんですけど、
じゃあリアクトで良くないという意見は僕はずっといまだに拭えてない。
ビュー3ちょっと僕もちょっとずつ勉強し始めて手を動かしているんですけど、
すごい疑似感しかなくて、
もうリアクトで良くないというのがずっと思っていたりはしています。
もちろんビューが素晴らしいことには全然否定する気は全くないですし、
本当に同感だと思います。
これ好みの問題ですね。
もう一つの重要な問題というのは、
タイプスクリプトのサポートであります。
もちろんビューのコンポーネントでタイプスクリプトを書くのは、
スクリプトタグにtype="ts",を追加するのと同じくらい簡単ではありますけど、
しかしテンプレートやストアの内部ではそのサポートに問題があります。
ビュー2の最大の課題はそこだと思いますね。
要はタイプスクリプト自体なので、
ビュー自体がタイプスクリプトを対応したりサポートを導入することが簡単だとしても、
その周辺内部ですね。
特にやっぱりストアが一番辛かったというのが正直に僕も同じことを思っていて、
そこがやはり懸念になったと思いますね。
現在のフロントエンドのアプリケーションでは基本的に
SPUを作ることがほぼほぼデファクトになっているので、
ストアというのは本当に切っても切り離せないんですよね。
そこがタイプスクリプトの導入がきついというのはやはり
でかい要因というか原因だと思いますね。
はい。
続いてビュー3ですね。
ビュー3のソリューションの話です。
完全な書き直しというのはフレームワークの内部を
改善するいいチャンスでしたと。
タイプスクリプトが対応されてリアクティビティ機構を含む
多くの側面というのがゼロから実装され直しましたと。
これによってバンドルサイズ、初期レンダリング、更新、
メモリ使用量の面で既にパフォーマンスの高いビュー2よりも
大幅にパフォーマンスが改善されましたと。
めちゃめちゃいい話ですね。
さらに多くの新機能も追加になりましたよと言っています。
はい。
コンポジションAPIもそうですし、
FSFCコンポジションAPIとか、
シンタックス収穫ですよね。
スクリプトセットアップというのがありますけど、
そのコンポジションAPIでシンタックス収穫が
投入されていますよと。
あとはテレポートですね。
これもいいですね。
あとはフラグメント。
あとはコンポーネントオプションの発行、
エミットってやつですけどね。
あとはクリエイトレンダラーAPIとかですね。
これアットビュースラッシュランタイムコア
っていうのがカスタムレンダラーになりましたよ
ということですね。
はいはい。
これも結構面白かったですね。
あとSFCのステートドリブンなCSSバリアブルですね。
Vバインドがそのスタイルの中に、
スタイルタグでVバインドができるということですね。
あとはSFCのスタイルスコープというのが入って、
いわゆるグローバルルールとかスロットサイドコンテンツのみを
対象とするルールを含めることができるのが
できるようになりましたという感じですね。
09:00
結構SFCのサポートがかなり大きく入ったよというのがあります。
あとはサスペンドですね。
エミットサスペンド2ですけど、
サスペンド機能も入ってますというところで、
本当にVue 3はかなりリッチとかモダンな
フレームワークになったなというのは
僕も感じています。
でもこれは新機能というのは、
開発者の体験を全体的に向上させるものであって、
常に歓迎されるものだと思ってます。
しかし、コンポジションAPI、テレポート、サスペンスなど、
そのほとんどは既にVue 2で動作しているため、
フレームワークの改良とは見なされないというのが
実情ですという意見ですね。
もうちょっとここに関して僕も、
疑問までいかないけどもやという感じはします。
僕の中では全然改良だと思いますけどね。
同じような機能が既にVue 2でも
動作しているのであれば、
それはそうだというふうに言いたいのは
わからなくはないですけど、
やっぱりコンポジションAPIの設計実装になったのは
僕は大きいと思いますけどね。
その責務の話が出てきて、
Vue 2は一つのコンポーネントの責務とか
関心事が多すぎるんですよね。
なので、そこをコンポジションAPIで
よりより制御しやすくなったとか、
細かく関心事とかの抽出であったりとか、
まとめができるようになったっていうのは
僕は大きいと思うんですけどね。
まあいいや。
続いて、Vue 2とVue 3の問題点、
課題点とかを見つけましたけど、
その上で本当の問題ですね。
リアルプロブレムっていうセクションに入りますね。
本当の問題っていうのはやっぱり
ブレーキングチェンジですよと。
破壊的変更がやっぱり問題の一つだと。
そしてその数もやっぱり多いと言ってますね。
この人はわざわざアロットオブゼムって書いてあるので
ブレーキングチェンジのリンクが貼ってますね。
これはVueの公式サイトですね。
vue3migration.vuejs.orgっていうのがあって、
ドメインでわざわざVue3migration.vuejs.org
っていうふうに作ってるんですね。
なるほど。そういうサイトがあるらしいです。
そこのリンクが貼ってますね。
その数が多くて、
その中にはイベントAPIの
玄関消極のような分かりやすいものもあります。
この一つはVueインスタンスが
イベントバスとして使えなくなることを意味しますが、
直接の代替品として使える
MIDやTinyEmitterのような
プラグアンドプレイのソリューションが存在します。
だってこれはオーディエンスじゃない。
でもMIDとTinyEmitterっていうのは
ちゃんと記事に載ってもリンクがありますね。
これは多分それぞれライブラリーですね。
GitHubのリポジトリのリンクがあってますね。
MIDってMITTってやつと
TinyEmitter、Tiny-Emitterってやつがあります。
全然知らなかったやつなんですけど。
これらのようなプラグアンドプレイの
ソリューションというのも一応存在しますよと言ってます。
これにはまだ作業が必要ですけど、
それほどリスクを負うことなく
適時に行うことができますと。
一応できなくはないと言ってますね。
12:01
一方で小規模または大規模なリファクタリングを
行わないと安全に行わない変更もあります。
Vue2で構築された既存の大規模なアプリケーションでは
非推奨または変更されたAPIのいくつかを
使用することになるでしょうと。
マイクリエーションビルドっていうのは
2つのバージョン間の端渡しになるはずでしたが、
多くの非推奨の機能があるため
大規模なプロジェクトはうまくいきませんと。
そんなにデカいけどデカいほど
さらっといかんでしょうね。
さらにいくつかの重要なサポートライブラについては
別のライブラリに移行することが公式に推奨されていて
複雑さをさらに増しています。
ここは多分苦渋の選択というか
Evan-Uも多分解決したいけどできなかった
ってところがあるんでしょうね。
多くの動く部品があるんですけども
たとえ移行ビルドがうまくいったとしても
コードのフリーズと膨大な作業が必要になり
大規模プロジェクトでは技術的塞に取り組むために
代わりに使える労働時間が多くなってしまいます。
続いてブレイキングチェンジの
カテゴライズしたような図がありまして
これがMiroで作られていますね。
Miroで4章限に分かれています。
コンプレキシティで複雑性とローとハイ。
これ何ですかね。
タイムリクワイヤーですね。
時間が必要なのと複雑さというところですね。
右に行けば右に行くほどやっぱり難しくて
左に行けば行くほど簡単であると。
上に行けば上に行くほどやっぱり時間がかかって
下に行くほど時間が短くなるよということですね。
という4章限に分かれていて
今回新しく入った機能だったりとかAPIというのの
難度みたいなところが4章限の表図で分かれています。
これはちょっと後頭でしゃべるのは結構時間がかかるので
後ほど見ていただければと思います。
View Migration Complexityというタイトルで
Miroで図示されています。
見る限り結構右上ですね。
難しくかつ時間がかかるものというAPIがかなり多いです。
なので確かにView3は時間がかかるんだろうなというのが
この筆者の人がまとめた観点でまとめたものなので
あれですけどかなり大変だったんだなということは
推測されますね。
続き読んでいきましょう。
必要じゃなかったものというところですね。
ビューというのは常に理にかなったフレームワークでしたと。
APIがどのように機能すべきかを推測してみると
おそらく正しいと思います。
しかしView3ではそうではなくなってしまいました。
例えばViewコンポーネントの新しい関数ベースの書き方に対する
Request For Commentですね。RFCでは
肯定的否定的を問わず圧倒的な数の反応が
一応ありましたと。この議論においてあなたがどのような
15:01
立場にいようとコミュニティがまんぷたつになることは
決して良い兆候ではなく、Viewの暗黒の日や
多くの人々がこのことで落胆することに繋がりましたと
言ってますね。
ちょっと僕RFCを実は読んだことはないんですけど
軽く開いてみてみます。
GitHubのView.jsの中に
RFCでリポジトリがあって
Appleの42番ですね。
めっちゃコメント多いな確かに。
このRFCは
Evang-U本人が言ってますね。
A Proposal That Consolidates Upon
Sharp22って別のやつですけど
これはAdvanced Reactivity APIと
Dynamic Lifecycle Injectionですね。
The Disconcretion Of A Juno
クラスAPIですね。
クラスAPIからDynamic Lifecycle Injectionと
Advanced Reactivity API
乗せ替えたいっていうところのプロポーターですね。
それについてコメント
本当にすごいですねこれ。
ぐっと1094だけどばっと170なんで
そんなまっぷたつに分かれたっていうほどまっぷたつじゃないと思いますね。
割とみなさん肯定的なんじゃないかと思うんですけどね。
ちなみにラブも297あったりするし
ターダーアーカも217あるんで
結構いい方に僕は受け取れますけどね。
もちろんコメント確かにずっと並んでいるのは事実としてあります。
カンバセッションが実に764に伸びているんで
すごかったですねこれ。
こんなにみんなでも関心ごとあるんだなって分かりますね。
数字だけを見ると
そんなにまっぷたつになったというわけではないし
いつも通りの良い悪いで悪いが少数派で
良いが多かったという感じがしますので
そんな暗黒の日に言っても他もないですね。
まあいいや。僕の感覚なんでみなさんがどう思うかわからないし
実際にそれぞれのスレッドのコメント自体を
読んでいるわけではないので
参考にみなさんも読んでみていただければと思います。
やっぱりみなさんにとってベストなソリューションなんて
100%なんてありえないので
それは否定発揮でもおかしくないと思います。
そういう方はリアクトとか今のスウェルトとかソリッドとかに
移っちゃうんじゃないかなと思います。
続いてドキュメンテーションですね。
ドキュメンテーションですけど
開発中に特に新しいフレームワークでは
Googleとかスタックオーバーフローというのがあなたの親友ですよと
日本だとKITAとかZENとかも
それに加わってくるのかなと思います。
現在Vue2の回答が
圧倒的な結果を支配していて
Vue3では多くのことが同じように機能しないため
混乱とフラストレーションを起こす可能性がありますと
Vue3で開発していて
いろんなGoogleとかスタックオーバーフローで調べるんですけど
18:00
Vue2の記事ばっかりが圧倒的に多数なので
同じものを見てもVue3じゃ動かないじゃんっていうようなところの
感じが出ますけど、これも仕方ないと思います。
完全に破壊的変更というか
ほぼ作り直しみたいなところがあるので
難しいですね。でもそれでもなるべく考慮するために
コンポジションAPIを最初からVue2にも導入したり
バックポートをしていたっていうのはいくつかの機能があるんで
全く動かないわけではないですけどVue2の
多くの機能は確かにVue3で動かないんだろうなというのは仕方ないと思いますね。
しばらくVue3は
このことはたぶん戦わなきゃいけないことになると思いますね。
多くのQ&Aとか
いろんな人がVue3の記事を書いてくれっていうふうに
もしかしたら裏で依頼してるかもしれないですね。
続いて
エコシステムですね。
フレームワークっていうのはそのエコシステムと同じくらい強力な
ものであります。非推奨の機能でありながら
物議を醸す決定と
説明責任というのは多くの貢献者
コントリビューターを倒さげて多くのライブラリーが放棄される
結果となりました。
しかし両方のバージョンをサポートする実現可能な方法を与えないのに
オープンソースライブラリーの遅延を非難することっていうのは
共感の欠如と全体像の理解の欠如を表しています。
かなり
この辺に対して割と怒りに近いような
文章を書かれてる感じですね。
ビュースリーに移行するためにはもちろん
エコシステムとかサードパーティー性のライブラリーの
サポートとか対応もほぼ必須だと思います。
ビュースリーだけでアプリケーション開発が完結する
というのはほぼ望めないと思いますね。
大きいのはでもナクスト3が割と追いついてきてるというか
もうベータ版まで来てるのでもうぼちぼち
メジャーリリースアップデートっていうのが見えてきてるので
そこは本当に大きい情報だと思います。
それ以外の細かなライブラリーがビュースリーに
どこまで追いつくのかっていうところが懸念にはなりますよね。
またビュー2とビュー3両方の対応をするように
各種エコシステムのライブラリーが対応しなきゃいけないのか
っていう問題もありますけどもこっちについては
ビュー2が2023年の末には終わるってことを
すでに公式が宣言していますので
対応してくださるんだったらそれに構わないですけど
基本的にはビュー3の対応にシフトしていけばいいと思ってるので
ビュー2に関しては今のままでいいんじゃないかな
という気はしています。エコシステムも時間の問題だと思いますけど
その辺も追いついてくると思うので
スピードは確かに遅いし時間はかかると思います。
オープンソースライブラリーの遅延っていうところが起きるので
そこに対してこの人は割と懸念という
嫌悪感を感じてるんだろうなって感じました。
難しい問題ですよね。
OSですなんて基本的に皆さんの自由意志というか
お金もらわれてるわけではないし
本当に皆さんの好みと自分の意思決定だけで
やられてるので
感謝ことすれど、確かにその人たちの対応を待つか
21:01
っていうのも大変なので、そこまで強い言葉を
この方がおっしゃるんだったら自分がエコシステムでライブラリ作ればいいんじゃない
っていう風に僕はちょっと思っちゃいましたね。
僕もXがライブラリ作って公開してる側の人間なので
欲しいものは作るがエンジニアだと思ったりはしてますね。
これはこれでちょっと言葉が強かったり
異論が唱えられそうですけど。
じゃあ続いていきましょう。
続いては過去ですね。
もしあなたが2015年頃に幸運にも行動を書いていたとするならば
当時最も有勢だったフレームワークである
アンゲラJSを使ってきた可能性があれば
いやないね。
アンゲラJSを使った可能性はないっすね。
まだアンゲラJSを詳しく知らなかったり
ビューの話も全然知らなかったときにアンゲラJSを選んだかって言うと
難しい問題があります。
もちろん世間、すごくアンゲラJSがめちゃめちゃ流行っていて
これじゃんというか
Googleが導入してきて
参入してきてフレームワーク作ったぞっていうので
かなり話題になったんですよね。
結構わーっと入ったと思います。
バックボーンドのノックアウトJSですかね。
あの辺が出てきたところですね。
他にもミズリルであったりとか
メデオとかいろんなフレームワーク
他にもいっぱい出てきたと思うんですけど
その辺が使われていたものになりますが
僕はそれでもアンゲラJSを使ったかってちょっと悩ましいですね。
もしかしたらバックボンドが出た可能性が個人的にはあります。
ちょっとアンゲラJSで苦しんだ記憶があるので
すみません早速予断しました。戻ります。
Vue3の移行というのは
アンゲラJSからアンゲラへの移行
バージョン1から2に移ることによく似てるよと言ってますね。
アンゲラJSとアンゲラというのは明確に公式が述べてます。
アンゲラJSというのがいわゆる1系のもの
アンゲラというのが2系のものだという風に
リポジトリも書いてますので。
多くの遅延と破壊的な変更というのはフラステーションを招いて
最終的にアンゲラはリアクトドVueに牽引されなくなったのですと
言ってます。これは仕方ないですね。
実際ダウンロード数でもアンゲラはやっぱりリアクトドVueに
ちょっと水を空けられてる感じですね。
さらにリアクトドVueでも水は空いてるんですけど
少なくともアンゲラが追いついてるということではないということは分かってますね。
ただすごくいいフレームワークであると僕は思いますけどねアンゲラって
あそこまでしっかり作り込まれていて
最初からタイプスクリプト導入もできてるしテストとか
P2のテストまでのフレームワークもガッと最初から入って
対応してくださっているので困ったらアンゲラの公式サイトの
ドキュメントとか見ていくと
エコシステム的なライブラリで何か欲しいのないかなって言うと
大体出てくるのでやっぱりワンパッケージになっているのは結構大きいと思います。
Rxっていう問題はありますけども
Rxの概念を理解するとすごく面白いと思いますし
プログラマーとしての幅も広がると思うので
いろんなことを加味すると僕はアンゲラは別に悪いものではないと思います。
24:00
好みによって分かれると思いますね。
学習コストの話がよく出てくるんですけど
別にVueとかReact使っても周辺ライブラリとかエコシステムの
学習したり調査をしたりとかその辺キャッチアップしたりすると
結局学習コスト全体っていうのは
アンゲラと別にそんなタイタナリで僕は思ってたりするので
あとそのAPIとか書き方とか公文とかに
好みがすごく分かれていてそこは多分アンゲラは弱いと
僕は感じちゃいましたね。
直感的ではないです。どう見ても。
というところがありますね。
ちょっと余談が過ぎるな。続けます。
アップデートですね。
アンゲラJSとの比較というのは多くのコメントを誘発しました。
私の個人的な経験ではどちらのケースでも移行は同じように
難しく時間がかかりかつ不明確でした。
いずれにせよこの記事のポイントはその間違いを二度と繰り返さないように
することなのでどうかそこから目を逸らさないでください。
ビューツリーとビュースリーと移行に対して
同じことがあるのでそこに対して二度とこの間違いを
しないでくださいと言ってますね。
間違いという言葉をこの人が使ってるのはなかなか
強いとは思いますけど。
またあなたがフルスタックエンジニアであれば充電法の前に
Pythonのエコシステムで同じ状況が起こったことを
ご存知でしょう。すみません僕はその頃Pythonを使ってないので
分かんないです。
Python3しかサポートしない新しいライブラリが
出現してしまったため約10年間多くのプロジェクトは
アップグレードすることができませんでしたと。
なるほどですね。
Pythonのメジャーバージョンアップの話か。
もちろんその後のPythonのリリースではバージョン3でしか
使えない新しい機能や素晴らしい機能が追加されるようになって
この厄介な状況はまだ本当に終わってないんです。
まだ終わってないんです。
Python3の環境って結構少ないと思うんですけどね。
でもまだまだ終わってないしPython2のライブラリを
そのまま残されているというのになると
割とエコシステムがまだまだ汚れているというか
ゴミが残ってしまったみたいな結果になっているような気がしていて
そこは大変ですしこの問題10年間まだずっと依存して
残っているというのがあるとやみやかいなと思いますね。
フレームワークのメジャーバージョンと言語の
メジャーバージョンアップとそれに対する変更というのは
やっぱりスケールのタイプが違いますよね。
言語まで行くインフラじゃないですけど
そこまでのレイヤーが低いところまで行ってしまって
メジャーバージョンの破壊的変更なんです。
それは大変なんだろうなとよくわかります。
新規プロジェクトであればPython3のものを使えばいいというので
スパッと解決はするんでしょうけど、2から3への移行を
まだ残している人もしくは2のアプリケーションとか
サイトがまだ残っているのであればそれは本当に
大変だと思いますね。
これと同じようなことがVueでもやっぱり起きているよ
という具体例のもう一つでしたね。
ラストですね。
The future. Will this happen again?
今後についてまた同じことが起こるのかなという話ですけど
27:01
進むべき道は逆戻りし、全てをマイグレーションビルドに
移植することのようには見えますけど、ダメージは既に大きく
開発満足度は良くなさそうで無視するわけにはいきません。
時間をかけてフレームワークを巻き込んでいくビジョンを
持つことはとても合理だんですけども、
Development Experienceですね。
世間一般じゃない僕らのDX。
開発者体験はフレームワークの中の中核的な責任の
一つになっています。
Vue4っていうのはエコシステム全体を考慮し
マイグレーションパスをやっぱり提供すべきですよと
言っています。そうなければ誰も使いたがらない最高の
これまでのVue3のマイグレーションの経験はどうでしょうかと
あなたの考えやアドバイスをコメントで共有してください
というところで記事は終わっていますね。
多分にこの人の試験とかが混ざった記事だと
思いますけども、
おおむね気持ちとしてはよくわかるし、
問題としても結構ピックアップされた課題とか問題点
っていうのは確かにそうだなって思う面はありますが、
一方でそれを含めた上でいろんなものを加味した
設計とかになってたりするので
僕はそんな言うほど問題というか
あくまではいかないとは思ったりはしてますけどもね。
一応、
10時きてしまったので終わっていこうと思うんですけど
この記事に関する
リプライとかコメントが
Twitterの方のコメントでスレッドが流れてるんですけど
この辺でサードパーティーじゃないわ、
メンテナンスの方々が
この記事についてのコメントをざっと書いてくださっていて
そこのコメント、全部英語なんですけど
それでも読む価値はあると思ってます。
これに対しての学びとか試験とかも結構書かれていたりするし
いろんな観点というのがあると思うので
ここも結構読むことをお勧めしますね。
基本的にみなさん、ビュー自体が好きな方が
コメントをしてくださっているという印象があって
強い言葉を使うほどのものでもないんじゃないのとか
表現にニュアンスが違うんじゃないのみたいなところもあったり
文章のコメントに対しても
微妙なニュアンスの違いがあったりするみたいなところも書いてあったりするので
興味があれば読んでいただければなと思います。
この後、本題となったTwitterトークも
リツイートしておきますので
ご興味があれば読んでいただければなと思います。
時間が過ぎてしまったので
今日はこちらで以上にしたいと思います。
今日も日曜日からだらだらと読んでしまったんですけど
ご参加いただいたみなさんありがとうございました。
明日は前回読もうと言っていた
リアクトコンポーネントの設計周りの記事ですね。
超ボリューミーなやつなので、多分3回ぐらいに分かれる気はしてますけど
そこを読んでいこうかなと思うので
またギルリとご参加いただけたら幸いだと思います。
一緒に勉強できたらなと思います。
日曜日みなさん良い休日をお過ごしください。
ではでは。
