一言でいうと、流行とその反動かなと思います。

まず、jQueryに人気が出た理由としては、JavaScriptが Webページの「ちょっとした飾り」に使われていた時代を経て、ユーザーの操作に応じて画面の一部が変化するなど、アクティブなページ制作に利用されるようになってきました。

しかし、素の JavaScriptはページ操作（DOM操作）が煩雑だったり、サーバーサイドとの通信に手間がかかるなどで開発が大変になってきたため、それらを補助するライブラリーの開発競争がスタートしました。Prototype.jsや script.aculo.usなど当時さまざまなものがありましたが、ここで勝利したのが jQueryでした。

jQueryは圧倒的なシェアを獲得し、JavaScript開発をするなら使うのが当たり前と言われるくらいのシェアになりました。しかし、jQuery自体はそもそも完璧なライブラリーではありません。

その後、より Webが高度化して、1ページであらゆる作業が完結する「SPA（Single Page Application）」など、アプリケーションのような動きをする Webページも登場してきました。しかし、HTMLの内容が大きく変わるようなプログラムの場合や大規模なプログラムの場合、jQueryでは手作りしなければならない部分が多いのです。

そこで次に登場したのが、MV*フレームワークと呼ばれるものの開発競争です。Backboneや React、Angularなどのフレームワークが登場し、これは今も開発競争が続いています（Reactが一歩リード中？）。

さてここで、なぜか今度は「jQueryなんてダサいよね」という流れができてきました。jQueryは重い、ファイルサイズがでかいなど、いろいろな理由から「jQueryを外そう」という「反流行」が出てきました。こういうことはよくあり、エンジニアは「人気がありすぎるものを嫌う」という傾向が若干あります。

本当は、役割に応じてベストなライブラリーを選べばよいだけで、jQueryがベストな場面も存在しているのですが、なんでもかんでも jQueryという時代からは一歩進んだというのも確かです。

jQueryは何を解決したかったかを教えます。

webページを作る一番簡単な方法は、HTMLを書くことです。

ここにタイトル

ここにリスト

というような宣言（マークアップ）をするだけで済みます。（静的）

ここで、最初に作られたHTMLページの中身を変えたいとします。（動的）

方法は２つあり

• ページを再度読み込む
• DOMを操作する

後者をする際に使用されるのが、DOM APIで、ブラウザ上で動くJavaScript上で使えるようになっています。

さて、例えばリストを変更したいとします。

このとき、リストの要素数が変わるとします。

DOM APIを通してJavaScriptからブラウザに命令する内容は、

① まずは、リストの要素数を数えて、多かったら削除して、少なかったら足してね

または

② この際、リストは全部削除して。新しい要素のリストで全部生成し直して

といったところです。

この処理を、vanillaのJavaScriptで行おうとすると記載量が（初期のDOM APIだと特に）多いため、ラッパーを作り、さらにいろんなユーティリティを足せるようにするようにしました。

それがjQueryとそのプラグイン達です。

便利に感じますが、例えば先ほどの①と②だと、目的は一緒なのに①の方がパフォーマンスに優れます。

なぜならDOMの生成は、パフォーマンスコストが高く、①の処理を行うために必要な

「現在のリストの構造の保持」→「新しいリストの構造との比較」→「差分の適用」

は面倒ですが、DOMの再生成よりずっとパフォーマンスに優れていて、要素数が多いほどコストの差が開きます。

もちろん「構造の保持」はメモリを消費しますが、人がwebページを通して認識しきれる量なら、大した問題になりません。

Reactに使われている仮想DOMと差分パッチの技術をご存知でしょうか。

• 現在のDOM構造の保持
• 新しいDOM構造との比較と、パッチ当て

をしてくれます。

つまり、DOM APIまたはそのラッパーであるjQueryを用いた場合に比べて、効率的にDOMの操作が行えて、指定しなければいけないのは前後の構造だけになります。

仮想的なDOMの構造を指定するには、一般的には「h関数」を入れ子で呼び出すのですが、それに対するシンタックスシュガーがreactにおけるjsxになります。

