クリスフェルディナンディとポッドキャストエピソード21を壊す：現代のベストプラクティスはウェブに悪いですか？

今日、私たちは現代のベストプラクティスがウェブに悪いのかどうかを尋ねています。 現代のフレームワークは私たちを間違った道に導いていますか？ 私はリーンウェブの専門家であるクリスフェルディナンディと話をして調べます。

メモを表示

• ポッドキャストのリンクとメモが記載されたChrisのページ
• リーンウェブブ​​ック
• ウェブ上のクリス・フェルディナンディ
• Twitterのクリス
• バニラJavaScriptポッドキャスト

毎週の更新

• 「デザインワイヤーフレームをアクセシブルなHTML / CSSに変換する」
  ハリス・シュナイダーマン
• 「ElectronとVueを使用したデスクトップアプリの構築」
  ティミ・オモイエニ
• 「読みやすさを向上させるための最新のCSSテクニック」
  EdoardoCavazza著
• 「Reactでスタイル付きコンポーネントを使用する方法」
  Adebiyi AdedotunLukman著
• 「スケッチでポルシェ911を作成する方法」
  ニコラ・ラザレヴィッチ

トランスクリプト

Drew McLellan：彼は、Vanilla JS Pocket Guide Seriesの著者であり、Vanilla JS Academy Training Programの作成者であり、VanillaJSポッドキャストのホストです。 彼はTipsニュースレターを作成し、毎週10,000人近くの開発者が読んでいます。 彼はChobaniやTheBostonGlobeなどの組織で開発者に教えています。 また、彼のJavaScriptプラグインは、Appleやハーバードビジネススクールなどの組織で使用されています。 何よりも、彼は人々がバニラJavaScriptを学ぶのを助けるのが大好きです。 つまり、彼はフレームワークよりもバニラJavaScriptを選んだほうがいいと思いますが、犯罪を犯した可能性が最も低い人物として、彼がかつて警察のラインナップで選ばれたことを知っていましたか？ 私のスマッシングの友達、クリス・フェルディナンディを歓迎してください。 こんにちは、クリス。 元気ですか？

クリス・フェルディナンディ：ああ、私は壊している。 お招きいただきありがとうございます。

ドリュー：今日は、このリーンWebの概念についてお話ししたいと思います。これは、あなたにとって情熱的なことですよね。

クリス：そうですね。

ドリュー：シーンを設定してみませんか？ リーンウェブについて話すとき、私たちが解決しようとしている問題は何ですか？

クリス：ええ、素晴らしい質問です。 すべてのリスナーへの警告と同じように、このエピソードでは、小さな老人が雲に向かって怒鳴る可能性があります。 私はそれを避けようとします。 今日のWebの構築方法を見ると、過剰に設計された混乱のように少し感じます。 今日のベストプラクティスとして私たちが考えていることの多くは、実際にはWebを悪化させているのではないかと私は信じるようになりました。

クリス：リーンWebは、シンプルさ、パフォーマンス、そして開発者の経験に焦点を当てたWeb開発へのアプローチです…申し訳ありませんが、開発者の経験ではありません。 むしろ、開発者の経験よりもユーザーエクスペリエンス、そしてチームの観点から物事を構築することの容易さです。これは、今日私たちが重点を置いている場所であり、おそらく会話に入ると思います。

クリス：私は実際、開発者エクスペリエンスを改善すると私たちが考えるこれらの多くのことは、開発者のサブセットに対してそうすることに気づきましたが、必ずしもあなたが構築しているものに取り組んでいるすべての人がそうとは限りません。 ですから、それについてもたくさんの問題があり、掘り下げることができます。 しかし実際には、リーンWebは、ユーザーのシンプルさとパフォーマンスに焦点を当て、私たちではなく、私たちが作ったものを使用する人々、つまりそれを作っている人々に本当に優先順位を付けるか、焦点を当てることです。

Drew： Webが開発プラットフォームとして成熟するにつれ、専門化への動きがますます高まっているようです。

クリス：はい。

ドリュー：フルスタックをカバーしていた人たち。その後、フロントエンドとバックエンドに分かれました。 そして、そのフロントエンドは、CSSまたはJavaScript開発を行う人々に分割されました。 そして、JavaScript内でますます、それはより専門的になります。 誰かが自分自身をReact開発者またはAngular開発者と見なし、売り込む可能性があります。彼らのアイデンティティと展望は、高度なスキルを持つ特定のフレームワークに基づいています。これは、Webでの作業の中核であるフレームワークへの依存です。悪いこと？

クリス：微妙な違いがあります。 私はかつては非常に強く、常にキャンプにいました。 大まかに言って、私はまだそう感じていると思います。フレームワークとツール全般を備えた業界としての私たちの執着は、私たちの不利益になる可能性があります。 フレームワークは本質的に悪いとは思いません。 非常に狭い範囲のユースケースに役立つと思います。 そして、それらがあなたやプロジェクトにとって必ずしも最良の選択であるとは限らない多くの状況を含め、ほとんどすべてにそれらを使用することになります。

クリス：今日ウェブ上で抱えている多くの問題について考えるとき、それらの問題の核心は、フレームワークへの過度の依存から始まります。 その後に続く他のすべては多くの点であります。なぜなら、私たちは一般的にJavaScriptであるフレームワークだけでなく多くのことをWebに投げかけるからです。 私は、JavaScriptの書き方と使い方を専門的に教える人として言っています。 それが私のお金を稼ぐ方法です。 そして、私はここで、JavaScriptを使いすぎていると思いますが、これは少し奇妙なことです。

