jQuery v4.0 ベータ版

 (blog.jquery.com)
1 ポイント 投稿者 GN⁺ 2024-02-08 | 1件のコメント | WhatsAppで共有
  • IE 10 以下のサポートが削除され、Edge Legacy、iOS <11、Firefox <65、Android Browser のサポートも終了
  • 複数のバージョンにわたって非推奨（deprecation）となっていた API が削除: jQuery.cssNumber、jQuery.cssProps、jQuery.isArray、jQuery.parseJSON、jQuery.nodeName、jQuery.isFunction、jQuery.isWindow、jQuery.camelCase、jQuery.type、jQuery.now、jQuery.isNumeric、jQuery.trim、jQuery.fx.interval
  • jQuery プロトタイプの内部用 Array メソッドだった push、sort、splice が削除され、これらのメソッドに依存するプラグインに影響する可能性
  • focusout、blur、focusin、focus 関連のイベント順序における jQuery の従来のオーバーライドが削除され、IE を除くブラウザは現在の W3C 順序である blur → focusout → focus → focusin に従う
  • jQuery.ajax が バイナリデータと FormData をサポートし、従来のように不明なデータ型として扱って文字列に変換していた動作が自動処理に変更
  • dataType: "json" とコールバックが一緒に指定された場合に JSONP リクエストへ自動昇格していた jQuery.ajax の動作が削除
  • jQuery のソースが AMD から ES modules に移行し、パッケージングツールが RequireJS から Rollup に変更
  • Trusted Types のサポートが追加され、TrustedHTML でラップした HTML を、require-trusted-types-for CSP ディレクティブに違反せずに jQuery の操作メソッドの入力として使用可能
  • ほとんどの非同期スクリプトリクエストが <script> タグを使用するようになり、インラインスクリプト使用による CSP エラーを避けるように変更
  • slim ビルドでは Deferreds と Callbacks が削除され、gzip 基準で 20k bytes 未満となり、通常ビルドより約 8k gzipped bytes 小さい
  • IE11 サポートが必要な場合は、slim ビルドではなく main ビルドを使うか、native Promises のポリフィルを追加する構成が推奨される
  • 正式リリース前に包括的なアップグレードガイドが公開される予定で、jQuery Migrate plugin が移行支援用として用意される予定
  • ベータリリースは jQuery CDN と npm で提供され、サードパーティ CDN はベータをホストせず、4.0.0 正式リリースを後日ホストする予定

関連記事