jsxの記法はHTMLによく似ています。

静的なHTMLを書く感覚で、動的な部分のみJavaScriptの式を組み込むことができます。

動的な部分が変わるたびに、毎回違う構造の仮想DOMが生成され、効率的なパッチアルゴリズムで実DOMに反映されます。

なので、DOM APIでパフォーマンスの良くメンテナンスのしやすいコードを素早く書けるなら、jQueryを使った方が正解です。

数年前から「jQueryは死んだ」と声高に喧伝するWebサイトが増えましたね。

jQuery「便利なものは、使ってナンボですよ？」(画像は Bing Image Creatorを使用)

jQueryは今もごくごく当たり前に使われています。少なくとも純粋なJavaScriptよりjQueryで書く方が記述量は相当減るからです。「怠惰」を目指すプログラマーの1人として、個人的にjQueryをあえて避ける理由はありません。(プログラマー界隈での「怠惰」は「少ない労力で多くの仕事をこなす」という意味の褒め言葉です)

ちなみにかなり大規模なサイトでも、フォームによるデータ送信や画面遷移を行う一般的なWebサイトの設計なら結構な割合でjQueryが採用されます。LaravelやDjango、Express.jsなどフルスタック寄りのフレームワークは、jQueryと組み合わせると効率よく便利に開発できるからです。最近注目されているReactやVueなどのJSフレームワークは、主にNext.jsなど専用のJSアプリケーションフレームワークやFastAPIなどフロントエンド機能を省いたWebAPIフレームワークと組み合わせた場合に最も真価を発揮します。

まぁどちらにせよ、jQueryに限らず「どのフレームワークやライブラリを使って開発すべきか」の議論は「最も優れたプログラミング言語はどれか」の議論と同じぐらい不毛で意味がありません。気に入ったものがあれば使えば良いですし、使いたくなければそれで良いと思います。結局は慣れているものが一番効率的に開発できますよ。

「jQueryは死んだ」と言われるのは、当時JQueryが利用される最も重要な理由であるブラウザ間の仕様の差異を埋める役割がES6の登場である程度終止符が打たれ現在においてはVanillaJS（素のJavaScript）の長ったらしい構文のシンタックスシュガー的な役割でしか価値が無くなってきたことでしょう。

みんなjQueryでよく使っていたであろう$(element).animate()も、WebAPIのAnimationsAPIや優れたライブラリで置き換えれますし、Ajaxも標準のfetchやAxiosで実装できます。

問題なのはjQuery ではなく、当時jQueryが大人気だった時にjQueryでしかJSを書けない人たちがわんさかと大量に生産されてしまったことが大問題でした。
$(function(){ });の意味すらわからずに、同じファイルに何個も$(function(){ });を書いていたり、同じエレメントに対して何度も同じプロパティの変更を意味なくしていたりと、ある意味jQueryの懐の深さが仇となって重くメンテナンス性の低いコードが大量生産されてしまったことですね。

PHPでもRuby on Railsを踏襲したcakePHPというフレームワークの誕生のときに同じような現象が起きました。ある程度のフルスタックエンジニアが即席で育てれるため、プログラミングスクールや専門学校などでcakePHPのみを教えて、業界にcakePHPしか使えないエンジニアが大量生産されました。cakeのラッパークラスしか使えないエンジニアがいっぱい現れましたよね。今ではcakePHPもLaravelに取って代わられ、現在では過去のシステムのメンテナンス程度の案件しかありません。その時の大量エンジニアも、一部の人を除いてほぼ淘汰されていったような感じです。

結局のところjQueryを使おうが使うまいが、素のJSを理解していざVanillaJSでも書けるようになっておかなければこの先業界では食っていけません。だってjQueryも素のJSで書かれてるんですから。React等のフレームワークも最後にはVanillaJSにコンパイルされます。
やっぱり基本は不変です。

サーバーサイドのNodeJSとかとなるとjQueryなんて全く関係ありません。あくまでwebAPIのシンタックスシュガーです。