Drew：大きなフレームワークが生まれる前は、jQueryなどを使ってユーザーインターフェイスなどを構築していました。 そして、フレームワークが登場し、状態ベースのUIのこの概念をさらに提供してくれました。

クリス：はい。

Drew：さて、これはかなり複雑なエンジニアリングであり、適切な場所に配置する必要があります。 より少ないJavaScriptで作業することは、そのようなものを使用することを除外しますか、それとも自分でそれを再実装する必要がありますか？ ロードされたボイラープレートを作成しているだけですか？

クリス：それの多くはあなたがしていることに依存します。 インターフェースが変更されていない場合は、状態ベースのUIを次のように構築できます…わかりません。おそらく数十行のコードです。 インターフェースが変わらない場合は、正直言って状態ベースのUIと言えます。 それは必ずしも正しいアプローチではありません。 代わりにできることはおそらく他にもあります。 静的サイトジェネレーター、事前にレンダリングされたマークアップ、古い学校のWordPressやPHP駆動のサイトでさえ考えてみてください。

クリス：しかし、これが面白くなり始めるのは、より動的でインタラクティブなインターフェースに入るときです。 アプリだけではありません。 私は人々がウェブサイトとアプリの間にこの線を引くのが好きであることを知っています、そして私はそれらの2つの間にこの奇妙なブレンドがあると思います、そして線は必ずしも明確ではありません。 あなたがより多くのことを始めたとき、ユーザーは何かをします、何かが変わります。 状態ベースのUIはもう少し重要になります。 しかし、それを実現するために大量のコードは必要ありません。

クリス：私はReactやVueのようなものを見ています。これらは絶対に素晴らしいエンジニアリングです。 それらに取り組んでいる人々から離れたくありません。 私は最終的に学習演習として、これらが内部でどのように機能するかをよりよく理解するために、独自のミニフレームワークを作成しました。 さまざまな可動部品のすべてを説明するのは本当に難しいです。 ですから、私はこれらのツールを構築して作業する人々に多大な敬意を払っています。 しかし、ReactとVueは、縮小してgzipした後、どちらも約30キロバイトです。 したがって、開梱すると、それよりもかなり大きくなります。

クリス：すべてではありませんが、その重みのかなりの部分が仮想DOMと呼ばれるものに費やされています。 同様のAPIまたはアプローチを使用する代替手段があります。 Reactの場合、Preactがあります。これは30ではなく2.5キロバイトまたは約3キロバイトです。これはサイズの10分の1です。 Vueの場合、代わりにAlpineJSがあります。これは約7キロバイトです。 それでも、かなり小さい。 それらと彼らの兄貴の対応物との大きな違いは、彼らが仮想DOMを流したということです。 彼らは1つか2つの方法を落とすかもしれません。 しかし、一般的に、コードを操作する方法は同じアプローチで同じ種類のAPIであり、それらは大幅に小さくなっています。

クリス：私たちが使用しているツールの多くは、私たちがやろうとしていることに対して潜在的に圧倒されていると思います。 状態ベースのUIが必要で、リアクティブデータとこれらの動的インターフェイスが必要な場合、それは素晴らしいことです。 今日私が試みて話している大きなことの1つは、ツールを使用しないことではないと思います。 私にとって、Vanilla JSは、コードのすべての行と実行するすべてのプロジェクトを手書きしているわけではありません。 それは狂気です。 私はそれをすることができませんでした、私はそれをしません。 しかし、それは私たちが使用するツールについてより選択的です。 私たちは常にマルチツール、これらすべてのものが入っているスイスアーミーナイフを選びます。 そして時々、あなたが本当に必要とするのははさみのペアだけです。 他のすべてのものは必要ありませんが、とにかく持っています。

クリス：これは本当に長い道のりです…ごめんなさい、あなたの質問に答えてください。 これは、自分で作成したり、作成したりするよりも多くのコードである場合もありますが、必要と思われるほど多くのコードではありません。 フレームワークは必要ないと言うと、「フレームワークを使用しない場合は、基本的に独自のフレームワークを作成している」というこの考えに多くの反発があります。 それからそれはそれ自身の問題を伴います。 ReactまたはVueを使用してから独自のフレームワークを作成することの間には場所があると思います。それは、少し小さいものを選択している可能性があります。 何をしようとしているのかによっては、独自のフレームワークを作成することが実際に正しい呼び出しになる場合があります。 それはすべて非常に流動的で主観的です。

ドリュー：学習演習として、独自の状態ベースのフレームワークを実装したことは非常に興味深いことです。 昔は、図書館などに行くたびに、自分で実装できると思っていたのを覚えています。

クリス：もちろんです。

ドリュー：しかし、図書館に手を伸ばすと、それをする手間が省けました。 このコードを自分で作成する必要があるかどうかはわかっていました。それを行うためにどのようなアプローチを取るかを知っていました。 そして、それはjQueryやもののようなものを使用するまでずっと真実でした。 最近、自分のバージョンのVueまたはReactを作成する必要がある場合、そのライブラリで、そのすべてのコードで現在何が起こっているのかほとんどわかりません。

ドリュー：なじみのない私たちにとって、Preactのようなものが仮想DOMを削除し、すべてを非常に小さくすると言うとき、その仮想DOMは私たちに何を与えますか？

クリス：その質問に答えるために、私は少し後退したいと思います。 フレームワークやその他の状態ベースのライブラリが提供する最も優れた機能の1つは、DOMの差分です。 UIをそれほど更新していない場合は、次のように言うことができます。「マークアップがどのように表示されるかを示します。 HTMLでは、このすべてのマークアップをこの要素に配置します。」 何かを変更する必要があるときは、もう一度やり直します。 これは、再描画をトリガーするため、ブラウザにとっては少し高価です。

