jQuery v4.0 bản beta
(blog.jquery.com)- Đã loại bỏ hỗ trợ IE 10 trở xuống, đồng thời ngừng hỗ trợ Edge Legacy, iOS <11, Firefox <65 và Android Browser
- Loại bỏ các API đã ở trạng thái ngừng khuyến nghị sử dụng (deprecation) qua nhiều phiên bản:
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 - Đã loại bỏ
push,sort,splice, các phương thức Array dùng nội bộ trên prototype của jQuery, nên có thể ảnh hưởng đến các plugin phụ thuộc vào những phương thức này - Với thứ tự sự kiện liên quan đến
focusout,blur,focusin,focus, phần override trước đây của jQuery đã bị loại bỏ; các trình duyệt ngoại trừ IE sẽ tuân theo thứ tự W3C hiện tại làblur→focusout→focus→focusin jQuery.ajaxhỗ trợ dữ liệu nhị phân vàFormData; hành vi trước đây coi đây là kiểu dữ liệu không xác định rồi chuyển thành chuỗi đã được đổi sang xử lý tự động- Đã loại bỏ hành vi của
jQuery.ajaxtừng tự động nâng cấp thành yêu cầu JSONP khidataType: "json"được cung cấp cùng callback - Mã nguồn jQuery đã được di trú từ AMD sang ES modules, và công cụ đóng gói được chuyển từ RequireJS sang Rollup
- Đã thêm hỗ trợ Trusted Types, cho phép dùng HTML được bọc bằng TrustedHTML làm đầu vào cho các phương thức thao tác của jQuery mà không vi phạm chỉ thị CSP
require-trusted-types-for - Hầu hết các yêu cầu script bất đồng bộ đã được đổi sang dùng thẻ
<script>, nhằm tránh lỗi CSP do dùng inline script - Deferreds và Callbacks đã bị loại bỏ khỏi bản slim, đưa kích thước xuống dưới 20k bytes theo gzip và nhỏ hơn bản thường khoảng 8k gzipped bytes
- Nếu cần hỗ trợ IE11, khuyến nghị dùng bản main thay vì bản slim, hoặc thêm polyfill native Promises
- Trước khi phát hành chính thức, một hướng dẫn nâng cấp tổng hợp sẽ được công bố; jQuery Migrate plugin sẽ được chuẩn bị để hỗ trợ di trú
- Bản beta được cung cấp trên jQuery CDN và npm; các CDN bên thứ ba sẽ không host bản beta mà sẽ host bản phát hành chính thức 4.0.0 sau này
1 bình luận
Ý kiến trên Hacker News
Nếu muốn biết điều gì vẫn đang giữ cho jQuery vận hành sau năm 2024, hãy nhớ rằng WordPress vẫn chiếm hơn 1/3 web và phần lớn các bản cài đặt cùng vô số plugin vẫn phụ thuộc rất nhiều vào jQuery
Việc loại bỏ dần các API hoặc hàm sắp bị khai tử là tín hiệu tốt, và jQuery nhiều khả năng vẫn sẽ tiếp tục hiện diện áp đảo trên web trong vài năm tới
Khoảng 15 năm qua, ngành này đã quá sa đà vào các framework JavaScript phức tạp và hào nhoáng, nhưng với 99% trang web, toàn bộ JavaScript cần thiết thường chỉ là gắn binding động cho các form được tạo động, xử lý trạng thái lỗi và thực hiện vài lệnh gọi Ajax; phần còn lại thường là quá mức cần thiết
Có vẻ ngành sẽ rời khỏi sự phức tạp của React để quay về sự đơn giản như htmx, Phoenix LiveView, Ruby on Rails Turbo, và cả jQuery đơn thuần
Nếu loại bỏ jQuery khỏi mọi phần mềm, một phần đáng kể các website trên internet sẽ ngừng hoạt động
Công ty cũ của tôi từng vận hành một sản phẩm SaaS doanh nghiệp bằng hàng chục nghìn dòng mã jQuery
Trừ khi thực sự bắt buộc, họ sẽ không viết lại bằng framework JS hiện đại. Phần lớn mã đó được viết hơn 10 năm trước để đáp ứng yêu cầu của các khách hàng cụ thể, và lập luận rằng dùng framework mới sẽ giúp tuyển dụng tốt hơn cũng không thuyết phục. Công ty chỉ trả cho kỹ sư frontend khoảng 75.000~90.000 USD, tỷ lệ nghỉ việc thấp, và đa số kỹ sư hiện tại đã làm hơn 5 năm
Quan trọng hơn, stack hiện tại hoạt động tốt và các khách hàng lâu năm cũng hài lòng. Một phần rất lớn của kỹ thuật phần mềm diễn ra trong những doanh nghiệp nhàm chán ở các thành phố có chi phí sinh hoạt thấp hơn rất nhiều so với các trung tâm big tech như Bay Area hay Seattle
Không hào nhoáng, nhưng vì nhu cầu rất lớn nên vẫn có thể kiếm rất nhiều tiền
Nếu một ngày nào đó tôi rời khỏi thế giới startup big tech luôn chạy theo xu hướng, tôi muốn kiếm tiền một cách tử tế bằng cách làm website WordPress và kết thúc công việc mỗi ngày lúc 3 giờ chiều
Tôi đã tự viết event dispatcher ở nhiều nơi, nhưng jQuery làm phần này rất đúng. Đến giờ tôi gần như chỉ dùng jQuery cho xử lý sự kiện, nhưng nó quá hữu ích nên hầu như tôi vẫn đưa vào mọi dự án phía client
Điều tôi muốn hỏi là có ai biết thư viện nhẹ nào có thể xử lý cả lắng nghe bất đồng bộ bằng cùng một API cho
$(window).trigger('click')và$(myClassInstance).trigger('myCustomEvent',{data})hay khôngNhờ
fetch()và sự phổ biến của CSS selector, có lẽ giờ có thể sống mà không cần phần còn lại của jQuery, nhưng tôi vẫn nghĩ không cần phải phát minh lại bánh xe. Trước khi ai đó nói việc để class instance dispatch event là code smell, thì nếu muốn tự xây dựng framework phản ứng từ đầu, đó là điều bắt buộcVí dụ, lớp component cơ bản của tôi lắng nghe một sự kiện resize tùy biến cụ thể phát sinh từ màn hình chứa nó, và màn hình đó chỉ gửi sự kiện cho những component không cuộn mà cần tự sắp xếp lại bên trong. Lớp màn hình lắng nghe
window.resizenhưng chỉ dispatch khi bố cục thực sự gặp vấn đề. Việc gắn listener resize DOM riêng cho từng component lênwindowlà vô lýTôi ngạc nhiên khi trên HN vẫn liên tục có người xem jQuery chỉ là một thư viện chọn DOM đơn thuần
Thực ra, đó là một bộ công cụ được hỗ trợ rộng rãi và cực kỳ ổn định, không chỉ chọn DOM mà còn cung cấp thao tác thuộc tính, yêu cầu Ajax, xử lý sự kiện, animation và các hàm tiện ích đa dụng
Hơn nữa, ngay cả khi có tính năng native thay thế jQuery thì API cũng không mượt mà tương đương
Nếu bạn chỉ cần bổ sung một chút chức năng lên trên HTML phía server mà không cần đến cả một framework UI JavaScript hoàn chỉnh, thì jQuery là một dependency ổn định, đáng tin cậy, tương thích đa trình duyệt với cái giá rất nhỏ
Native JS có mọi thứ mà jQuery có, ngoại trừ đống plugin lộn xộn thường được bảo trì kém và dở dang một nửa. Những plugin đó thường chỉ làm đúng thứ chúng định làm và ngoài ra chẳng giúp được bao nhiêu
Selector thuần thì dài dòng hơn thật, nhưng với hầu hết trình soạn thảo mã, tốc độ gõ về cơ bản là như nhau. Không phải muốn tranh cãi, nhưng tôi thật sự không hiểu vì sao vẫn còn nhiều người dùng jQuery đến vậy
https://youmightnotneedjquery.com/
Hễ cần làm gì hơn một chút so với chọn DOM là nhiều người lập tức cầm ngay framework JS cỡ lớn đang thịnh hành lúc đó, và họ vẫn luôn làm như vậy
Không cần công cụ build và những phiền toái đi kèm. React cũng có thể dùng kiểu đó, nhưng chức năng mà nó cung cấp thì không cùng loại để so sánh
Trong một thế giới nơi nhiều người đang tích cực cố gắng xóa bỏ những dấu vết cuối cùng của jQuery, tôi thật sự tò mò không biết bây giờ còn ai đang chủ động phát triển bằng jQuery nữa
Phần lớn những gì trước đây làm bằng jQuery giờ đã có sẵn trong trình duyệt, và tôi nghĩ
querySelectorAlllà ví dụ mạnh mẽ nhất$.ajax()đơn giản hơn nhiều so với promise,await,asynccủa JS thuầnTôi cũng đã thử dùng JS thuần trong vài dự án cá nhân nhỏ để tập quen, nhưng với tôi xử lý bằng
$.ajax()là kiểu làm đến mức thành phản xạ cơ bắp rồiHơn nữa, số người thực sự dùng đoạn mã thao tác DOM mà tôi viết chắc chỉ khoảng 20 người. Tôi không phải người phụ trách UI mà là backend, chỉ là phải viết cả frontend vì không có ai khác làm
https://survey.stackoverflow.co/2023/#section-most-popular-t...
Cá nhân tôi thấy HTMX, ở một khía cạnh nào đó, là người kế thừa tinh thần của jQuery
Việc bắt đầu dự án mới bằng jQuery thì đáng nghi thật, nhưng chắc chắn có những lập trình viên quen xử lý theo kiểu jQuery hơn nhiều so với cách JavaScript thuần
Một ví dụ hay là levelsio: https://twitter.com/levelsio/status/1750175827197567165
Tôi cũng thuộc nhóm đó và vẫn dùng jQuery
SaaS hiện tại của tôi là https://www.snipcss.com, một extension không có quá nhiều mã UI, còn SaaS tiếp theo sẽ là một extension tự động hóa web dựa trên ChatGPT với lượng UI kha khá. Cả hai đều dùng jQuery
Lý do chính tôi chưa chuyển sang JS thuần với
querySelectorAlllà vì tôi thích cách gắn sự kiện, đặc biệt là có thể gắn vào phần tử cha để nhắm đến các phần tử con được thêm động, cộng với chaining hàm tiện và lượng mã ít hơn JS thuầnTuyệt vời. Chỉ là tôi đã đợi 4.0 quá lâu nên cuối cùng tự làm một bản jQuery của riêng mình với vài khác biệt cốt lõi
Animation, tween và timeline dùng CSS thuần thay cho hệ thống tùy chỉnh của jQuery, xử lý minh bạch cả phần tử đơn lẻ lẫn danh sách, và chọn cách làm inline
Tôi cũng đang làm thứ gì đó tương tự, có cả inline event và hơn cả các phương thức mảng tiêu chuẩn [0]
Sẽ rất hay nếu có bài viết hoặc screencast giải thích cách surreal và dự án đi kèm css-scope-inline hiện thực hóa locality of behavior. Tôi muốn hiểu để có thể duy trì lâu dài và đưa vào dự án của mình
Tôi cũng muốn bàn về triết lý web. Có vẻ ở vài điểm chúng ta sẽ khá hợp ý nhau
[0] https://hyperspace.so/All.js.png
Cảm giác như quay lại thời còn là junior khoảng năm 2008. Tôi từng tranh luận khá căng với tech lead về việc thêm jQuery vào dự án
Lập luận của anh ấy là kích thước thư viện đã nén 40KB là gánh nặng quá lớn cho thời gian tải trang
Rồi sau đó chúng tôi mất trọn một tuần để tự viết các lời gọi Ajax và kiểm thử hỗ trợ đa trình duyệt, cuối cùng vẫn không thể làm cho nó chạy được trên Internet Explorer 5
Thời đó jQuery thực sự giải quyết rất nhiều cơn đau đầu, và cuối cùng anh ấy cũng thêm thư viện này vào dự án
Đội ngũ jQuery làm tốt lắm. Có lẽ tôi sẽ thích jQuery mãi mãi
Nó đúng là công cụ giúp hoàn thành công việc
Giờ khi trình duyệt đã hỗ trợ chọn DOM tốt hơn nhiều, tôi tò mò vì sao năm 2024 người ta vẫn dùng jQuery
Không phải để chê bai, và tôi cũng thấy thật tuyệt khi nó vẫn còn được phát triển, nhưng tôi hơi khó hình dung use case là gì
document.querySelector()không hỗ trợVí dụ như
:selected,:checkedvà còn vài cái khác nữa mà tôi từng gặp vài lầnNhìn chung, DOM API đi ngược với khá nhiều cảm nhận của tôi về thiết kế API tốt. Tôi cũng có điểm không hài lòng với API của jQuery, nhưng nó vẫn tốt hơn nhiều, và luồng đọc-ghi tự nhiên hơn hẳn
Tôi đang bảo trì một ứng dụng web .NET đã khoảng 15 năm tuổi và nó chạy bằng jQuery. Mơ về một cuộc đại tu hay viết lại toàn bộ bằng thứ hiện đại hơn như Web Components thì cũng hay đấy, nhưng thực tế là sẽ không bao giờ làm
Nếu đó là trang chỉ khoảng 20 nhân viên nội bộ nhìn thấy, thì jQuery đủ nhẹ, có thể tải ngay từ CDN, không cần transpile gì cả, và về cơ bản xử lý được mọi thứ cần thiết
Nhân tiện, chúng tôi đã xây dựng toàn bộ trình biên tập kéo-thả của một nền tảng low-code bằng jQuery
Bao gồm editor, mọi control, tức các UI component, và dĩ nhiên cả đoạn mã được sinh ra cuối cùng cũng là jQuery thuần
Nhưng các lãnh đạo cấp cao ở doanh nghiệp lớn lại thường hỏi kỹ sư bán hàng vì sao không phải React hay Angular các kiểu
Vì vậy đọc được rằng jQuery vẫn còn phù hợp đến vậy thật sự làm tôi rất vui, và tôi cũng mừng vì đồng sáng lập kiêm CTO vẫn tiếp tục ủng hộ lựa chọn này thay vì cố chuyển stack
Vẫn nhớ thời jQuery mới ra mắt
Để thuyết phục các đồng nghiệp, tôi đã tổ chức một buổi trình bày nội bộ với tiêu đề “Don’t Fear the $” và giải thích những ưu điểm mà jQuery mang lại
Vẫn nhớ thời kỳ hoàng kim của jQuery, khi chúng tôi dùng nó để thay thế Mootools
Giờ nhiều người đang chuyển từ React sang HTMX, nên biết đâu sau một vòng quay, chúng ta lại thấy web quay về dùng cả jQuery thuần túy
Nghĩ đến việc xây một ứng dụng hiện đại có đủ khả năng truy cập, hỗ trợ di động, cập nhật thời gian thực, trực quan hóa, và cả một vài tính năng PWA chỉ bằng jQuery thôi đã thấy thật kinh khủng
Cơn sốt HTMX cũng đang chờ ngày va vào thực tế. Cách lập trình ứng dụng bằng những thuộc tính giả kiểu DSL như thế có lẽ sẽ nhanh chóng khiến người ta chán
Đó là một thư viện JS nhỏ và rất chuyên biệt
$().load()