最後にjQuery大好きです。昔まだInternetExplorerが猛威を奮っていた時には無茶苦茶お世話になりました。

作りたいものと、開発のチーム状態とプログラマー次第ですが、私はJavaScriptのフレームワークは出来るだけ深入りしないでやりすごそうと決めています。Reactはチュートリアルと少し自分でテストしてみたぐらいです。そのほかのフレームワークもテストして、利用するのを保留しています。

私の理解では、今のブラウザはかなりの混乱状態だと思っています。ECMAScriptの仕様は肥大化して、実装ごとに微妙に、というか盛大に振る舞いが違い、DOMオブジェクトとXMLHttpRequestの仕様も歴史的経緯から、微妙に異なっています。

実際のDOMオブジェクトとは別に内部にDOMオブジェクトを仮想的に作るのは動機は理解できますが、どうしても美しいとは思えないのです。大げさで、もっさりと重くなり、フレームワークの不具合にはほとんどの場合は何もできません。微妙なバグが残っているものが多く、手を出しにくいです。

DOMオプジェクトの構造の中に、直接データを書いたり、イベント呼び出しのコールバック関数をセットする、というやり方を試してみたら、シンプルでコンパクトに実装することができたので、仮想DOMは使わずにプロダクトを作っています。

ハマりそうなところをシンプルにやり過ごすのがフルスタック野郎の流儀なのですね。

出荷したプロダクトから支障のない範囲で抜き出してみました。差し障りのあるところを一部書き換えています(コード断片なので動きません)。できるけオールドスタイルのフォームに近い記述をします。各ダグの標準的な要素に格納できるデータは全て標準を使い、それ以外はdataタグを利用して、値チェック用の正規表現や修正時を促す時の文字列を格納しています。特定のクラスにイベントによって発火するコールバック関数をセットすると、少ないコードでかなり高機能でわかりやすいフロントエンドを作ることができます。記述が「宣言的」でコンパクトなのも気に入っています。実際にバグも非常に少ないです。

いわゆるオレオレフレームワークですが、class属性をみてコールバック関数をフックしているだけで、コールバック関数にはそのDOM要素を引数として渡して、属性を利用しているだけなので、とても読みやすいと思います。DOM要素の操作とXMLHttpRequestのアクセスはjQueryに全て任せています。

仮想DOMは良さそうなので、いつも研究するのですが、結局プロダクトでは採用を見送っています。バージョンアップも早く、Auglarのように下位互換がなくなってプロダクトのコンセプトも変わったりするのもプロダクトでの採用を躊躇するポイントです。あと結構重たい。軽いやつはバグが残っているし、そのバグには手が出ない。

ほとんどのアプリケーションではjQueryと軽めのアニメなどのライブラリを使って工夫すると高品質で軽く、バグが少ないフロントエンドが作れると思いますよ。

        </h6> 
        下記に設定した数以上出品されている商品を出品します<br> 
        新品 
        <div class="input-field inline small-field"> 
            <input 
                class="mds-input mds-input-center" 
                name="min_offer_new" 
                type="number" 
                min="0" 
                max="100" 
                data-fn="min_offer" 
                data-rx="[0-9]{1,3}" 
                data-sg="整数を入力してください" 
                value="<?=$settings['min_offer_new']?>" 
            > 
        </div> 
        中古 
        <div class="input-field inline small-field"> 
            <input 
                class="mds-input mds-input-center" 
                name="min_offer_used" 
                type="number" 
                min="0" 
                max="999999" 
                data-fn="min_offer" 
                data-rx="[0-9]{1,3}" 
                data-sg="整数を入力してください" 
                value="<?=$settings['min_offer_used']?>" 
            > 
            <input 
                    type="hidden" 
                    name="country_code" 
                    value="<?=$hidden_country_code?>" 
                    data-rx=".+" 
                    data-fn="min_offer" 
            > 
        </div> 
        <button 
            class="btn mds-form-button" 
            style="margin-left: 15px;" 
            data-fn="min_offer" 
            data-rl="/operation/setting4country" 
            data-md="PUT" 
        > 
            <img src="../assets/img/send_white.svg" style="height: 34px;"> 
        </button> 
        <p 
            class="mds-button-message" 
            data-fn="min_offer" 
        > 
        </p> 
    </div> 