クリス：しかし、それよりも潜在的に重要だと思います。それを行う際の問題の1つは、そこに何らかのインタラクティブな要素、フォームフィールド、誰かが注目したリンクがあることです。 その要素が失われるため、その焦点は失われます…似たような新しいものがあったとしても、それは同じリテラル要素ではありません。 そのため、フォーカスが失われると、スクリーンリーダーを使用している人が混乱する可能性があります。 それにはたくさんの問題があります。

クリス：その重みに値する状態ベースのUIは、DOM差分の一部を実装する予定であり、次のように述べています。 DOMでの現在の外観は次のとおりです。 何が違うの？」 そして、それはそれらのことを変えていくでしょう。 UIを手動で更新するだけで実行できることを効果的に実行しますが、内部で実行します。 つまり、「これが私が望むものです」と言うことができます。 そして、ライブラリまたはフレームワークがそれを理解します。

クリス：プリアクトやアルパインのような小さなことは、実際にそれを直接行っています。 彼らはあなたが彼らに提供するUIがどのように見えるべきかという文字列をHTML要素に変換しています。 そして、各要素をリテラルDOMの対応する部分と比較しています。 UIがどんどん大きくなっていくと、DOMに何度もクエリを実行するとコストがかかるため、パフォーマンスに影響を与える可能性があります。 これが問題となるインターフェースのタイプを理解したい場合は、右クリックして、Twitterの「お気に入り」ボタンまたはFacebookの「いいね」ボタンの要素を調べてください。 そして、その要素に到達するdivのネストを見てください。 とても、とても深いです。 それは、1ダースほどのdivのようなもので、その1つのツイートのためだけに1つをもう1つの中にネストします。

クリス：それだけ多くのレイヤーを下に移動し始めると、パフォーマンスに大きな影響を与え始めます。 仮想DOMが行うことは、実際のDOMを毎回チェックする代わりに、JavaScriptでUIがどのように見えるかのオブジェクトベースのマップを作成することです。 次に、既存のUIを置き換えるUIに対して同じことを行い、それら2つを比較します。 これは、実際のDOMで行うよりも、理論的にははるかにパフォーマンスが高くなります。 変更が必要なもののリストを取得すると、実行されてそれらの変更が行われます。 ただし、DOMを攻撃する必要があるのは1回だけです。 すべての要素を毎回チェックしているわけではありません。 Twitter、Facebook、QuickBooksなどのインターフェースがある場合、仮想DOMはおそらく非常に理にかなっています。

クリス：それに関する課題は…PreactとReactの違いは、すべてを実際のコードウェーブに解凍する前に27キロバイトです。 それだけで生のダウンロードと解凍およびコンパイルの時間は、UIの初期ロードにかなりの待ち時間を追加する可能性があります。 ユーザーがAppleの最新のデバイスを使用していない場合、これはさらに顕著になります。 数年前のAndroidデバイスやフィーチャーフォン、あるいは発展途上国に人がいる場合でも、それは本当に…始めるのに時間がかかります。 それに加えて、余分な抽象化のために、実際のインタラクティブ時間は遅くなります。

クリス：つまり、ロードするだけでなく、速度も同等です。 誰かが行う各マイクロインタラクションと発生する必要のある変更も、そこに余分なコードがあるために、わずかに遅くなる可能性があります。 ネストされた要素とデータがたくさんある本当に本当に複雑なUIがある場合、仮想DOMのパフォーマンスの向上はその余分なコードの重みを上回ります。 しかし、開発者がReactまたはVueを使用していると私が見ている典型的なアプリの典型的なUIは、仮想DOMから得られるメリットがないため、より良い結果が得られます。 Reactと同じ利便性を維持したい場合でも、Preactを使用してください。 サイズのほんの一部であり、まったく同じように機能し、パフォーマンスが向上します。 これは私が主張しがちなことです。

クリス：私たちは仕事に適したツールを選ぶことについてより良くする必要があります。 そのようなアプローチを採用する場合、仮想DOMが実際に意味をなすようになれば、独自のDOMをロールするよりも、PreactをReactに移植する方がはるかに簡単です。 それが状況です。 それが本当に心配な場合は、将来を見据えた機能も組み込まれています。

Drew： Vue、Reactなどのこれらのフレームワークはパフォーマンスが非常に最適化されているため、バンダラーのパッケージマネージャーとペアリングするだけで確実に多くのメリットが得られると主張する人もいるかもしれません。必要なコードのみを送信してください。 確かに、あなたはそれをするだけですでにはるかに進んでいますか？

クリス：うん。 同意しません。 それ以外に詳しく説明することはあまりありません…多分、しかし実際にはそうではありません。 バンドラーを使用する場合でも、そのReactコアが必要です。 バンドルしても、Preactのようなものを使用するよりも大きくなります。

クリス：ドリュー、これについて質問をしてくれて本当にありがとう。 私が本で話している他のことの1つであるTheLean Webと同じ名前の私の話は、これらのツールがどのように機能するかということです…たとえば、バンドルについて言及しました。 このすべてのJavaScriptを使用することで得られるパフォーマンスの低下を回避するために行うことの1つは、それを説明するためにフロントエンドにさらに多くのJavaScriptをスローすることです。 その方法の1つは、パッケージマネージャーとモジュールバンドラーです。