1件のコメント

 
GN⁺ 2024-02-08
Hacker News の意見

  • 2024年以降も jQuery を動かし続ける力が何なのか気になるなら、WordPress が今なお Web の 1/3 以上を占めており、ほとんどのインストール環境と無数のプラグインが jQuery に大きく依存していることを思い出すべき
    廃止予定の API や関数の削除が進むのは良いことで、jQuery は今後も数年間、Web 上で支配的な存在であり続ける可能性が高い

    • それに jQuery は素晴らしい
      この15年ほど、業界は過度に複雑で派手な JavaScript フレームワークにのめり込んできたが、動的に生成されたフォームに動的バインディングをかけ、エラー状態を処理し、Ajax 呼び出しを数回行う程度が、Web ページの99%に必要な JavaScript のすべてであり、それ以外は過剰なことが多い
      業界は React の複雑さから離れ、htmx、Phoenix LiveView、Ruby on Rails Turbo、そして単に jQuery のようなシンプルさへ移っていくことになると思う
    • 誰が何と言おうと、jQuery は今なお強力で重要であり、影響力が大きい
      すべてのソフトウェアから jQuery を取り除けば、インターネット上のかなりの数の Web サイトが止まるだろう
    • WordPress だけの問題ではない
      以前勤めていた会社は、エンタープライズ向け SaaS 製品を数万行の jQuery コードで運用していた
      本当に必要にならない限り、最新の JS フレームワークで書き直すことは起きないだろう。大半は10年以上前に特定顧客の要件に合わせて書かれたコードであり、最新フレームワークを使えば採用に役立つという理屈も通らない。会社はフロントエンドエンジニアに7.5万〜9万ドルしか支払っておらず、離職率も低く、現在のエンジニアの大半は5年以上在籍している
      何より、現在のスタックはうまく動いており、古くからの顧客も満足している。ソフトウェアエンジニアリングのかなりの部分は、Bay Area や Seattle のようなビッグテックの中心地よりも生活費がはるかに低い都市にある、こうした退屈なビジネスで行われている
    • WordPress 開発者はテック業界の配管工のようなもの
      派手ではないが、必要としている人があまりに多いので、かなり稼げる
      いつか最新トレンドを追うビッグテック系スタートアップの世界から引退するなら、まっとうに稼ぎながら WordPress サイトを作り、毎日午後3時に仕事を切り上げたい
    • 少し前に HN に投稿しようとしてやめたのだが、DOM メンバーと抽象クラスのインスタンスが相互に置き換えて使えるイベントをトリガーできる、優れたイベントチェーン処理／バブリングモデルを今も見つけられていない
      あちこちで自前のイベントディスパッチャを作ってきたが、jQuery はこの部分をきちんとこなしている。今でもほぼイベント処理のためだけに jQuery を使っているが、あまりに便利なので、ほぼすべてのクライアント側プロジェクトに入れている
      聞きたかったのは、$(window).trigger('click') と $(myClassInstance).trigger('myCustomEvent',{data}) を同じ API で、非同期リスニングまで扱える軽量ライブラリを知っている人がいるか、ということだった
      fetch() と CSS セレクタの台頭のおかげで、今では jQuery の残りの部分はなくてもよさそうだが、わざわざ車輪を再発明する必要があるのかと思う。クラスインスタンスがイベントをディスパッチするのはコードスメルだと言う前に、リアクティブフレームワークをゼロから作るには必ず必要になる
      例えば、私の基本コンポーネントクラスは、自分を含む画面で発生する特定のカスタム resize イベントを購読し、その画面はスクロールされず内部の再配置が必要なコンポーネントにだけイベントを送る。画面クラスは window.resize を購読するが、レイアウトが厄介なときだけディスパッチする。すべてのコンポーネントに個別の DOM resize リスナーを window に付けるのは筋が通らない

  • HN では jQuery を単なる DOM 選択ライブラリと見なす人が継続的に見られるので驚く
    実際には広くサポートされ、非常に安定したツール群であり、DOM 選択だけでなく属性操作、Ajax リクエスト、イベント処理、アニメーション、汎用ユーティリティ関数まで提供している
    さらに、jQuery を置き換えるネイティブ機能があったとしても、API が同じくらい流麗とは限らない
    サーバー側 HTML の上に少し機能を足すだけでよく、完全な JS UI フレームワークまでは不要な作業なら、jQuery は安定していて信頼でき、ブラウザ間互換のある依存関係として、小さな代償にすぎない

    • 数年前に jQuery を捨てて素の JavaScript に移ってから、一度も振り返っていない
      ネイティブ JS には jQuery が持っていたものがすべてあり、たいてい管理が不十分で半端にしか完成していないプラグインの山がないだけだ。そうしたプラグインは普通、自分たちがやろうとしていることだけをやり、それ以外はあまり助けにならない
      素のセレクタのほうが冗長ではあるが、まともなコードエディタなら入力速度は同じくらいにしてくれる。議論したいわけではないが、なぜ今でもそれほど多くの人が jQuery を使っているのか、正直よく理解できない
      https://youmightnotneedjquery.com/
    • HN の投稿者層を考えると、それほど驚くことではない
      DOM 選択を少し超えるものが必要になると、その時々で流行している大型 JS フレームワークをすぐ手に取る人が多く、ずっとそうしてきたからだ
    • 「jQuery をただの DOM 選択ライブラリだと見ている人たち」と言いながら、その後に選択とネイティブ関数を列挙している
    • プロジェクトに jQuery を入れるほうがはるかに簡単
      ビルドツールと、それに付随する厄介ごとが必要ない。React でもそうできなくはないが、提供される機能は比較対象にならない

  • 多くの人が jQuery の最後の痕跡を積極的に取り除こうとしている世界で、今いったい誰が jQuery で積極的に開発しているのか、本気で気になる
    かつて jQuery でやっていたことの大半は、今ではブラウザに入っていて、querySelectorAll が最も強力な例だと思う

    • 年を取ったし、新しい技術にあまりワクワクしなくなったので、ネイティブ JS の promise、await、async より $.ajax() のほうがはるかに単純に感じる
      慣れようとして小さな個人プロジェクトいくつかでは素の JS も使ってみたが、自分にとっては $.ajax() で処理するのが筋肉記憶のようにすぐできるやり方だ
      それに、私が DOM 操作用に書くコードを実際に使う人は20人くらいだと思う。私は UI 担当ではなくバックエンド担当なのだが、やってくれる人がいないのでフロントエンドも書いているだけだ
    • 昨年の Stack Overflow 調査によると、jQuery は3番目に人気だった
      https://survey.stackoverflow.co/2023/#section-most-popular-t...
    • ついさっき、ある会社で React の最後の痕跡をかなり取り除いて HTMX に置き換える仕事をした
      個人的には、HTMX はある意味で jQuery の精神的後継者だと思う
    • 私も jQuery をなくそうと積極的に取り組んでいるが、人々はそのツールに慣れていて、書き直すにはコストがかかるため、なくすほどの意志やビジネス上の根拠が足りないのだと思う
      新規プロジェクトを jQuery で始めるのは疑問だが、素の JavaScript のやり方よりも jQuery 流で処理することにはるかに慣れている開発者は確かにいる
    • モダンなツールチェーンを嫌う個人開発者や小規模チームの開発者が使っている
      良い例として levelsio がある: https://twitter.com/levelsio/status/1750175827197567165
      自分もそちら側で、今も jQuery を使っている
      現在の SaaS は UI コードが多くない拡張機能の https://www.snipcss.com で、次の SaaS は UI がかなりある ChatGPT ベースの Web 自動化拡張機能になる予定だ。どちらも jQuery を使っている
      querySelectorAll を使う素の JS に行かない主な理由は、イベントを付ける方法が気に入っていて、特に親に付けて動的に追加された子要素を対象にできること、関数チェーンが良いこと、素の JS よりコードが少なくて済むことだ

  • 素晴らしい。ただ私は 4.0 を待ちすぎた結果、いくつかの重要な違いがある独自の jQuery を作ってしまった
    アニメーション、トゥイーン、タイムラインは jQuery のカスタムシステムの代わりに素の CSS を使い、単一要素とリストを透過的に扱い、インライン方式を採っている

    • こういうモダンで軽量な jQuery 代替があるべきだとずっと思っていた。よくできているし、構文も気に入った
      私も似たものを実装していたが、インラインイベントと標準の配列メソッド以上のものを含んでいる [0]
      surreal と関連プロジェクト css-scope-inline で、振る舞いの局所性（locality of behavior）がどのように実装されているのかを説明する記事やスクリーンキャストがあるとうれしい。長期的にメンテし、自分のプロジェクトにも入れられるよう理解したい
      Web に対する哲学についても話してみたい。いくつかは考えがかなり合いそうだ
      [0] https://hyperspace.so/All.js.png

  • 2008年ごろ、ジュニアだった頃に戻ったような気分だ。プロジェクトに jQuery を追加しようとテックリードと激しく議論したことがあった
    彼の論理は、縮小後のライブラリサイズである 40KB がページ読み込み時間にとって大きすぎる負担だというものだった
    それから Ajax 呼び出しを自前で書き、複数ブラウザ対応をテストするのに丸一週間を費やしたが、結局 Internet Explorer 5 で動かすことには失敗した
    あの頃の jQuery は本当に多くの厄介ごとを解決してくれたし、最終的に彼はプロジェクトにライブラリを追加した

    • 人々はこれをよく忘れるが、昔のブラウザは互いに大きく異なっていて、jQuery はその点でコードベースを支える唯一合理的な 接着剤だった
    • 良い戦いをしたテックリードに拍手を送る

  • jQuery チーム、よくやった。jQuery は永遠に好きでいそうだ
    ただ 仕事を終わらせてくれるツールだ

    • Bootstrap、PHP、JQuery、WP は実際に成果物を作る人たちのスタックだ

  • ブラウザの DOM 選択サポートがずっと良くなった今、2024年にどうして jQuery を使うのか気になる
    けなすつもりはなく、今も開発が続いているのは素晴らしいと思うが、ユースケースが何なのか混乱している

    • document.querySelector() がサポートしていない、かなり便利なセレクタがいくつもある
      例えば :selected、:checked のようなものがあり、ほかにもいくつかあって実際に何度か遭遇した
      全体として DOM API は、良い API 設計に対する私の感覚の大半に反している。jQuery API にも不満はあるが、はるかにましで、読み書きの流れがずっと自然だ
    • レガシープロジェクトのせいではないだろうか
      約15年ものの古い .NET Web アプリを保守していて、jQuery に戻った。Web Components のようなもっとモダンなもので全体をリファクタリングしたり書き直したりする夢は良いが、実際には絶対にやらないだろう
    • 推測するに、便利な API と巨大なエコシステムのためだ
    • 管理画面では jQuery が好きだ
      社内スタッフ20人だけが見るページなら、jQuery は十分軽く、CDN からそのまま読み込めて、トランスパイルは一切不要で、基本的に必要なことを全部こなしてくれる

  • 参考までに、私たちは ローコードプラットフォーム全体のドラッグ＆ドロップエディタを jQuery で作った
    エディタ、すべてのコントロール、つまり UI コンポーネントが含まれ、言うまでもなく最終的に生成されるコードも素の jQuery だ
    ただ、大企業の役員たちは営業エンジニアに、なぜ React や Angular などではないのかとよく尋ねる
    だから今でも jQuery がこれほど関係性を持っていると読めて本当にうれしいし、共同創業者兼 CTO がスタックを移行しようとせず、この選択を支持し続けてくれていることをうれしく思う

  • jQueryが初めて登場した頃を覚えている
    同僚を説得しようと「Don’t Fear the $」という社内発表を開き、jQueryが提供するメリットを説明した

  • jQueryの全盛期、私たちがMootoolsの代替として使っていた頃を覚えている
    多くの人がReactからHTMXへ移っているので、一周回ってWebがただの素のjQueryも使う姿を見ることになるかもしれない

    • 似たような時代を経験したが、あの混沌が恋しいわけではない
      アクセシビリティ、モバイル対応、リアルタイム更新、ビジュアライゼーション、さらにいくつかのPWA機能まで備えたモダンなアプリをjQueryだけで作ると考えると、本当に不快に聞こえる
      HTMXの過熱も現実にぶつかる時を待っているところだ。DSLのような偽の属性でアプリをプログラミングするやり方には、すぐ飽きそうだ
    • HTMXはMootoolsを思い出させる
      小さく、非常に特化したJSライブラリだ
    • HTMXは$().load()みたいだ
    • 「多くの」は少し大げさかもしれない