$(document).ready(function() { 
    //値変更されたとき 
    $(".mds-input").bind( 
        'input', 
        function(){ 
            mds_input_change($(this)); 
        } 
    ); 
}); 
     
    //入力フィールドの数値が変更されたとき 
function mds_input_change(jQueryObject) { 
    var button_message = $("p[class=mds-button-message][data-fn=" + jQueryObject.data('fn') + "]"); 
    var button = $("button[data-fn=" + jQueryObject.data('fn') + "]"); 
    var result = _is_data_valid(jQueryObject); 
    if (result.is_requied_filled === false) { 
        button_message.text('入力してください'); 
        button.addClass("disabled"); 
    } else if (result.is_data_ok === false) { 
        button_message.text('修正してください'); 
        button.addClass("disabled"); 
    } else if (result.is_data_ok === true) { 
        button.removeClass("disabled"); 
        button_message.text(''); 
    } 
} 

安定、と、使いやすいの定義次第だと思います。

jQueryはフロントエンドから退場しつつありますが、依然最も手軽で強力で便利で過去の豊富な資産を持つライブラリの一つに変わりなく、テストや拡張機能開発やちょっとしたハックコードの実験とかにはよく使われています。

しかし、フロントエンドは近年大きなパラダイムシフトが起こっており、いわば作り方が変わってしまいました。

安定して使いやすいのは事実なのですが、単なる安定感だけでいえばReactだとかVueだとかも同じく安定しています。使いやすさについてはjQueryで出来ないことがそれらの技術ではできるため、同列には語れないと思います。

jQueryは習熟難易度がReactだとかVueとかに比べるとかなり低く、かつ手軽に導入できて、それでいて非常に強力ですから、私個人としてはjQueryを今も愛していますし逆にReactだとかVueだとかが必ずしもベストとは思いませんが、同時に開発が巨大化してくるとjQueryではキツイと感じる部分(逆にReactとかVueだと楽になる)も出てきますから、このへんの使いやすさは一長一短あると思います。

私の意見としては、短いコードや小規模な開発であればjQueryの手軽さは未だに最高だと思っています。

また、補足なのですが、jQueryは未だに支配的です。

Reactは2021年現在でも約2%程度のサイトでしか採用されておらず、Vue.jsは0.5%程度です。逆にjQueryはマーケットシェアの大部分で採用されています。

ただし、人が多いサイトとか最先端のサイトではReactやVueがよく採用されていますので、今後まだまだ伸びていくと思いますが、(2020年の0.5%から2021年は2%なので成長率は高いです。)なんだかんだで学習コストがそれなりに高いことがネックになっていると思いますので、その前にポストjQuery（かつReactブレイカーなもの）が数年後とかに登場して一気にReact食いしちゃうんじゃないかと思っています。

作るページに相応しい方をやるべきです。

理由は

• Reactで作るべきサイトをjQueryで作るのは苦行となる可能性が高い上に、特段の勉強となるわけでもない。避けるべき
• jQueryが相応しいページにReactを適用するのは手間とのトレードオフが成り立たない。避けるべき

だからです。

歴史的には、高機能なWebページは、まずjQueryで実装されてきたので、Reactの前にjQueryを勉強した方が良いのでは？と考える向きもあるかもしれません。しかしそもそも両者は思想や用途が全く異なります。

ですので、両者は競合するものではありませんし、また一方で勉強したことが他方で活きることは少ないです。

まず、Reactを使うべきページをjQueryで実装する必然性はありません。jQueryはReactに比べて機能が低レベルです。Reactなら簡単に実現出来る機能をjQueryで作れと言われたら、私なら逃げ出します。