クリス：あなたがほのめかしたように…知らない人のために、これらは…あなたの小さな個々のJavaScriptビットのすべてを1つの大きなファイルにコンパイルするツールです。 新しいものともっと…私はそれらを思慮深いとは言いたくありません。 しかし、新しいものはツリーシェイクと呼ばれる機能を使用します。この機能では、実際には必要のないコードをすべて削除します。 そのコードに、実際に行ったことに使用されていない依存関係がある場合は、それらの一部を削除して、パッケージを可能な限り小さくします。 これは実際にはひどい考えではありませんが、依存関係の上に依存関係の上に依存関係のカードのこの本当に繊細な家がある場合、私は通常、依存関係の健全性と呼んでいます。

クリス：プロセスの設定には時間がかかります。 そして、NPMインストールを実行したことがあり、依存関係の束が古くなっていることを発見し、修正が必要な依存関係を見つけるために1時間費やす必要があった人は誰でも、実際には依存関係の依存関係です。自分で修正することはできません。 それはすべてです。 たぶんそれはあなたのために働くかもしれません、しかし私はむしろ私の依存関係を一緒にしようとすることをいじり回さないように私の時間を費やしたいと思います。

クリス：ワークフローに時間を浪費していると不満を言う人からツイートを集め始めました。 私のお気に入りの1つであるBradFrostは、数年前に、現代のJSで怠けていたことが、jQueryで10分かかる可能性があるという気のめいるような認識について話していました。 私は実際にはjQueryのファンではありませんが、フレームワークの操作に関してはその苦痛を感じます。

クリス：これらのツールの多くに関するもう1つの問題は、それらがゲートキーパーになり始めることです。 あなたが本当にこれにどれだけ飛び込みたいのかわかりません、ドリュー。 しかし、JSに対する私の大きな反発の1つは、ワークフローのすべてです。 特に、「HTMLにJSをすでに使用している場合は、CSSにも使用してみませんか？」と言い始めると特にそうです。 あなたは本当に才能のある多くの人々を開発プロセスから除外し始めます。 コミュニティ全体にとって、プロジェクトにとっては本当に大きな損失です。

ドリュー：ええと、私は確かに…2020年の初めにReactを手に入れ始め、それをスキルセットに追加しました。 私は今それをほぼ7ヶ月間やっています。 私が最も自信がない部分の1つは、プロジェクトを開始するためのツールをセットアップすることです。

Drew： Hello Worldに何かを届けるには非常に多くの作業があるようですが、本番環境に対応させるために知っておくべきことはさらにたくさんあります。 これが、Web開発者になることを学ぶために、2020年にすべきこととして提案されている場合、開発を開始するのがより困難になる必要があります。 それに慣れていない誰かが本当の問題を抱えているでしょう。 それは参入障壁になるでしょうね。

クリス：もちろんです。 ここでのもう1つの点は、JavaScript開発者だけが、コードベースに取り組んだり、そのコードベースに有意義な方法で貢献したりする人だけではないということです。 JavaScriptをコードベースで操作するための要件にするほど、それらの人々が実際にプロジェクトに参加できる可能性は低くなります。

クリス：その一例として、私が話したいのは、最近出てきたWordPressです…現時点では最近言うべきではありません。 数年になります。 しかし、彼らはバックエンドスタックをPHPからJavaScriptにますますシフトしており、これは本質的に悪いことではありません。 彼らの新しいエディターであるGutenburgは、Reactに基づいて構築されています。

クリス： 2018年、WordPressの主任アクセシビリティコンサルタントであるRian Rietveldは、私がほぼ間違いなくその名前を殺しました…彼女は非常に公然と辞任し、その理由を非常に詳細な記事に記録しました。 問題の核心は、彼女と彼女のチームがこのエディターを監査して、アクセス可能になることを確認するという任務を負っていたことです。 WordPressは現在ウェブの30％を占めています。 彼らの目標は出版を民主化することであるため、アクセシビリティはその重要な部分です。 これは、Webプロジェクトの重要な部分である必要があります。 しかし、特に彼らにとって、それは非常に重要です。 彼女のチームの全体の仕事は、確認することです…彼女のチームの全体の仕事は、このエディターにアクセスできることを確認することでした。 しかし、彼女もチームの誰もReactの経験がなく、その経験を持つアクセシビリティコミュニティでボランティアを見つけることができなかったため、彼女と彼女のチームが仕事をするのは非常に困難でした。

クリス：歴史的に、彼らはエラーを特定し、それから入ってそれらを修正することができました。 しかし、新しいReactベースのワークフローでは、バグを特定してからチケットを提出することになりました。 それらは、JavaScript開発者が取り組んでいた他のすべての機能開発要求とともにバックログに追加されました。 簡単に修正できたはずの多くのものが、最初のリリースにはなりませんでした。

クリス： 2019年5月、リアンが辞任してから約1年後、グーテンブルクで詳細なアクセシビリティ監査が行われました。 完全なレポートは329ページでした。 エグゼクティブサマリーだけでも34ページでした。 91のアクセシビリティ関連のバグをかなり詳細に文書化しました。 これらの多くは本当に…単純な簡単な果物とは言いたくないのですが、それらの多くはRianのチームが修正できた基本的なものであり、開発者は機能開発に集中できるようになりました。 それが最終的に彼らがやったように見えることであり、機能開発に多くの時間を費やし、後でまでこのようなものを押しのけていました。 しかし、そのチームはプロジェクトにとって非常に重要であり、技術的な選択のために突然プロセスから締め出されました。

