この動画は、「JavaScriptがウェブを台無しにした」という記事に対するウェブ開発者の詳細な反論である。記事の著者がSEOコンサルタントという背景から、JavaScript フレームワークやモダンなウェブ開発手法への批判を展開する一方、動画作成者は実際のアプリケーション開発経験に基づいて、なぜJavaScriptやReactが現代のウェブに必要不可欠なのかを説明している。特にユーザーエクスペリエンス、インタラクティブ性、そして複雑なアプリケーション構築の観点から、記事の主張に対して技術的かつ実践的な反証を提示している。
動画の開始とスポンサー紹介
JavaScriptは最悪です。ウェブを完全に台無しにしました。ただウェブサイトに行ってテキストを読めた時代が懐かしいです。インタラクティブなページや実際に役立つアプリケーションや機能、そして時折現れるポップアップや広告に対処する必要がありませんでした。
ちょっと皮肉を込めて言っていますが、この記事は違います。Jonnoによると、JavaScriptはウェブを壊し、それを進歩と呼んだということです。この記事がどこに向かうのか何となく分かりますし、この記事のトーンや方向性について私はあまり興奮しないだろうという感じがします。ほとんどのウェブサイトがひどいということには同意しますが、そこに至る道筋は私たちのものとはかなり異なるだろうという感じがします。
これを私に送ってくれた人たちは皆、私がどれだけこれを嫌うかを興奮して話してくれました。つまり、これは事実上自傷行為みたいなものです。YouTubeの検閲があるので自傷行為という言葉を使うのは慎重になりますが、まあそういう感じです。これは私にとってかなり辛いものになるでしょう。私の苦痛に対して補償してもらう必要があります。
それでは今日のスポンサーから簡単に一言いただいて、すぐに本題に入りましょう。あなたはNext.jsを使っています。おそらくVercelも使っているでしょう。これはNext.jsに最適なクラウドです。では、文字通り他の何かを使っている場合はどうでしょうか？そのレベルの品質体験と、ユーザーのために良いアプリを構築するのに必要なすべてのピースを提供してくれるクラウドはどこでしょうか？
AWSで自分で設定することもできます。他のすべてを自分で理解することもできます。または今日のスポンサーであるSavalaを使うこともできます。彼らはあなたのためにこれらすべてを理解してくれています。
どのようなスタックで出荷したいかに関係なく、RailsやPHP、Python、WordPressなど、何を使っていても、Savalaでうまく動作するだけでなく、実際に設定方法の例も提供している可能性が非常に高いです。これらの人たちは、私のような愚か者でも大量のランダムなサービスをデプロイできるようにしてくれます。
今では、デプロイしたいかもしれないさまざまなもののテンプレートも用意されています。明らかにDjangoやLaravelのようなフレームワークもありますが、GhostのようなCMSもあります。Moodleは私にトラウマを与えるでしょう。高校時代にMoodleを経験したことがあります。これは学習管理システムです。でも、Nextさえもあります。つまり、従来のサーバーでNextを使いたい場合も問題ありません。
そして、私が一緒に働いたことのある他の会社、例えばFirecrawl（ウェブサイト用のオープンソーススクレイパー）なども、すべてワンクリックでデプロイできます。本当にそのとおりです。私はクリックしてデプロイしました。そして中に入ると、サービスに関するすべてを見ることができます。DDoS保護付きでCloudflareを前に自動的に設定してくれます。つまり、これらの他のピースを自分で設定する必要がありません。
CDNの一部をキャッシュしたい場合は、設定をクリックしてCDNをオンにします。他の複数の場所で大量の設定をする必要はありません。複数の異なるクラウドプラットフォームや異なるインフラストラクチャの専門家になる代わりに、2回のクリックでこのようなことができるのは本当に素晴らしいです。
一方で、Savalaはクラウドですが、より重要なことは、クラウドを構築するためのチームを雇う代替手段だということです。現実の世界はマルチクラウドです。サーバーが必要で、CDNが必要で、ファイアウォールが必要で、他にも多くのピースが必要です。Savalaでは、オールインワンのふりをする代わりに、すべての異なるクラウドとその最良の部分を提供することで、オールインワンになっています。
今すぐ始めれば50ドルの無料クレジットがもらえます。soy.link/savalaで今すぐチェックしてください。
記事の内容への反論開始
ほとんどのウェブサイトはひどいです。
これが、JavaScript以前に実際に真実だったことではなく、実際には広告、アナリティクス、トラッキング、その他すべてのものが原因で、JavaScript自体とは何の関係もないということを非常によく正当化された声明になることは確信しています。きっとそうでしょう。そして、FlashやJavaエラーがあった時代のJavaScript以前のものも、明らかにはるかに良かったということも確信しています。
ほとんどのウェブサイトはひどいです。ただ遅いだけでなく、ひどいのです。膨張していて、脆弱で、過度に設計された災害です。読み込みが遅く、不安定にレンダリングされ、メガバイトのJavaScriptの後ろにコンテンツを隠しています。モバイルでグリッチが発生します。ユーザーをイライラさせ、検索エンジンを混乱させます。メンテナンスが不可能です。そして、どういうわけか、これを進歩と呼んでいます。
ウェブで経験するこのような事象の数にますますイライラしていることは認めます。速いはずなのに遅い読み込み、遭遇する不安定なレンダリング条件。さっきTwitterでバグがありました。友人のプロフィールの一つに行くと、フォローしていると表示され、その後フォローボタンに戻って何度も点滅するのです。このようなことがよく起こります。
チャットからの面白い引用です。著者はSEOコンサルタントです。SEOコンサルタントはウェブを悪化させています。これは客観的事実です。SEOコンサルタントがウェブにとって純粋にプラスだったと言う人は想像できません。いえ、明らかにそうです。
これ全体が、彼がSEOコンサルタントになりたくて、JavaScriptがそれを少し難しくしたからといって迎合しているだけなのでしょうか？でも実際には、インターネット中にキーワードやバックリンクを詰め込むことと違って、ウェブにとって有益なことなのです。事実上、サービスとしてのスパムボットになっているのです。きっとこれは良いものになるでしょう。
ああ、もっと良いですね。おそらく著者は、AIが自分の仕事を無関係にしていることに動揺していて、代わりにJavaScriptに八つ当たりしているのでしょう。それは理にかなっています。
分かりました、後退しましょう。そんなに敵対的に入っていかないでください。多くのウェブサイトが膨張していて遅くて使うのが悲惨だという事実は本当の問題です。モバイルウェブがひどいという事実も本当の問題です。その事実について、私は多くの異なる当事者を責めるでしょう。
うまくいけば、私が確実に大いに愛するであろうこの記事で同意できることを見つけることができるでしょう。
JavaScriptの複雑性への批判と反論
悲劇は、これらのどれも必要ではないということです。昔、私たちには速く、安定していて、回復力のあるウェブがありましたが、それをJavaScriptのカーゴカルトに置き換えました。今では、見出しを変更するだけで4人のエンジニア、3つのフレームワーク、CI/CDパイプラインが必要です。
ウェブページをプッシュするのが異常に複雑です。ああ、すでに意見があります。別の挑戦を提案しましょう。見出しの代わりに（この場合、ページのタイトルを変更することを意味していると確信していますが）、トップナビを変更したいとしたらどうでしょうか？サイトの上部にあるこの部分を変更したいとしたらどうでしょうか？
これがフレームワークやJavaScriptのようなものを使用していない場合、おそらく多くの異なるファイルでそれを変更する必要があるか、コンポーネントと呼ばれる再利用可能なピースを持つツールを使用して、一箇所で変更してから先に進むことができます。狂ったことですが、見出しを変更するのに4人のエンジニアが必要だと考えることです。
いえ、あなたは悪いエンジニアを雇っているか、悪いチームに対処するのに困っているかです。GitHubに直接プッシュして即座にビルドしてデプロイする私のワンオフコミットが、あなたが何について話していると思っているものよりもはるかに悪いという世界はありません。
その上、2人で狂ったものを作ることができます。私とMarkだけで、T3 chatでchat GPTやClaudeの本当の競合相手を作ることができました。私たちが神だからそれをしたわけではありません。確実に、HTMLのような古い信頼できる標準に依存したからでもありません。実際、私たちは長い間やってきた以上にクライアントサイドにハードに行きました。
T3 chatのコードの99％は、そのような良いインタラクティブエクスペリエンスを作るためには必要だからクライアントサイドJavaScriptです。あなたのウェブの見方がブログ投稿とマーケティングで、それをSEOコンサルタントとしてサービスとして売っているなら、JavaScriptに動揺する理由が分かります。なぜなら、JavaScriptは、あなたのサービスを買わせるためにひどいマーケティングブログを書くためではなく、実際のアプリケーションやソフトウェアのプラットフォームとしてウェブを使用しているからです。
これは進化ではありません。自分で課した複雑性です。そして、どこかの時点で、ユーザーのためではなく開発者のためにウェブサイトを構築し始めたので、これを正常化しました。
いえ、これについては、本当に誇りに思っているHTMLを異なる方法でレンダリングする動画を含む他の動画で話しました。私たちがここに至ったのは、より多くのことをするより複雑なウェブサイトを構築し始めたからです。
ウェブサイトがテキストコンテンツだけを持つか、送信時にフォーラムに投稿するためにページ全体をリロードしなければならないフォームを持つ代わりに、私たちは動的なウェブ、インタラクティブなウェブ、フォームに書いて送信を押すだけではない実際にできることがあるウェブに向かって移動しました。
Gmailのようなものは、ウェブがHTMLファイルだけであるという考えを超えて移動したからこそ可能でした。
これは著者からのものです。あなたのウェブサイトにローディングバー、スケルトンレイアウト、またはプログレスインジケーターがあるとき以上に、開発者が何をしているか分からないということを示すものはありません。皮肉なことに、これらのものはほとんど常にローディングプロセスを遅くします。ただ、本質的に速いものを作ってください。今までになく簡単です。
いえ、そうではありません。私が何度も確立し、例を通して実証し続けるように、私は多くの異なる戦略を使って多くの異なるサービスを構築しました。これはその一つです。これはping.ggです。ストリーマー向けのZoomのようなものです。
このアプリは事実上サーバーサイドレンダリングを全く使用していません。クライアントサイドアプリです。また、良いWebRTC体験に完全に焦点を当てているため、Firefoxでは動作しないクライアントサイドアプリでもあります。これらはすべてFirefoxが言い方を知らない言葉です。
これがpingの私のダッシュボードです。「ルームに参加」をクリックすると、クリックするとすぐに移動します。「ホーム」をクリックして戻ると、クリックするとすぐに戻ります。「参加」をクリックすると、今クリックしています。即座に何かが起こります。それがクライアントサイドレンダリングをするときの違いです。
参加ボタンをクリックしたときにローディングスピナーがありましたか？はい、非常に短時間でした。適切な権限を取得して他の複雑なことをしているときです。ローディングスピナーの一部は、より多くのデータが読み込まれることでした。はい。ローディングスピナーの一部は、クライアントサイドで時間を費やす必要があることをすることでした。それがインタラクションがどのように機能するかの性質です。
あなたの仕事がランダムな会社にマーケティングの粗雑品を売ることでない限り、ローディングは常にサーバーからのローディングを意味するわけではありません。実際のアプリケーションは物事をします。時々、データを取得する必要があります。時々、デバイスとやり取りする必要があるだけです。クリックしてすぐに起こるすべてのことは、はるかに良く感じられます。pingが客観的に少し遅いことを事実として知っているからです。
私たちは、よく確立される前と良い回避策がある前に、古いツールと技術を使用しました。そして、ping周りをナビゲートするためのラムダのコールドスタートが1〜2秒かかることがあります。それはちょっとクレイジーです。
問題は、ボタンをクリックしてローディングスピナーを避けるためにサーバーがページを生成するのを待つと、異なるものを得ることです。代わりにページの上部にローディングバーを取得します。そして、そのローディングバーはひどく感じられます。クリックした場所では起こりません。
つまり、ここをクリックしてローディングバーがページの上部に表示されるとき、私はまだ同じページにいます。クリックが通ったかどうかは不明です。そこで、数回クリックして、時には更多のリクエストを送信して、より多くのものを生成します。
サーバーでレンダリングすることがより速くても、それはしばしばより遅く感じられることになります。pingが私が構築したほとんど他のすべてのものよりも客観的に数字的に遅いにもかかわらず、今日でも定期的に「うわー、pingはとても速い。どうやってそんなに速くしたの？」という賛辞と質問を受けることを事実として知っています。速くありません。
遅いですが、何かをクリックするたびに何かがすぐに変わるので速く感じられます。何かをクリックしたりやり取りしたりするときに、UIの更新を遅らせません。ローディングスピナーが表示されるかもしれませんが、残りのコンテンツが完了するまで一つのローディングスピナーが表示されます。
この図は何度もやったことがあります。気にしません。もう一度やります。
ユーザーがクリックして、サーバーがHTMLをレンダリングして、答えが反対側から出てきます。サーバーで待つ必要のないCDNや静的コンテンツであっても、時間がかかるものです。
そして違いはここにあります。クライアントサイドでレンダリングするか、クライアントサイドでReactのようなフレームワークを使用して従来のシングルページアプリスタイルの開発をする場合、複数の異なるステップがあるためより長くかかるとしても、大きな違いがあります。
この終点に到達するのにより長い時間がかかるとしても、本当にクールな他のことが起こります。大きなものは、瞬時に何かが見えることです。つまり、クリックするとすぐにページに異なるコンテンツがあります。これをローディングの瞬間として、ここに置きましょう。
強調したい違いがあるので、これを黄色にします。クリックした後すぐに何かを見ることは、クリックした後にサーバーがレンダリングして応答を送信するまで待たなければならないよりもはるかに良く感じられるということです。特に高レイテンシーや悪いインターネット接続がある場合、クリックした後に何かが起こったかどうかを見るために待たなければならないのは最悪です。そこで、すぐにローディングスピナーを表示します。
これらのスピナーを表示していると同時に、いくつかの作業も開始しています。いくつかのAPIリクエストを作成するつもりです。そして、これを最悪のケースにします。APIリクエスト1をやります。そして、あなたが下手で一つのリクエストだけをするように設定していないふりをします。それらをカスケードしなければならないふりをします。
HTMLをレンダリングする必要がないので、それらのAPI呼び出しを完了したら、応答は少し速くなります。でも、これを少し誇張してみましょう。スピナーを表示します。これをやることで強調します。つまり、スピナーが表示されています。
どのコンポーネントをレンダリングしたいかを理解したら、不適切にAPIリクエスト1をレンダリングしてから、APIリクエスト2をレンダリングします。そして、その2番目のリクエストが完了したら、クライアントで取得したデータを処理しなければなりません。DBコールがどれくらい遅いかなどによって、これははるかに短くなります。少しより現実的です。取得したものを処理し、ユーザーが見ることができるHTML応答を生成し、今度はユーザーが探しているものを見ます。これが最終的なコンテンツを取得するときです。
これのためのより良い図を描く気はありません。過去に私や他の人がそれをやっているのを見たことがあります。何らかの理由で古いものを見つけることができませんでした。しかし、ここでのポイントは、クライアントサイドレンダリングのものが長く時間がかかるとしても、クリックしてからクリックしているものに変化が起こるまでの時間は大幅に短くなるということです。
そして、人間はそれらのことを非常によくも悪くも知覚します。何かをしてから変化が起こるまでの時間を本当に本当に強く知覚します。アクションからインタラクションまでに何ミリ秒、何秒かかるかと、それが速いか遅いかを感じる可能性の間には多くの研究があります。
100ミリ秒以上かかると、脳は同じようにそのことを考えるのをやめます。遅く感じ始めます。1秒以上、10秒以上かかると、離脱して他のことをするでしょう。しかし、ユーザーが何かを見ることを確実にすることは、理想的には30ミリ秒未満で、少なくとも100未満で、本当に重要です。
サーバーへの完全な呼び出しをして、応答が戻ってきてからレンダリングするのを待たなければならない場合、クリックして待って、それが機能しているかどうか分からないでしょう。特に、これらのページの多くの上部にあるローディングバーが遅くて非常に見えにくいからです。だから気付かないかもしれません。最悪です。
即座ではない実際のデータベースから、ただ下手なWordPressブログのようなものではない、実際のデータベースからレンダリングされるデータを持つ実際のアプリを構築しようとしたことがあるなら、それらのページの一部がどれくらい遅くかかるかを知っています。そしてより重要なことに、クリックしても何も起こらないので、どれくらい悲惨に感じられるかを知っています。
クライアントレンダリング方式で30％から、倍の時間がかかるとしても、クライアントレンダリングの遅いサイトは、クリックしたときに何かが起こるので、SSRバージョンよりも速く感じられるでしょう。
その上、これらのローディング時間を短縮する方法があります。同時にこれらのAPIリクエストを行う方法を理解したとしましょう。そうすれば、はるかに早く処理できます。今、突然、ああ、サーバーがページ全体を再レンダリングするのを待つよりも実際に速くレンダリングしています。
または、これらを事前に取得すると、これらを前に移動します。つまり、すでにデータがあります。今度は、すでに持っているデータを処理するだけで、コンテンツをさらに早く表示しています。
ここでの魔法は、クライアントサイドレンダリングを行うときに異なる戦略があることです。なぜなら、クライアントを制御しているからです。データ取得メカニズムに何を入れるかを制御しています。どのデータを取得するか、いつ取得するか、そしてそのデータをHTMLにどのように変換するかを制御しています。
SSRでは、URLにリクエストを送信します。URLはサーバーを指しています。そのユーザーに関するすべてを再び理解し、必要なすべてのデータとコンテキストを取得し、HTMLページを生成し、ユーザーに送信し、そして最終的に何かを見ます。
より多くのクライアントサイドレンダリングを行うときに、より多くのオプションがあるという事実は、すべてがSSR戦略よりも優れているのですが、クライアントサイドレンダリングの欠陥ではありません。開発者として、いつデータを取得するか、そのデータをいつ取得するか、そしてそれをHTMLにどのように変換するかについて、異なる方法を選択できるJavaScriptの利点の一つです。
これらのオプションは、より多くの悪い開発者がより多くの悪い決定を下すことを意味します。しかし、それは熟練した力や熟練した場所の性質です。愚かなことをする方法があれば、それらは愚かな方法で行われるでしょう。私はそれを事実として知っていますし、著者も知っているはずです。なぜなら、私は多くのWordPressサイトを閲覧したことがあり、開発者が所有するこれらすべてのツールと技術で今日のウェブの状態について文句を言っているとは信じられません。
どれだけのWordPressサイトが侵害されたでしょうか？私は個人的に多くの時間とお金、そしてより重要なことに、古いサーバー上の一つの古いWordPress展開がハッキングされて私のサービス全体を乗っ取るために使用されたために回復できない情報を失いました。最悪です。そして、それが私たちが以前に持っていたウェブでした。確かに、それがクールで良くて結構だと思うなら、素晴らしい。あなたにとって良いことです。しかし、それは悪意です。
記事に戻ります。まだ読まずにあまりにも悪口を言いすぎています。
JavaScriptフレームワークの歴史と批判への反論
どうやってここに来たのでしょうか？2010年頃、何かが変わりました。iPhoneが優勢でした。ネイティブアプリは洗練されていて、速く、流動的でした。ウェブ向けの最初の主流JSフレームワークであるAngularが登場したばかりでした。そして突然、すべてのCMOがウェブサイトのブリーフで同じことを言い始めました。
アプリのように感じさせることができますか？
ウェブアプリについてCMOの観点で考えているという事実が、非常に多くのことを物語っています。これまでに開発者という言葉が一度出てきて、次に出てきた職種の固有名詞はCMOでした。新しいフレームワークと良い意図で武装した開発者は「はい」と言いました。JavaScriptは理論的にはシームレスなトランジションと滑らかなUIを行うことができました。そこで、私たちはその約束に向けて構築しました。少なくとも、私たちはそれを試みました。
ネタバレ注意、私たちはアプリのようなパフォーマンスを得ませんでした。より良いユーザーエクスペリエンスも得ませんでした。私たちが得たのは複雑性の軍拡競争でした。
古いYahoo Mailウェブサイトが、GmailやSuperhuman、または私が投資しているMail Zero（もちろん偏見がありますが）よりも良かったと本気で思いますか？
これらのツールと技術の結果として、ウェブでより良いユーザーエクスペリエンスを全く得られなかったと本気で思いますか？以前は不可能だったか、何千人も必要だったものを、数十人のチームが構築しているということを本気で思いませんか？T3 chatが悪いエクスペリエンスか、またはクライアントサイドでJavaScriptを使用しなかった場合、T3 chatがさらに簡単に構築できて、より良くなったと本気で思いますか？冗談ですか？
T3 chatのような品質に近いものを作るには、すべてがサーバーサイドの場合、最低でも100人が必要でしょう。実際、SSCストリームが動作する方法は、多くのJavaScriptなしではクライアントサイドで特に実行可能なエクスペリエンスではないため、できないでしょう。更新レイヤーを機能させるために少しのJavaScriptを自分でロールして、他のすべてをサーバーサイドで行ったとしても、それは滑稽に悪いエクスペリエンスになるでしょう。
私はこれを間違った方向に行き過ぎた人として言っています。私たちはローカルファーストにオールインしましたが、ローカルファーストは完全な災害です。それは別の機会のビデオです。
複雑性の可能性が、悪い開発者がそれを使用したときに不必要な複雑性をもたらしたからといって、これらのツールが問題だという意味ではありません。私はいつもこれを言っています。何かが十分に人気になってデフォルトになると、それはデフォルトになるということです。どの分野でも面白いことは、平均を見ると、人々の半分がその線より下にいるということです。
手の中で平均的な開発者を想像してみてください。ウェブではなく、ただの平均的な開発者、完全に真ん中にいる人です。開発者の半分は彼らよりも悪いプログラマーであり開発者です。彼らの大部分は、他に知らないのでデフォルトツールを選ぶでしょう。
React、Angular、Node、これらすべてのようなJavaScriptベースのフレームワークが、デフォルトになるほど人気になったという事実は、より技術の低い開発者の大部分がそれらを採用するということを意味します。それが人気であることの性質です。より能力の低い人々が人気のあるものを選ぶでしょう。人気のあるものが悪いという意味ではありません。それは悪い人々が人気のあるものを選ぶということを意味します。なぜなら、再び、それは人気があるからです。何かの成功をそれに対して使うことはできません。
少なくともこれが何であるかを理解しなければなりません。私たちは、フルブローンアプリケーション用に構築されたツールで、ナビゲーションやレイアウトのような単純な問題を解決し始めました。ちょっと同意します。これがGatsbyに対する攻撃だったら、私は完全に参加します。
Reactを非常に間違って使用する多くのツールと技術がありました。あなたのサイトがほとんど、もしくは完全に静的である場合、JavaScriptフレームワークは必要ありません。使いたければ使ってください。静的サイトにAstroの代わりにNext.jsを使うことが人生を楽にしてくれるなら、いいでしょう、どうでもいいです。JSなしでコンテンツが読み込まれる限り、問題ありません。しかし、静的サイトには私はまだAstroを選ぶでしょう。
私は個人ブログなどのためにまだそれを使っています。しかし、それは開発者として時間を費やしている場所の大部分ではありません。それが重要なことです。ウェブサイトの大部分がReactを使用しておらず、jQueryとPHPを使用しているという統計をみんな愛しています。
はい、URL数でウェブを測定するなら、確かに。あなたたちについては分かりませんが、私はかなりヘビーなウェブユーザーです。一日に何時間もウェブを使っています。6つくらいのウェブサイトを使っています。
与えられた技術のURL数を測定する代わりに、与えられた技術で働く従業員数、与えられたURLで働く従業員数、またはウェブサイトで費やされる時間数を測定するなら、Reactベースのサイトで費やされる時間は、PHPベースのウェブサイトで費やされる時間よりもはるかに大きな数字です。
チャットで誰かが指摘しているのは、この記事全体が、電子メールがどのように機能すべきかについてのポストマンのレビューのようなものだということです。はい。はい、これがどこに向かうか楽しみです。正直に言うと。
同時に、JavaScriptは単なるフロントエンド言語ではなくなりました。Node.jsの台頭により、JavaScriptはサーバーサイドに移りました。そしてそれと共に、アプリ開発者がウェブエコシステムに参入する波が来ました。
ふむ。他の誰かがこの文を私のために翻訳してくれませんか？ただ、ついていけません。アプリ開発者がサーバーサイドにいて、今、Node.jsのようなJSがバックエンド開発者にウェブ向けの構築を始めさせたと言っているのですか？私は本気で彼がこの文で何を意味すると思っているのか混乱しています。
この人はJSがウェブの前にアプリのためのものだったと思っています。翻訳構文エラー。
何？はい、みんなこれが混乱していることを理解しています。また、WordPressの話題で、WordPressは有用な副作用としてブログも含んでいる認証されていないリモートシェルです。それはとても良いです。それはとても良いです。
少なくともこれによると、ウェブがひどくなっている理由は、すべてのバックエンドからのアプリ開発者がNodeのためにJavaScriptを学び、今彼らがウェブを台無しにしているからだということです。それは正しいですか？
これらはウェブデザイナーやコンドーム出版社ではありませんでした。彼らは文書ではなくアプリケーションを構築するように訓練されたエンジニアでした。静かな部分を大声で言いました。彼はウェブがアプリのためのものになることを望んでいません。彼はウェブが粗雑品のためのものになることを望んでいます。
突然、すべてがクリックします。
そして、この最初の文は、彼が自分のバブルの外の世界をどれほど理解していないかを強調しています。nodeが、これらすべての既存のサーバーからのアプリ開発者に、その結果学んだ言語でブラウザを突然感染させることになったと考える唯一の方法。いえ、これは、私がこの読書の残りの部分で善意でいる能力を汚染した、このすべての誤解と歴史の偽りの理解の妄想レベルを必要とします。
最善を尽くしますが、彼のウェブの誤解が何度も何度も自信を持って述べられるにつれて、ますます困難になっています。
彼らは一緒にアーキテクトファーストのマインドセット、パターン、状態管理、依存性注入、抽象化されたロジックを持ってきました。結果は、ユーザーが記事を読み込むだけでよいときでも、ページを構築することからシステムを工学することへの遅い文化的シフトでした。
これらのもののほとんどが乱用されていて、私がここで同意すると言ったらどうでしょうか？実際、モデルビューコントローラーパターンが10年間ウェブを感染させ、私たちがまだそれらを取り戻そうと働いているという事実は不条理です。これらの大きな実際の会社でシニアからプリンシパルレベルにいるエンジニアと今でも話していて、ブラウザに押し込まれた彼らの奇妙なMVCモデルが実際に彼らを遅くしているのだと説明しているという事実ですが、彼らは500人のチームが決して機能しない粗雑品を出荷しているから自分たちが正しいと確信しています。
JonnoがAngular時代にこのすべてに入り、Angularがウェブに何をしていたかを見たなら、彼の視点がどこから来ているのか実際に理解できます。なぜなら、Angularが最初に特にアプリケーションを構築することについて考えた方法は、それが危険であるほど間違っていたからです。
それが私がこの関心事の分離という糞を信じない理由です。そして、それが私がTailwindのようなものを愛する理由です。それが私がReact、特に関数コンポーネントからフックへのポストを愛する理由です。なぜなら、それはアーキテクチャで考えるのではなく、エクスペリエンスで考えることを可能にするからです。
構築したい機能を構築し、今度はそれが他の場所で再利用できるコンポーネントになります。もし彼がAngular時代にそこにいて、それがすべて起こるのを見たなら、今後のすべてに対して彼がそれほど懐疑的である理由を実際に理解できるので、より同情的です。しかし、Reactがどのように機能するか、なぜ作られたのかを実際に調べることを彼に勧めます。または、私が愛したばかりでビデオをやったベストプラクティスを再考する講演を見てください。本当に良い講演だからです。
記事に戻ります。そして、私たちは一夜にして、まったく異なるニーズの周りでウェブ開発のルールを書き直しました。コンテンツではなく、スピードではなく、相互運用性ではなく、発見可能性ではなく、ただコードです。
ウェブが以前どのように見えていたかを思い出させてください？私は、これがあったときにそこにいた、インターネットで何かを見つけようとするたびに発生したすべての災害を見た、まさにその年齢です。
インターネットで見つけようとしたすべてを覆うこのすべての粗雑品。そして、SEOが価値があった理由は、主に人々をあなたのサイトに行かせることができれば、これらの広告からお金を稼ぐからでした。具体的には、本当のダウンロードボタンではないダウンロードボタンをクリックして、彼らのコンピューターにウイルスを取得するランダムな祖父からお金を稼ぎ、詐欺会社がクリックに対して50セントを支払うのです。
ウェブが以前は素晴らしく高潔で、Reactによって台無しにされたと本当に思いますか、これではなく？冗談ですか？
しかし、良いニュースがあります。JavaScriptがあります。ブラウザの角にあるUblockのための小さなボタンをクリックできます。これはJavaScriptベースの拡張機能です。そして、それをクリックすると、広告がすべて消えます。JavaScriptがウェブを救いました。より高価値にし、より機能的にしました。そして、ユーザーとしてそれをどのように体験するかについても、より多くのコントロールを与えてくれました。
これらの多くの人々がJavaScriptにそれほどハードになり、広告やウイルスや悪いインセンティブが実際にウェブを台無しにしたものであることを認めさえしない理由が私には決して理解できません。彼らが同じカテゴリーで文句を言っているのと同じもので、文句を言っているのよりもはるかに悪いです。
開発者体験対ユーザー体験の議論
私たちがこの道をさらに進むにつれて、スタックは基本から漂流しました。セマンティックHTMLオプション、ゼロから再構築されたサーバーサイドレンダリング。アクセシビリティ、たぶん時間があれば。パフォーマンス、サーバーの代わりにユーザーのデバイスに負荷負担を置くことでコストを節約できるときに誰が気にしますか。
これは最大の売り込みです。これをよく見ます。このような悪いテイクとそれをどれくらい頻繁に見ているかのために、私は何年ぶりかにブログ投稿を書きました。SSRが高価、不必要、またはクラウドプロバイダーが請求書を膨らませるための単なる策略であるという主張を見ることがますます一般的になっています。感情は現実を過度に単純化しています。
SSRはおそらくお金を節約してくれます。オーバーヘッドは最小限です。JSONをHTMLに変換するのは比較的安価です。それほど安価ではないものは、データベースクエリと認証チェックです。そして、大量の認証チェックを行わなければならない場合、一つだけ行えばよい場合よりもサーバーコードにより多くの時間を費やしているでしょう。
公平に言うと、これはシングルページアプリに対するケースのようなものです。しかし、彼がSSRについて文句を言うなら、彼が間違っているので私は反撃します。
SSRはとても安価です。クライアントに移る理由はコスト削減とは何の関係もありません。クライアントに移る理由は体験の節約です。先ほど図解したもので、今度はクリックするとすぐに何かが見えるからです。
再び、私たちには長い間構築した他のどのものよりも成功している新しいサービス、T3 Chatがあります。私たちはすべてのレンダリングをクライアントで行っています。お金を節約するからではありません。アプリがはるかに速く感じられるようにするからです。私たちは、より良く使えるサイトを作るために、SEOでの打撃を意図的に受けています。
JavaScriptを理解する有能な開発者として、私たちは、それが私たちのアプリケーションをより速くするからクライアントサイドレンダリングを選びました。ソフトウェアの書き方を知っていると思うマーケターであるあなたは、私たちがコストを節約するためにユーザーデバイスに負担をかけているだけだと自信を持って主張します。冗談ですか？
徐々に、ウェブはユーザーが必要としたからではなく、開発者がモダンに感じたかったから、公開する前にコンパイルしなければならないものになりました。
コンパイラから得たものをいくつか紹介します。ユーザーに送信されるより効率的なコードを得ました。チェックとエラーハンドリングがビルドプロセスの一部として、間違いが犯されたかどうかを知ることができるようになり、書いたもののより良い信頼性を得ました。より良いものを構築しながら、多くの異なるソースからソフトウェアを構成する能力を得ました。同時にすべてを変更する必要がある何百ものページで同じHTMLをコピー＆ペーストする代わりに、複数の場所で部分を再利用する能力を得ました。
ホットテイク。コンパイラは良いものです。そして、これに対するすべての返信は、はい、そうですというものです。
コンパイラが悪いものだと思う人々をからかいました。Ruby開発者です。ポイントは、コンパイラは悪いものではないということです。彼らは私たちがより複雑な、より良い、より信頼できるソフトウェアを作ることを可能にしてくれます。
あなたのソフトウェアがコンパイラを必要としないなら、あなたと毎日一緒に働く最大2人に対して幸せです。しかし、実際のアプリケーションを構築している私たちにとって、コンパイラは人生をはるかに良くしてくれます。
開発者体験のカルト。今日、私たちはUXではなく、パフォーマンスではなく、結果ではなく、DXを最適化しています。開発者体験です。
これまでの私のこのすべてへの応答で言及した唯一のDXは、あなたの世界ではひどいか、あなたのためにすべての動的部分を書いた誰かがいるWordPressを使っているかの、あなたのウェブサイトのバナーやトップナビを更新するDXでした。
とにかく、今日の人気のあるフレームワークはそのDXで売られています。いえ、Reactはそのメンテナビリティとパフォーマンス特性と迷惑なことの単純化で売られています。しかし、サーバーコンポーネントが純粋にDXで売られたと思いますか？人々が持っている不満のようなものは、ドキュメントが滑らかではないということです。
ああ、これは著者について非常に多くのことを物語っています。これらのツールのドキュメントがどれほど長い間ひどくて、それが良くなるのにどれくらい時間がかかったかを全く知りません。オンボーディングはスムーズです。ツールは賢く、統合されていて、巧妙です。CLIコマンドで新しいアプリを立ち上げて、コンテンツの一行さえ書く前に生産的に感じることができます。
しかし、良いDXは良いUXを保証しません。実際、しばしば逆です。いえ、それらは無関係です。理想的には、最高のユーザーエクスペリエンスをもたらすハッピーパスを最高のDXにすることができます。
DXの改善を通してUXをより良くするものの良い例を知っていますか？アクセシビリティのためのリンターとコンパイラチェックです。私のすべての画像タグがAriaラベルとAria属性を持っていることを確認するコンパイラとビルドステップを持つことは本当に素晴らしいことです。そうすれば、視覚障害者や盲目の人々が使用して体験できるようになります。
それは、アプリケーションにビルドツール、コンパイラツール、リンターを導入する前にたくさん見逃していたものです。それはUXも改善するDXの勝利です。これらは非常に多くあり、私たちが行った建築的決定のいずれかでUXよりもDXを選んだ回数をあまり考えることができません。
これがFlutterについてのコメントなら、私はあなたと一緒です。しかし、ウェブについてのコメントなら、それはせいぜいウェブの誤解です。
私たちが開発者にとって物事をより快適にすればするほど、より多くの抽象化を追加します。そして、すべての抽象化は、構築されているものとそれが対象とする人々との間に距離を作ります。
これは実際に私が少し支持できるもう一つのものです。Flutterのような本当に重いもののような抽象化は、確実にユーザー、ユーザーエクスペリエンス、デバイス、標準からあなたを抽象化します。
しかし、例えばTypeScriptのような抽象化が私たちをユーザーから遠ざけるのはどうしてでしょうか？型システムとコンパイラについて何が、私たちと構築している人々との間に距離を置くのでしょうか？
今、私たちにはボタンマークアップを生成するコンポーネントライブラリがあります。JS関数で管理されるページメタデータがあります。設定ファイルに埋もれた画像読み込み戦略があります。
これらはすべて良いことです。文字通り彼がここでリストしたすべてが良いことです。再利用できるボタンがコンポーネントであること、スタイル保証、ユーザビリティ保証、信頼できるコントラスト比、正確なエリア属性、そしてこれらの他のピースを持つこと。馬鹿らしく聞こえますが、良いボタンを作ることは、ボタンHTMLをレンダリングするほど簡単ではありません。
JS関数で管理されるページメタデータも良いことです。なぜなら、ページメタデータは通常データを必要とするからです。それは言葉の中にあります、データです。そのデータをどのように取得していますか？その動的データをどのように取得していますか？あなたの選択肢は、PHPのようなサーバー言語を使ってデータベースから取得し、奇妙なテンプレート構文でHTMLテンプレートに詰め込むか、または狂った考えで、まったく同じことをするためにウェブプラットフォームですでに標準である言語を使用して、クライアントとサーバーでデータ取得と収集ロジックを再利用できるようにするかです。
狂気です。メタデータが静的HTMLファイルでない場合、すでに関数で管理しなければなりません。PHP関数を好むか、JavaScript関数を好むかの問題です。そして、JavaScriptに対して非合理的な憎悪を持っているなら、突然関数が悪くなります。
そして、画像読み込み戦略については話さないでください。ああ、神様。
この暴言をするたびに、人々は私に怒ります。気にしません。彼らは皆間違っています。WEBPは、インターネットに起こった最高のもののひとつです。ウェブページのほとんどが、最適化されていない、不適切に、もしくは全く圧縮されていないPNGとJPEGを提供しているという事実。ウェブ上の画像の90％以上が、巨大で読み込みがはるかに遅いJPEGとPNGです。
インターネットが遅すぎるという不満があるなら、その問題を解消する画像読み込み戦略を本当に好むべきです。これらすべての素晴らしい新しいコーデックがあり、今度はNext.jsのような構成のような素晴らしいツールがあって、やりたい方法でURLを介して画像を読み込むことが本当に簡単になったという事実。そして今、ユーザーはこの巨大な20メガバイトのJPEGを取得しません。
何も異なることをすることなく、12から20キロバイトのwebpを取得します。それは素晴らしいことです。それは完璧なバランスです。それはUXの勝利でありDXの無操作です。開発者体験を全く変えていませんが、ユーザーエクスペリエンスを大幅に改善しました。
DXが良いUXを保証しないと文句を言った後の段落です。一つの議論を選ぶか、少なくとも議論している点を理解する必要があります。
すべてが開発者のために最適化されていて、他のみんなに敵対的です。画像読み込み戦略と設定ファイルは誰に敵対的ですか？これをフレーズする方法から、ここでの問題は、これらのものでの開発者体験であるように思えます。それは不必要なレベルの開発者の関与です。これらのすべてのものは、ユーザーにとって物事をより良くします。
とにかく、これは偶然ではありません。それは文化的です。私たちは、複雑性が賞賛され、巧妙さが報われ、工学的洗練が明確さ、使いやすさ、または商業的効果よりも価値がある業界を作りました。
それで、私は完全にこれに同意します。その丘で死にます。
実際、複雑性がそれほど賞賛されているという事実は、多くの異なるレベルで悲惨です。特に企業でよくこれを見てきました。ユーザーにとって後退である変更について30ページのレポートを書き、その後20人のチームでそれを実行して昇進を得る人。
しかし、ユーザーが抱えている問題に気づき、それらを修正し、その後どのようにしてなぜそれをしたかについて1〜2ページを書く個々の開発者。より多くの仕事をしたように見える人が昇進を得ます。そして、実際に問題を修正すべき方法で修正している人は、昇進を得ないだけでなく、そのために書面で注意を受けるかもしれません。それは非常に現実的なことです。
私は、これが私たちが使用している技術とは何の関係もないと思います。実際、TwitchでReactに移行したときの面白いことの一つは、その文化の多くがウェブサイトで死ななければならなかったことで、まだそれに関与していた少数の人々は、ユーザーの問題を解決する正しい簡単な方法で物事を構築することが常にすべきことであるので、結局恥ずかしい思いをしました。
そして、これが実際に私と著者の間で合意を見つけ始めることができるかもしれない場所だと思います。もし彼が正直にこれらのツールをこのすべての原因として認識しているか、または逆に彼がこれを問題として見ていて、これらのツールがそれから出てきたと見ているなら、彼がここでそれほど憤慨している理由を理解できます。なぜなら、これは本当に悪い問題だからです。
もしあなたが、ランダムな人がファンシーな言葉や用語でいっぱいのこの狂った提案を書いて、実際にはユーザーのために何もしないか、彼らにとって物事をより悪くするそれらのチームの一つにいたことがあり、そしてあなたがこのタイプのビデオを見るタイプの人であるなら。それは本当にひどく吸います。
それは、特に長期間それを経験するなら、その結果として少し妄想的になることを責めないほどひどく吸います。この段落のために、彼にもっと多く同情できますし、今後できるだけ彼がここで言ったことのレンズから読もうと努力しますが、再び、チャットが正しく指摘しているように、彼が説明していることは、ReactよりもCorporate Javaのように聞こえます。
また、Demiからのもう一つの良いものです。公平に言うと、私たちは皆、トラウマに基づいた悪いテイクを持っていると思います。チームミーティングで少し暴言を吐くかもしれませんが、一般的にブログ投稿を書いて「このテイクのために私を雇うべきです。それは悪いです」と言うほど賢くありません。はい、完全に同意します。
彼が自分のトラウマを、理解していない全世界を糞にすることで外に出しているという事実は良くありません。しかし、それがここでこの部分に根ざしているなら、彼が感じているトラウマに同情できます。
そして、すぐに私の善意の多くを奪い取ります。SSRの互換性問題を引用して議論に勝つ方が、なぜブログにReactを使用しているのかを問うよりも簡単です。
そこでの3つの考えです。良い理由がない限り、ブログにReactを使わないでください。ハイドレーション問題はそれほど解決が困難ではありません。特にブログの場合、90％がdatetimeのものです。そして3番目、キャッシングは困難です。期間。そして4番目、理由がない限りブログにReactを使わないでください。
はい、これは彼が実際に経験したもののように聞こえ、そのために同情できます。しかし、ブログとコンテンツ管理側で対処したチームは、私が人生で会った最悪の過度の工学的愚か者の一部だったと約束します。
Twitchでブログを担当している人がMP4やPNG以外のものを埋め込む方法を知らなかったために長い戦いになり、私がほとんど困った立場に陥った話があります。
実際、MP4を埋め込む方法さえ知りませんでした。MP4を埋め込む方法は、ビデオをアップロードできた頃のTwitchにアップロードしてから、ビデオプレーヤーを埋め込むことでした。
私が構築した製品の一つであるmod view launchのために、私のデザイナーとプロダクトマネージャーが、製品を見せる本当に良い4秒間の例のように、本当に良い4秒間のビューを作るために多くの時間をかけました。それは、製品を見せるためにブログ投稿に埋め込むような小さなwebmタイプのものでした。
ブログを運営している人は「オーケー、クール。はい、それを完了します」と言いました。そして、彼らは私たちのローンチのためにブログ投稿を立ち上げて、最大3〜5秒のクリップを見るためにボタンを押す必要がある、下手なUIで覆われた5つの手動クリックtoplayのTwitchプレーヤーがあります。
私はすぐにDMして「何をやったんだ？」と言いました。これらの小さなMP4を埋め込むために送ったのに。彼はそれらを埋め込んで自動再生させることができないと言いました。WordPressか何かを使っていたと思います。私は「オーケー、いいよ、どうでもいい。投稿に埋め込むHTMLがここにある」と言いました。
彼はそれをやりましたが、正しいファイルにURLを向けませんでした。この時点で、私はイライラしています。そこで、私はファイルを取って、webとして再エンコードしました。私はそれらを自分のS3バケットに置き、公開としてマークし、正しく機能させるために正確なURLがすでに埋め込まれた正確なHTMLを彼に渡し、それが良いことを確認するために自分でページに埋め込んでテストしました。
この男と4日間のやり取りを費やしました。そして、彼はHTMLを貼り付けて、それが機能するかどうかもチェックせずに出荷しました。彼が自分で構築したと主張し、エンジニアであると主張する彼の下手なインターフェースは、彼が知らない方法すら知らない彼の資産管理ツールへのローカルURLであることを期待していたため、URLのURL文字をエスケープしました。
そして、すべての埋め込みが壊れました。その時点で、私は諦めて、彼が最初から求めていたものを彼に与えました。20メガバイトのGIFです。
申し訳ありません。そのその人がレイオフされる前にもう一度昇進を得たという事実は、この糞記事で引用されているどのものよりも悪いです。申し訳ありません。彼に対して怒鳴りつけることさえしないで、どれほど怒っていたかについてただチームに吐き出しただけで、私がほとんど困った立場に陥ったのです。
マネージャーから「おい、落ち着けよ。このことでそれほどハードに行くと困ったことになるぞ」というような警告を受けました。私は「この人は自分の糞仕事をしていない。ここで雇われるべきではない」と言いました。週末の1時間の余暇で、私は彼の仕事全体をより効果的に行うことができます。そして、それがそれよりも複雑であると偽らないので、私は決して昇進を得ることはありません。
だから、ここであなたを感じます。しかし、Jono、あなたが来ている世界は、私のものよりも何度もこの糞をやります。しかし、私たちが同じ場所から来ている可能性もあります。あなたがウェブ開発者と1〜2回の経験をして、彼らが最悪だったということです。そして、私はSEOマネージャーやブログマネージャーとの10〜20回の経験があって、それらがさらに悪かったということです。
私たちは皆そこにいたことがあります。私たちは皆それをやったことがあります。CMSが悪だということについてブログ投稿を書くことはありませんが、あなたはより強い感情を持っています。そして、それは良いです。間違っていますが、良いです。
私たちは、それが良い感じで、楽しく、モダンに見えて、誰も私たちを止めないので、間違ったものを最適化し続けています。
これらの信じられないほど賢い人々が、楽しくて良い感じだったからこれらの信じられない技術を発明したと思いますか？多少はそうかもしれませんが、彼らのほとんどは、通常はパフォーマンスと体験や保守性と複雑性の周りで、解決したい特定の問題を認識するからそれをするのです。
複雑性がデフォルトになります。こうやって螺旋状になります。私たちはもはや複雑性を評価するだけではありません。それを期待しています。すべてのサイトがビルドステップ、バンドラー、ハイドレーション戦略、ルーティングレイヤー、APIレイヤー、デザインシステム、そしていくつかの巧妙なキャッシュ無効化ロジックを必要とすると仮定しています。
私たちはマイクロサービスで構築し、エッジネットワークでホストし、基本的なコンテンツを出荷するためにパイプラインをデプロイします。
この人は、ウェブ全体が基本的なコンテンツだと思っているようです。これらのものを特定の用語で考える代わりに、それがあなたにもたらしているもののように、これは怖いです。
ビルドステップはコマンドです。バンドラーは、コードをユーザーが取得するものに変換する方法です。ハイドレーション戦略は、同じコードをクライアントとサーバーで実行していて、クライアントがサーバーが止めたところから拾う必要がある場合にのみ関連します。クライアントレンダリングをしているか、完全にサーバーレンダリングされるAstroのようなものを使用している場合、ハイドレーションは何も必要ありません。そして、ハイドレーション戦略のアイデア、いえ、戦略はありません。開発者が自分の独特なハイドレーションを処理する方法を考え出しているわけではありません。
彼らはサーバーでコードをレンダリングし、React Next.jsを使ってクライアントで拾っているだけです。これらすべてについてそう言います。これらのもののどれも、人々が構築しているものや考えているものでもありません。
これらのモダンフレームワークのほとんどでは、ルーティングレイヤーはURLパターンにマッチするファイルとフォルダーです。APIレイヤーは、データを取得するために呼び出す関数です。デザインシステムは、再利用するコンポーネントです。HTML至る所に貼り付けるのが好きな人からの狂った考えです。
そして、いくつかの巧妙なキャッシュ無効化ロジック。いえ。サイトが静的なら、静的です。無効化は必要ありません。サイトが完全に動的なら、完全に動的です。無効化は必要ありません。部分的に定期的に更新されるものを構築している場合、それをオンデマンドで無効化する能力を持つことは本当に強力で、負荷を減らすのに役立ちます。SEOツールではなく、実際のユーザーを取得するものを構築している場合は理解できないことです。
ブログ投稿を公開するかeコマースサイトかに関係なく、スタックは同じです。有用性の端まで工学された重い抽象。
ここで少し同情できます。すべてにReactを使っているという事実は、この一つのもので使うことができて、ほとんどの場所で使えるほど良く機能することが狂っていることは本当にクールです。同じフレームワークがMetaQuestやPlayStation 5のオペレーティングシステムを構築するために使用され、TwitterやFacebookのような統合体験やShopifyのようなeコマースサイトに使用されることは、実際にクールです。
しかし、同時に、それは生態系がそれらのソリューションの一つのために構築されたもので、他のものではないものを持っていることを意味します。そして、すべてに同じツールを使用する場合、悪い場所に行き着くことができます。
これが、T3スタックのテンプレートレポを作ることを拒否し、代わりにコミュニティがCLIを作った理由です。人々が自分の糞ブログにTRPCやその他のライブラリをインストールすることを望まないからです。
この問題の解決策は、モジュラーデザインと必要に応じて適切なピースを選ぶことであり、すべてがどれほど重くて抽象的かについて文句を言うことではありません。抽象化は実際にこの解決策です。なぜなら、必要に応じてモジュラーピースを追加および削除できることを意味するからです。
これはもう一つの面白いものです。誰もそれを理解していません。完全には。あなたは彼らが理解していると言っているのですか？この声明から取ることができる2つのパスがあります。
代替案であるWordPressを人々が完全に理解していると言っているか、またはより一般的な理解の定義を使用していて、平均的なWordPress開発者が平均的なReact開発者がJavaScriptとウェブを理解するよりもPHPをよりよく理解していると本気で信じているかです。
そして、そこでも、私はちょっと同意します。境界線にいます。しかし、それは100倍多くの開発者がいて、WordPressを使った開発者よりもReactを使っている開発者がはるかに多いからです。
しかし、これは特に非声明で、代替案が提示されておらず、代替案が提示されない理由は、それらがさらに悪く見えるからです。
マーケターでも、SEOでもない、6ヶ月前にそれを構築した開発者でもない。すべての新しいツールが新しい抽象化、新しい構文、新しいメンタルモデルをもたらします。見出し、メタタグ、またはレイアウトに簡単な調整をすることが、3ステップのデプロイプロセスになります。それは狂気です。
見出しをトップナビと再び交換すると、議論は完全に反転します。私は、同じ5行のコードを400ファイルで編集してから、FTP経由で手動でそれらすべてをプッシュするよりも、ビルド・リント・デプロイである3ステップのデプロイプロセスをはるかに好みます。
あまりにも詳細に入ると、あまりにも多くの作業が起こっているように感じられます。しかし、コンピューターについて本当にクールなことがあります。彼らは何かをすることができます。3ステップのデプロイプロセスが自動的に並行して実行でき、全体が他のプロジェクトからコピー＆ペーストしたかchat GPTからコピーした10行のYAMLコードであり、今度は会社の誰かが変更をするたびに、それらが安全かどうか、リンティングが通るかどうか、アクセシビリティチェックが行われて物事がおそらくほとんどアクセシブルかどうかを知り、マージをクリックしたときにそれらのチェックが再び実行されて、すべてが大丈夫であることを確認することは魔法的です。
それは素晴らしいことです。しかし、明らかに、その素晴らしいことは狂気です。
私たちは、数キロバイトのテキストを提供するために、航空交通管制システムのようにウェブを再構築しました。
いいでしょう。ブログにReactを使わないでください。WordPressも本当に重いですが。
最悪の部分は、複雑性のほとんどが、デフォルトで得ていたものを改造するためだけに存在することです。ルーティング、メタデータ、キャッシュ、テンプレート、レイアウト。
テンプレートとレイアウトをデフォルトで得ていました。キャッシュをデフォルトで得た方法を見たいです。サイトのトップナビを変更した場合、ユーザーが新しいバージョンを見るのにどれくらい時間がかかりますか？
航空交通管制が著しく時代遅れであることも面白いです。チャットで誰かが指摘したように、航空交通管制がフロッピーディスクとかで動いているので余計に面白いです。
私たちは革新していません。ウェブがすでに私たちに与えてくれたツールの壊れたバージョンを再構築していて、それを下手にやっています。ああ、あなたは、ページの上部にあって最悪で、客観的に測定して悪いユーザーエクスペリエンスであるローディングバーを意味しますか？
とにかく、スタックは自分のイメージで自分を再構築しています。今日に早送り。皮肉なことに、抽象化と複雑性を追いかけて何年も経った後、JSエコシステムは今、私たちが失ったものを再導入するために奔走しています。
SSRが再び流行り、慎重に管理されたルーティング、URL構造、メタデータ、さらにはHTML出力、すべてが一度に一つのプラグインで再構築されています。
彼はライブラリをプラグインと考えているのでしょうか？それは多くのことを説明するでしょう。
実際、WordPressの世界から来ているなら、私たちが今構築している方法を、UnixやLinuxのようなものではなく、50のプラグインがインストールされたWordPressインストールのように見るかもしれません。WordPress時間をやったことがある場合、プラグインをインストールするたびに、プラットフォーム全体が崩壊してすべてが壊れる可能性が指数関数的に増加することを知っています。
そして、それはトラウマ的で地獄的です。そして、それがpackage JSONについてどのように考えているなら、この恐怖がどこから来ているのかを理解できます。しかし、現実の世界では、実際の問題を解決するために構築された実績のあるソリューションを再利用することは良いことです。
それが、Unix全体とLinuxエコシステム全体がこれらのアイデアで構築されている理由です。ウェブツールがLinuxの世界のようになることは良いことだと思います。明らかに、著者は反対意見です。
それは私たちが始めたもの、サーバーでレンダリングされたHTML、ユーザーに近くキャッシュされた従来のCMSと、ますます似てきています。
ユーザーに近くキャッシュは以前のケースではありませんでした。それは妄想的です。従来のCMS、私たちはまだそこに近くありません。そして、誰かがその方向に行き始めるたびに、何か狂ったことが起こります。PayloadがFigmaに買収されるように。
つまり、いえ、私たちは全くそこにいません。これは野生のテイクです。TwitterをCMSと呼びますか？YouTubeをCMSと呼びますか？あなたにとってCMSとは何ですか？SEOコンサルタントとして開くものですか？それとも人々が関わるツールですか？
プラットフォームを再構築しています。ああ、神様、彼はWordPressさえ肯定的に引用しています。冗談ですか？本気で冗談ですか？私は狂いそうです。
面白くないでしょう、それほど疲れなければ。これは、新しさに取り憑かれた開発文化の終着点です。私たちはより良いサイトを出荷していません。基本的なインフラストラクチャをますます複雑な方法で再発明していて、それがほとんど機能するという事実を祝っています。
この記事は私が期待していたよりもはるかに長いです。いつものように、全体を読みたい場合は、リンクが説明にあります。あなたをこれ以上苦しませないため、また私自身の苦しみを減らすために、最後のポイントを要約します。
この次のセクションがマーケターとユーザーへの巻き添え被害だということにおかしくなります。文字通りユーザーの前にマーケターを置いています。文字通りそれをやっただけです。冗談ですか？
それが彼の考え方です。それが広告でウェブを膨張させることやスパイウェアは大丈夫で、そのことについてどこでも一言もない理由です。しかし、何らかの理由で、Reactは本質的に存在論的に悪です。野生です。
まるでユーザーよりもマーケターについて考えていて、私たちがユーザーよりも開発者について考えていると私たちを非難しているようです。
とにかく、マーケターはチケットを上げずに、コピーを更新したり、実験を実行したりできません。コンテンツをプレビューしたり、レイアウトをテストしたり、ページを立ち上げたりできません。すべての変更は、開発者、パイプライン、承認、再構築を通らなければなりません。
一方で、WordPressで何でも変更できることに慣れているマーケターで、今はできない場合、動揺している場合は同情できます。理解できます。
しかし、WordPressで物事を変更することは、モバイルで動作するサイトを作ることにはなりません。ユーザーが実際に関わって使用できるモバイルアプリを作ることにはなりません。複雑な実行可能なインタラクティブページを作ることには全くなりません。
しかし、WordPressの体験に慣れていて、誰でも入って何かを更新でき、すべてを壊す30％の確率しかない場合、それは確実に最悪です。しかし、私たちが構築しているものはより複雑です。
以前は、ウェブサイトは世界中で同じ標準タイプのインターネット接続で、同じアスペクト比で、一種類のブラウザでレンダリングされるものでした。各側のすべてがより複雑になりました。それが物事が改善することの性質です。
しかし、技術的でない人々が貢献できなくなったことは確実に最悪だということに同意します。しかし、はい、彼らが貢献したい多くのものは、とにかく彼らができるべきではないものです。つまり、これで50/50です。
しかし、開発者がTwitterが構築された方法でブログを構築し、今マーケターが物事を変更できないという角度から完全に来ているなら、はい、それはちょっと最悪です。そこでは私はあなたと一緒です。
さて、いくつかの合意をもっとできます。JavaScriptは強力ですが、誤用されています。明確にしましょう。JSは悪役ではありません。強力です。不可欠です。豊かなインタラクティビティ、動的コンテンツ、リアルタイム更新などを可能にします。ページではなくツールを構築することを可能にします。
Twitterはツールですか、それともアプリですか？なぜなら、あなたはアプリが好きではないような感じがするからです。
ほとんどのウェブサイトはツールである必要はありません。実際、ここで完全に同意します。ほとんどのウェブサイトはツールやアプリケーションである必要はありません。
しかし、これは再び、異なるURLと費やされた時間の区別です。ウェブで費やされる時間の大部分が古いブログ投稿を読むことではないということに皆が同意できることを願っています。
Twitterのようなウェブ上のこれらのツールやアプリケーションに関わることです。今、最も多くのWordPressブログがあるよりもtwitter.comははるかに少ないです。しかし、解決されている問題の複雑さのレベル、またはそのものに取り組んでいるエンジニア数、またはただ時間を費やされている時間の関数として見ると、突然この議論は消えます。
最もウェブサイトの議論にはとても疲れました。なぜなら、ウェブサイトの大部分は15年以上更新されていないからです。それは何のための実際の議論でもありません。
ここでも完全に屈服します。ウェブサイトの大部分はReactを使うべきではありません。なぜなら、ウェブサイトの大部分は、もう誰も行かない、ウェブの角の冷たい棺で静かに死ぬべきだからです。それがインターネットの現実です。
ウェブサイトの大部分はゼロユーザーとカップルのボットを得るでしょう。ほとんどのウェブサイトがツールである必要がないだけでなく、ほとんどのウェブサイトにはユーザーさえもいないので、誰が気にしますか？
一方で、eコマースでさえフレームワークが必要ないということに同意しますが、もしブラウズするのがより速く感じられるものを作ることができ、大量のカスタムコードを書く必要のない検索体験を持つことができ、最悪ではないカート管理を持つことができ、また、モーダルも持つことができれば、それから大いに恩恵を受けます。
純粋にバニラでモーダルができるふりをしないでください。これをあまりにも多くの回数試しました。できません。これらのもののウェブ標準は絶対的に糞です。動的コードを書かなければならず、フレームワークを使うとそれが大幅に簡単になります。特にアクセシビリティのようなことを気にする場合。
これを愛します。一部のサイトには、ログイン状態のような本物のクライアントサイド状態ニーズがあります。
彼がログインを一部のサイトが必要とするものとして軽視しているという事実は、私が必要だと思うすべてを言います。
これらの人々がAstroについて話しているのを見ないのは残念です。彼らは常に、WordPressや11のように、意図的にJavaScriptを完全に避けるものを引用します。あなたがここで探しているものを与えてくれるより良いモダンなツールがあることを知っています。そして、それが本当に価値を追加する場所に合理的なJavaScriptを持ち込むことを可能にします。
明らかに、著者は、death to spasという名前のビュートランジション用のWordPressプラグインをインストールしました。記事を真剣に受け取ることはできません。
長いpackage JSONファイルに動揺しているソルティなWordPress開発者のように感じます。私はあなたを感じます。著者がどこから来ているのかを理解できますが、彼が来ている場所は、多くのウェブサイトであるため大きく感じる小さなバブルですが、非常に少量のトラフィックであるため小さいです。
私は彼に、開発者ツールと彼らのユーザーの両方を気にする開発者とより多くの時間を過ごすことを勧めます。私のような人々とは必要ではありません。なぜなら、私は話すのが迷惑だからです。特に最近は。私はあまりにも糞忙しいです。
しかし、ここにたむろしている素敵な人々、あなたたちのどれもがあまりにも多く苦しまなければならないことを願っています。もしそうしたければ、リンクは説明にあります。そして、このような人々に対処しなければならない場合、申し訳ありません。これ以上何もありません。
コメント