さて逆はどうでしょうか。ちょっとした動きをページに追加するような場合にjQueryは便利に使えるのですが、これをReactで実装する意義はあるのでしょうか。やってやれないことは無いと思いますが、得られる効果に対して準備やリリース手順の手間が大きすぎる可能性が高いと思います。

ReactはJSXやTypeScriptという言語を使うのが定番なので、トランスパイラを使ってJavaScriptに変換するという手間が発生します。また動的にDOMを生成するためHTMLに静的にDOMが書かれている場合に比べて初期表示が遅くなります。これに対処するためにサーバーサイドレンダリングという仕組みも提供されていますが、「ちょっとした動きをページに追加したい」だけなのに明らかに大掛かりすぎですよね！

結局は適材適所。初心者と言えどそれを歪めると無用の苦労をすることになり、その上今回の場合は一方を勉強したときに他方の理解が進むようになる要素も少ない。

ですので私の考えは「ページに相応しい方を使う」となります。

なお…

もし質問の意図が「先に勉強した方が良いのはどちらか？」というものであれば、私の回答は「その質問には意味がない」あるいは「どっちからでもいいよ」となります。上の方でも書きましたが、両者は思想や用途が全く異なるのでどちらかを勉強したからと言って他方の理解が進むようなことはないからです。

CSSフレームワークの動向にはあまり詳しくないのですが、そこまで古いという感じではありません。

下記記事も参考にどうぞ。タイトルには「下火」とありますがまだある程度の地位は保っているように見えます。

Bootstrapはすでに下火に——海外の開発者1600人に聞いたCSS開発のいま

個人的には、見た目のオリジナリティを問われるサイトを作ることがあまりないので、Bootstrapを未だにメインで使っています。それほど使いこなしているわけではなく、基本的な入力コンポーネントとレイアウト系の機能をよく使うくらいです。このような目的ではBootstrapはあまり手間をかけずに見やすい画面が作れるため、重宝しています。

さてjQueryですが、こちらは間違いなく古いです。一部の目的での利用は確実に置き換えが進んでいて、特にSPA(Single Page Application)と呼ばれる単一のページ内で多数の機能を持たせる作りのページでは、jQueryの出番は全く無いばかりか、むしろ排除の対象です。

ReactやAngular、Vue.jsなどがSPAを作るためのライブラリです。私はReactをメインに使っているので、以降の記述はReactの知識を基にしています。

jQueryはHTMLのDOMを操作するためのツールの域を出ませんが、ReactやAngularはもっと抽象的なレイヤ、いわばアプリを作るための「フレームワーク」と言える機能を提供します。

ちょっとした動きを加える程度なら今でもjQueryで済ませることはありますが、単一のページに非常に多くの機能を持たせる場合、jQueryで実装しようとするとよっぽどうまく統制しないと簡単に破綻します。

しかしReactは、Facebookが開発しているだけに、SPAをうまく実装することを念頭に設計されているように思います。jQueryでSPAを上手に実装するには、非常に多くの決め事が必要になってきますが、Reactはそれらの決め事を内包しており、非常に手間が減ります。

ただし、jQueryは古いのですが不要になったわけではありません。実績やノウハウが大量に積み上がっている、いわゆる「枯れた」ライブラリであり、安心して使えるライブラリです。

例えば「２度押しを防止するためにsubmitボタンが押された時にこのボタンを押せないようにする」と言ったちょっとした制御を入れるには、非常に便利に使えます。

目的に応じた道具の選択肢が増えた、ということですね。

色々なものが使いこなせて問題が発生することは有りません。ただ、「フロントエンジニアとしてキャリアアップ」が何を目指すかによって大きく異なります。どこかに就職するならば、そこの開発状況に準じた技術習得は就職面で役に立つと思います。