クリス：アレックスラッセルはChromeチームの開発者です。 彼は数年前にTheDeveloper Bait and Switchと呼ばれるこの記事を書き、フレームワークのストローマンの議論について話しました。 これらのツールを使用すると、より速く移動できるというこのアイデアにより、より速く反復し、より良いエクスペリエンスを提供できます。 より良い開発者体験はより良いユーザー体験を意味するというのはこの考えです。 これは、その議論が人々が信じているように常にうまくいくとは限らないことの非常に明確な例だと思います。 すべての人にとってではなく、一部の人にとってはより良い体験です。

クリス： CSS開発者、設計システムに取り組んでいる人々、他の人が使用できるツールを作成する能力は、これらのツールの選択によっても制限されることがあります。 私の経験では、CSSが得意でした。 ここ数年で大きく変化し、以前ほど良くはありません。 私の経験では、本当に高度なCSS開発者である人々…そして私は本当の意味でそれを意味します。 CSSに取り組む人々は、プログラミング言語に取り組む適切なWeb開発者です。 それは非常に特別なことでも、非常に特殊なことでもあります。 私の経験では、JavaScriptが非常に得意な人は、JavaScriptが得意であるとは限りません。これは、1つのことを深く掘り下げて、他のことを少しスライドさせるためです。 これらのテクノロジーを使用する彼らの能力も妨げられますが、以前はそうではなかったので、それは残念です。

クリス：スタックが単純になると、複数の分野の人々が開発プロセスに参加しやすくなりました。 それは、私たちが構築するものとコミュニティ全体の両方に悪影響を与えると思いますが、それはもはや事実ではありません。

Drew：最近、CSSの問題、ワークフローの問題のいくつかに対処する方法を研究しているプロジェクトで、プロジェクトに複数の作業があり、バンドルサイズが大きくなり、古いCSSが削除されないことがわかりました。 これはReactプロジェクトだったので、JavaScriptアプローチでこれらのCSSのいくつかを調べて、私たちが抱えていた問題を解決するために何を使用するのが最適かを調べました。 すぐに明らかになったのは、これを行うための解決策は1つだけではないということです。 これを行うには、さまざまな方法があります。

Drew： JSのCSSは一般的なアプローチですが、あるプロジェクトから次のプロジェクトに移動する可能性があり、まったく異なる方法で完全に影響を受けます。 あなたがCSSの人であり、プロジェクトで特定のアプローチを学んだとしても、それらのスキルはとにかく移転できないかもしれません。 JavaScriptに特に慣れていない場合、誰かが学習に多くの時間を費やす方法を理解するのは非常に困難です。

クリス：うん。 もう少しおもしろいと思うのは、これについて話すときです。私が得る最大の反発の1つは、フレームワークが規則を適用することです。 あなたはVanillaJavaScriptを使用します、あなたはこの緑の野原を持っています-青い空、あなたはあなたが望む種類のプロジェクトを何でもすることができます。 Reactには、物事を行うためのReactの方法があります。

クリス：しかし、私が見つけたものの1つは、Reactyのアプローチがあるということですが、Reactで物事を行うための厳密な1つの正しい方法はありません。 それは人々がそれについて好きなことの1つです。 それはもう少し柔軟性があり、必要に応じていくつかの異なる方法で物事を行うことができます。 Vueと同じです。 HTMLベースのプロパティをHTMLで正しく取得し、Vueがそれらを置き換える場合に使用できますが、必要に応じて、よりJSXのようなテンプレート形式の構文を使用することもできます。

クリス： Reactを学んでいるときに複数の人が不満を言うのを聞いたことがありますが、大きな問題の1つは、GoogleがReactでXを実行する方法です。 それは彼らがプロジェクトにいくつかのガードレールを置かないということではありません。 「私はフレームワークを選択しました。 これが私がそれを使って構築する方法です。」 正直なところ、それが必ずしも私が望んでいることだとは思いません。 私はあなたがそれらを厳しく閉じ込めることを望まないと思います…多分、何人かの人々はそうします。 しかし、あなたがそれを利益として宣伝しているのなら、それは人々が時々そうするように思われるほどはっきりしているとは思いません。

クリス：あなたは、もう必要のないCSSについて言及していたところですが、興味深いことに気づきました。 これは、CSSやJSなどの合法的に興味深いものの1つだと思います。または、CSSをJavaScriptコンポーネントに何らかの方法で結び付けると、そのコンポーネントが脱落した場合、理論的にはCSSがなくなります。 私にとってこれの多くは、人々の問題にエンジニアリングを投げかけるような気がします。 常に、あなたはまだどこかで人々に依存しています。 それは決してそれらのアプローチを使用しないということではありませんが、確かにそれらはこの問題に取り組む唯一の方法ではありません。

クリス： HTMLを監査し、CSSやJavaScriptを使用しなくても使用されていないスタイルを引き出すために使用できるツールがあります。 CSSを「昔ながらの方法」で記述しても、未使用のスタイルのリンティングを行うことができます。 CSSには、JSのような出力でCSSを提供し、CSSやJSで時々発生するこれらのぎこちない人間が読めないクラス名を吐き出さずにスタイルシートを小さく保つオーサリングアプローチがあります。 X2354ABCのように、または吐き出されるこれらのナンセンスな言葉。