ただフロントエンジニアに最も必要なのはインターフェイス設計です。私は長年（約 20 年）Web で業務システムの開発を手掛けて来ましたが、最も大変なのは利用者の仕事の流れを理解して、端末を利用している局面でどんな事態が発生するのかとか、データ入力の入口情報は何かとか、何処迄精度の高い情報がエントリー時に揃うのかとか、画面を開いた時に利用者が最も閲覧したい項目が何で、画面上の配置状況を如何すれば情報をピックアップしやすいか、エントリー時のカーソルの移動順序は如何すれば使いやすいかと言った事が重要になると確信しています。実際インターフェイスを絶賛してくれるお客がいます。

コード入力に関しても参照用のヘルプ（一覧）を用意して検索ができると同時に、場合によってはそこから新たなデータの追加を可能にする（元の画面を閉じずに作業が継続できる）機能を追加するとか、されにその登録用画面からさらなる参照画面を開ける様にする等の機能を提供できるべきですが、場合によっては、顧客ヘルプ → 顧客登録 → 関連企業ヘルプ（顧客ヘルプ）と言った具合に多重で同じプログラムを呼び出しても問題を生じさせない様な仕掛けが必要となります。私は React.js も Vue.js も知りませんが、ここで述べている様な事が簡単にできないのならばフロントエンドを語るレベルに達しているとは思えません。業務系 Web システムではこれ以外にも山の様に必要な機能が有ります。

整理するとフロントエンドで最も大事なのは、提供先の業務の理解と利用者の動線（端末を使っている時におかれている状況）の理解、業務スイッチングの頻度と復帰までの時間（タイムアウトで入力途中の画面が消えると泣きたくなります）の把握、権限や制限（締関連等）を考慮した画面の制御、ログインによる利用者メニューやボタン・項目の表示やロック等がどうあるべきかを顧客に提案できる力で、決して React.js や Vue.js の技術を顧客は求めていません。提供するものを作るに有用な道具を選択するので有って、まず道具ありきの考え方はプログラミングで何をしようとしているかという本質を踏み外していることを理解すべきです。

ついさっき学んだことですが、「イケてる」かどうより「動作要件を確実に満たしているか」の方が遥かに重要です。私はついイケてるかどうかを追いがちなので自分にも戒めて言い聞かせていますが、どのみち制作段階で「イケてるからこれにしよう」ということにはならないのでなんとかなってます。説明つきであれば一読の価値はあるかもしれませんが、それでも悩むべきものは別にあると思います。

まあ求められてるものが「動かなくていいからイケてるやつ」だと違うと思いますがそんなものまずないですしね。イケてるなんて言うような単語で流行りを強調する記事は大体制作全体を見ずに物を語ってるので結構地雷だったりします。

私も社内でデザイナーの方に「jQuery 使わないのがイケてんの？なにそれ？」と聞かれました。普段技術トークをしない方だったので、余程その主張が流行ってて目についたんだなと思いました。まあ確かに jQuery 不要のプラグインは少し増えたきはします。

語順かき混ぜて『CSS でイケる（出来る）デザインで jQuery (Javascript) を使うのはイケてない（良くない）から、CSS だけで済ますべき』というのであればおおむね同感です。

まあそれにしたってそれが良いか悪いかなんてその場面じゃないとわからないです。イベントの絡んだ複雑なアニメーションを作るのであれば、一つの目的のためにわざわざ CSS と JS で二つのコードに分けて管理するよりも、JS コード一箇所にまとめた書いた方が記述も管理もスマートということもあると思います。
Javascript で書けるならそれのほうが処理の負担も軽いし自由が効くかもしれませんし、jQuery のほうが慣れてて且つそれでも問題なく動くのであれば、それでも支障ありませんし。

私もそういった記事に気を取られて時間を無駄にしないように気をつけようと思います。

まず、重松 卓馬さんが書かれている回答の一文を理由としています。

問題なのはjQuery ではなく、当時jQueryが大人気だった時に、jQueryでしかJSを書けない人たちがわんさかと大量に生産されてしまったことが大問題でした。
$(function(){ });の意味すらわからずに、同じファイルに何個も$(function(){ });を書いていたり…

自分もこれをやったことがあります。
いつまでたっても理解が深まらないからと、JavaScriptの方に徐々に移行していきました。