クリス：ここから、おじいさんがクラウドのようなものに怒鳴り始めます。 ここでは、開発者の年齢を実際に示しています。 しかし、ええ、必ずしもこれらが悪いというわけではなく、正当な問題を解決するために構築されています。 私は時々少しあるように感じます…それがFacebookにとって十分であるならば、それは私たちにとってこれらで起こるようなことで十分です。 そうですね、Facebookはこのツールを使用しています。 私たちが本当のエンジニアリングプログラムであるなら…チーム、部門、組織、私たちもそうすべきです。 私は必ずしもそれがそれについて考える正しい方法だとは思いません。 Facebookはあなたがしていない問題を扱っているからです。逆もまた同様です。 彼らが取り組んでいるもののサイズと規模はちょうど異なります、そしてそれは大丈夫です。

ドリュー：その通り。 CSSやJavaScriptのようなこれらのもののいくつかは、ほとんどポリフィルのように見えます。 正当な問題があります。それを解決する方法が必要です。 この技術はまだそれを解決する方法を私たちに提供していません。 たぶん、Webプラットフォームが進化し、その問題に対処するのを待つ間、JavaScriptのようなもので今行っていることは、私たちを通り抜けて大丈夫です。 私たちはそれが悪いことを知っています。 私たちはそれが素晴らしい解決策ではないことを知っていますが、それは今私たちを助けます。 そしてうまくいけば、しばらくの間、それを引き出してネイティブソリューションを使用することができます。

クリス：これを持ってくるのは本当に面白い。 文字通り昨夜だったので、昨年のジェレミー・キースからプログレッシブウェブアプリについての話を見ていました。 しかし、彼は数十年前、JavaScriptを使用するように人々を説得しようとしていたことについて話していました。 当時はばかげているように見えますが、JavaScriptはこの新しいものでした。 彼は、この新しい機能を使用して、ホバー時にリンクの色を変更するなどのクールな方法を人々に示しました。CSSが行うので、今すぐJavaScriptが必要になるのはばかげているようです。 しかし、focus属性やプロパティなどは、当時は存在していませんでした。

クリス：彼が話の中で私に本当に共感したと思うことの1つは、JavaScriptが多くの点でそれらの牛の道を開くということです。 まだ存在していない機能を作成または追加するために使用できるのは、この非常に柔軟でオープンな言語です。 そして最終的に、ブラウザはこれらの機能に追いつき、よりネイティブな方法で実装します。 しかし、それは時間がかかります。 私はあなたがこれについて言っていることを完全に理解しています。 それは完璧な解決策ではありませんが、私たちが今持っているものです。

クリス：私にとって、ポリフィルとこれらのソリューションのいくつかの最大の違いは、ポリフィルが引き裂かれるように設計されていることだと思います。 ブラウザがまだサポートしていない機能を実装したいのですが、ある種の仕様があり、ポリフィルを作成します…ブラウザが追いついたら、そのポリフィルをリッピングできます。何でも変更します。 しかし、これらのツールのいくつかを使用する道を進むとき、それらをリッピングすることは、コードベース全体を書き直すことを意味します。 それは本当に高価で問題があります。 絶対に使わないというわけではありませんが、後で簡単に引き出せる道具を選ぶことを考えるべきだと強く感じています。 それらが不要になった場合、またはプラットフォームが追いついた場合、それらを引き出すために大規模な書き直しは必要ありません。

クリス：それで、私たちはもう使用しないスタイルがたくさんあるので、レンダリングされたマークアップに対してCSSを監査し、不要なものを引き出すビルドツールテクノロジーを個人的に支持するのはそのためです。 プラットフォームが追いついた場合は、すべてを変更することなく、ビルドツールのその部分を引き出すことができます。 それはあなたがすでに持っているものを増強するだけですが、CSSとJSはあなたに同じ種類の利益を与えません。 私はそれを選んでいますが、これらのテクノロジーの多くについてもっと広く考えています。

クリス： ReactやVueのようなものは、おそらくブラウザーが追いつくであろういくつかの牛の道を開いていると思います。同じではないにしても、おそらく同様のアプローチを使用するので、そこに含まれる書き換えは少なくなる可能性があります。 周りに接続されているエコシステムのものの多くは、それほどではないかもしれません。

ドリュー：ウェブプラットフォームがゆっくりと慎重に動くのは正しいと思いますね。 5年前なら、私たち全員がJavaScriptカルーセルをページに配置していたと思います。 彼らはいたるところにいました。 誰もがJavaScriptカルーセルを実装していました。 Webプラットフォームがジャンプして、そのニーズを満たすためにカルーセルソリューションを実装した場合、人々はもはやカルーセルでそれを行っていないため、誰もそれを使用していない状態でそこに座っていることはありません。 ただの流行だったので、デザイントレンド。 これに対抗し、プラットフォーム自体が肥大化し、解決が必要な問題になるのを防ぐには、プラットフォーム自体をより安定したペースで動かす必要があります。 その結果、1999年に書いたHTMLは、プロセスが遅いため、今日でも機能します。

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it's related to the framework conversation. But it's the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you're getting all this benefit because you're not reloading the entire page framework. I feel like they don't always make good on those performance promises. 同意しますか？

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don't think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who's unfamiliar with those. When a single-page app, instead of having separate HTML files or if you're using something like a database driven site like WordPress, even though you don't have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That's what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don't have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that's slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they're not confused about where they are or what's going on. Because they can't see the change that's happening, they're hearing it announced. If you don't actually shift focus anywhere, that announcement doesn't happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don't necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website's being built, it doesn't always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you're going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it's not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it's being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. 絶対。 絶対。 One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that's already there. So there's no reloading, they don't lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It's again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you'd have just a rectangle embedded in an HTML page which is your Flash Player, and you'd build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we're putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn't exist, I spell article like arcitle instead of article and the browser runs across that, it's going to be like, “Oh, I don't know what this is. Whatever, I'll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let's say I forget the B in bold, so I write old instead, font way old. The browser's going to be, “I don't know what this is. Whatever, we'll just keep going.” Your thing won't be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn't exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn't complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn't work at all.

Chris: There's an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don't disable it and most people are using devices that can actually handle modern JavaScript. That's true, but that's not the only reason why JavaScript doesn't work right, even if you have a linter there for example and you catch bugs ahead of time and things. There's plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we're recording this… a bad deploy took down Cloudflare. Interestingly as we're recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They're an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you'd like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn't part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone's in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it's probably even more now. That's a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There's just all sorts of reasons why JavaScript can fail and when it does, it's so catastrophic.

Chris: And so we built this web that should be faster than ever. It's 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn't have to be that way.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I've hammered on this a couple times. I'm not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn't mean obsolete. It doesn't mean never embrace new stuff, but don't be so quick to just jump on all the shiny new stuff just because it's there. I know it's one of the things that keeps this industry really exciting and makes it fun to work in, there's always something new to learn. But when you pick these new things, do it because it's the right tool for the job and not just because it's the shiny new thing.

クリス：私たちが望んでいたほど多くは入りませんでしたが、本当に重要だと思う他のことの1つは、プラットフォームがここ数年で非常に大きな方法で追いついたことです。 可能な限りそれを採用することで、より高速で脆弱性が低く、ブラウザが提供するものを使用するなどの依存関係が少なくて済むため、構築と保守が容易なWebエクスペリエンスが人々にもたらされます。 -ボックス。 以前は、クラスなどを選択するためにjQueryが必要でした。 現在、ブラウザにはそれを行うためのネイティブな方法があります。 JSXは、JavaScriptでよりシームレスな方法でHTMLを記述できるため、人々はJSXを好みます。 ただし、Vanilla JavaScriptには、追加の依存関係なしで同じレベルの使いやすさを提供するテンプレートリテラルもあります。 HTML自体が、JavaScriptを必要としていた多くのものを置き換えることができるようになりました。これは絶対に驚くべきことです。

クリス：私たちは少し話しました…これはCSSのことですが、リンクとそれがJavaScriptを必要としていた方法にカーソルを合わせます。 ただし、詳細要素や要約要素などを使用すると、スクリプトを必要とせずに、展開や折りたたみ、アコーディオン要素などの開示をネイティブに作成できます。 オートコンプリート入力は、…だけで実行できます。言うべきではありません。その言葉は嫌いです。 ただし、控えめな入力要素を使用してから、それに関連付けられるデータリスト要素をいくつかのオプションとともに使用します。 このようなものがvanillajstoolkit.comでどのように機能するかについて知りたい場合は、プラットフォームが提供するJavaScript関連のものをたくさん用意しています。 しかし、以前はJavaScriptが必要だったものもありますが、コードサンプルをこれに合わせて使用​​したい場合は、興味深いことはありません。

クリス： CSSの面では、これまでで最も人気のあるVanilla JSプラグインは、アンカーリンクまで下にスクロールするアニメーションを作成できるこのライブラリです。 それは非常に大きいです。 これは私が今までに書かなければならなかった最も難しいコードです。 そして、CSSの1行に完全に置き換えられ、スクロール動作がスムーズになりました。 それはよりパフォーマンスが良いです。 書くのは簡単です。 その動作を変更する方が簡単です。 これは、より優れた全体的なソリューションです。

クリス：私たちがもっとやりたいと思っている他のことの1つは、複数ページのアプリに頼ることです。 私は最近、Googleの誰かからの記事を見て、実際にこのアプローチを推進しているので、ここで少し立証されていると感じています。 この巨大な角度とフレームワークを考えると、それはかなり興味深いと思いました…グーグルが数年前に始めたすべてのもの、ブーム。 彼らがこれに戻ってくるのを見るのはちょっとクールです。 静的サイトジェネレーターやNetlifyやCDNキャッシングなどのすばらしいサービスを使用すると、さまざまなビューすべてに個別のHTMLファイルを使用する人々に信じられないほど高速なWebエクスペリエンスを作成できます。 だから、このすぐに使えるもののいくつかに頼っているようなものです。

クリス：それが現実的ではない状況で、より多くのJavaScriptが必要な場合は、ある種のライブラリが必要です。おそらく、業界の巨人に行くのではなく、より小さく、よりモジュール化されたアプローチを最初に見てください。 Reactの代わりに、Preactは機能しますか？ 角度の代わりに…つまり、Vueの代わりに、Alpine JSは機能しますか？ 現在Sveltと呼ばれているこの非常に興味深いプリコンパイラもあります。これはフレームワークのようなエクスペリエンスを提供し、すべてのコードをVanillaJavaScriptにコンパイルします。 だから、あなたはあなたが必要なものだけを持っているこれらの本当に小さなバンドルを手に入れます。 CSSとJavaScriptの代わりに、HTMLをCSSと比較して、誤ってそこに残っているものを引き出すサードパーティのCSSリンターを追加できますか？ 代わりに、Nicole Sullivanによるオブジェクト指向CSSのように、CSSを作成する別の方法が機能しますか？ それについてはあまり話せませんでしたが、人々がチェックすべき本当にクールなことです。