jQueryの大きなメリットは敷居の低さですね。より多くの人間に構築や修正依頼できるはずです。コードの文字数もシンプルです。
しかし、他人に任せた結果、ページ内に複数のjQueryライブラリ（バージョン違い）が埋め込まれる事態になりました。

サイトはCMSで構築しており、パーツ単位で独立したファイル管理となっています。
そのファイル内で動的処理が必要だからと、複数の担当者が各々jQueryを読みこんだのでしょう。
（単にDOM要素取得でしか使ってないコードもありました）

ファイル納品後に修正指示を出しても、簡単な修正すら難航する始末でした。どのjQueryがどの記述に作用しているのか、それすら分からない状態のようでした。

そのような理由で、徐々にjQueryを使用しない雰囲気に変えていきました。
現在はjavascriptで構築するか、理解の低い人間に任せないようにしています。
一種の選別目的としての活用ですね。
（単独のランディングページとかなら全く問題ないですが）

あとは実行速度の面から。
どうしてもjQueryは非同期で読み込みますし、処理によってはオーバーヘッドが発生しますし…。

グローバルナビゲーションや、重要度の低いエリア（関連ページ一覧のような）など、DOM解析時間を与えたくない要素に関しては、ボタンクリックや監視に応じてHTMLレンダリングさせています。

ページを少しでも早く表示させたいため、基幹部分でjQueryを活用することはなくなりました。

Golangです。ジェネリックスと例外処理の無い安定の使いにくさのGolangですが、今月(2021年6月)のTiobeのランキングで、とうとうランクを20位にまで落としました。Googleのブランド力と宣伝力で今まで多くの開発者やCTOたちを騙し続けてきたGolangですが、いよいよ化けの皮が剥がれ、開発者やCTOたちもGo言語自体の大きな欠点を誠実に真正面から受け止め始めているのだと思います。

ちなみにこちらが今月(2021年6月)のGoogle Trendsの結果です。着々と世界規模でGoの人気は下がっています。

シンプル、そして汎用プログラミング言語(General Purpose Programming Language)と謳っておきながら、実際はシンプルすぎ（機能が少なすぎ）、そして専用プログラミング言語(Specific Purpose Programming Language)だったGoはもはや一部のマニアにしか使われないのではないでしょうか。

Java、Ruby、PHPなどなどいろいろな言語がオワコンだと言われていますが、意外にもGoが一番最初に消えそうです。Godying。

jQueryを使う機会は着々と減ってきています。

まず、jQueryでやっていた事は、新しいブラウザなら標準的なAPIで事足りますので、どうしても使いたいjQueryプラグインでも無い限りは特にjQueryを使う必要がなくなってきています。

You Might Not Need jQuery

また、「イケてるデザインはCSSだけで済ます」という話からすると、おそらくjQuery.animate等を使って少し凝ったインタラクションを仕込む事などを想定されてるのかなと思いますが、近年のWeb環境下ですと、JS側でアニメーションの類を仕込むのは、大抵の場合よい結果になりません。

今はスマホにPCと様々な画面幅/操作方法のデバイスでWebサイトが表示されます。大きな画面、小さな画面、マウス操作用、タッチパネル用など、様々なデバイス特性に合ったUI/インタラクションが要求されます。

JS側でそれらを全て判別して分岐させつつ、さらにアニメーションまで仕込もうとすると、見通しの悪くメンテナンス性の低いコードになりやすいです。

CSSであればメディアクエリ等を使ってデバイス別の表示の切り分けは行いやすいですし、また描画のスムーズさの点でも多くの場合でCSSのほうがよい結果になります。

さらにCSSを書く人はデザイナーに近しい人が多いので、CSSの側でインタラクションを制御するほうが、デザイナー的なセンスの活きた良い仕上がりになりやすい、というのもあります。

そんなこんなで、jQueryを使うにしても、JSでは状態に応じたclassのつけ外しや通信などJS側でしかできない事に徹し、アニメーション等は極力CSS側で行うのがお勧めです。