クリス：それから、ここで3番目に重要な部分は、特定のアプローチではなく、もっと多くの人に覚えてもらいたいことですが、Webはすべての人のためのものだと思います。 私たちが今日使用しているツールの多くは、良好なインターネット接続と強力なデバイスを持っている人々のために機能します。 ただし、古いデバイスを使用していて、インターネット接続が不安定な人には機能しません。 これは開発途上地域の人々だけではありません。 これは、私たちが絶対にひどいインターネット接続を持っている米国の特定の地域の英国の人々でもあります。 私たちの国の真ん中は非常に遅いインターネットを持っています。 ロンドンの一部には、歴史的な理由で新しいブロードバンドを接続できない場所があることを知っています。そのため、これらの古いインターネット接続は非常に悪い状態になっています。 そのような場所は世界中にあります。 前回イタリアにいた時も同じです。 そこのインターネットはひどいものでした。 それ以来変わっているかどうかはわかりません。

クリス：今日私たちが作ったものは、必ずしもすべての人に役立つとは限りません。それは残念です。 ウェブのビジョン、私がそれについて気に入っているのは、それが絶対にすべての人のためのプラットフォームであるということです。

Drew：リスナーがこのアプローチについてもっと知りたいのなら、あなたはあなたの本、The LeanWebでそれについて多くの詳細を調べました。 そして、それはオンラインで利用できます。 それは物理的な本ですか、それともデジタル本ですか？

クリス：それは両方の少しです。 うーん、ダメ。 それは確かに物理的な本ではありません。 あなたはleanweb.devに行きます。 あなたは無料ですべてをオンラインで読むことができます。 また、必要に応じて、EPUBバージョンとPDFバージョンを非常に少ない金額で利用できるようにすることもできますが、今はどれだけ忘れていますか。 しばらく見ていません。 あなたがそれを望むならば、すべてはオンラインで無料です。 必要に応じて、このトピックに関する講演をご覧になることもできます。

クリス：でも、名前を付けるのはとてもクリエイティブなので、gomakethings.com / smashingpodcastにSmashingPodcastのリスナー専用の特別なページも用意しました。 これには、本に加えて、今日お話ししたことに関する多くのリソースが含まれています。 それは、私たちがカバーした多くの異なるテクニック、これらのトピックのいくつかをより深く掘り下げ、私の考えを少し拡張する私が書いた他の記事にリンクしています。 人々がもっと学びたいのなら、それはおそらく始めるのに最適な場所でしょう。

ドリュー：それはすごい。 ありがとう。 私はリーンウェブについてすべてを学んでいます。 クリス、最近何を学んでいますか？

クリス：ええ、いくつかあります。 プログレッシブウェブアプリでジェレミーのビデオを見て、少し前にこれをほのめかしました。 自分が取り組んでいるものに特別なニーズがなかったため、私は数年間、実際に自分のプログレッシブWebアプリを作成する方法の学習を延期してきました。 私は最近、南アフリカにいる私の学生の1人から、彼らがそこで起こっているいくつかの事柄のために計画停電に取り組んでいることを知りました。 その結果、彼女は私たちが定期的に行っているプロジェクトのいくつかに取り組むことができません。これは、電源が切れて、学習ポータルにアクセスしてフォローすることができないためです。

クリス：私にとって、インターネットを持っていなくても機能するエクスペリエンスを構築することが、より優先度が高くなっています…以前だったのかもしれないと気付いたので、それを掘り下げて、それをまとめたいと思っています。次の数週間。 わかります。 しかし、これに関するJeremy Keithのリソースは、絶対的な命の恩人でした。 それらが存在してよかったです。

クリス：ドリュー、あなたがこの質問をしたい理由の1つは、どんなに熟練していても、人々が常に学んでいることを示すためだとおっしゃいました。 ほんの少し関連した逸話。 私は約8年前からWeb開発者だと思います。 文字通り使用するたびに、CSSプロパティをイタリックにするために使用する必要があります。 どういうわけか、私の脳は、それが正しいものではないのに、デフォルトでテキスト装飾になっています。 いろいろな組み合わせをいくつか試してみますが、毎回一言間違っています。 また、イタリックの代わりにイタリックを書くこともあります。 うん。 誰かがこれまでにそう感じたことがあれば、ああ、私はこのことを学ぶつもりはありません…あなたがどんなに熟練していても、あなたが何度も何度もグーグルする本当に基本的なことが常にあることを知ってください。

Drew：私は22、23年間Web開発者であり、Flexboxのさまざまなプロパティを毎回Googleで検索する必要があります。 私はそれを23年間使用していますが。 しかし、ええ、いくつかのことは…私が年をとるにつれて、おそらくそれらの多くに行くでしょう。

クリス：うん。 正直なところ、グーグルよりも簡単だったので、コピー＆ペーストの参照を簡単にするために、私は何度も何度もグーグルのもののウェブサイト全体を構築することになりました。

ドリュー：それは悪い考えではありません。

クリス：それは私が怠け者のようなものです。 3秒のグーグルのように自分自身を救うためにウェブサイト全体を構築します。

ドリュー：リスナーがクリスからもっと聞きたい場合は、彼の本をウェブ上のleanweb.devで見つけることができ、彼の開発者向けのヒントニュースレターなどをgomakethings.comで見つけることができます。 クリスはツイッターのクリスフェルディナンディにいます。 そして、vanillajspodcast.comや、通常ポッドキャストを入手できる場所ならどこでも、彼のポッドキャストをチェックできます。 本日はご参加いただきありがとうございます、クリス。 別れの言葉はありますか？

クリス：いいえ。ドリュー、私を迎えてくれてありがとう。 私は絶対に壊滅的な時間を過ごしました。 これはたくさんの楽しみでした。 チャットに来る機会に本当に感謝しています。