jQuery v4.0 เวอร์ชันเบต้า

 (blog.jquery.com)
1 คะแนน โดย GN⁺ 2024-02-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ยกเลิกการรองรับ IE 10 และต่ำกว่า รวมถึงหยุดรองรับ Edge Legacy, iOS <11, Firefox <65 และ Android Browser
  • ลบ API ที่อยู่ในสถานะเลิกใช้งาน (deprecation) มาหลายเวอร์ชันออก: 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
  • ลบ push, sort, splice ซึ่งเป็นเมธอด Array สำหรับใช้งานภายในของ jQuery prototype ออก จึงอาจส่งผลต่อปลั๊กอินที่พึ่งพาเมธอดเหล่านี้
  • ลบการ override เดิมของ jQuery ออกจากลำดับอีเวนต์ที่เกี่ยวข้องกับ focusout, blur, focusin, focus และเบราว์เซอร์ปัจจุบันที่ไม่ใช่ IE จะทำตามลำดับของ W3C คือ blur → focusout → focus → focusin
  • jQuery.ajax รองรับ ข้อมูลไบนารีและ FormData แล้ว และเปลี่ยนจากพฤติกรรมเดิมที่มองเป็นชนิดข้อมูลที่ไม่รู้จักแล้วแปลงเป็นสตริง มาเป็นการจัดการอัตโนมัติ
  • ยกเลิกพฤติกรรมของ jQuery.ajax ที่เคย ยกระดับเป็นคำขอ JSONP โดยอัตโนมัติ เมื่อมี dataType: "json" และ callback ถูกส่งมาพร้อมกัน
  • ซอร์สของ jQuery ถูกย้ายจาก AMD ไปเป็น ES modules และเครื่องมือแพ็กเกจเปลี่ยนจาก RequireJS เป็น Rollup
  • เพิ่มการรองรับ Trusted Types ทำให้สามารถใช้ HTML ที่ห่อด้วย TrustedHTML เป็นอินพุตของเมธอดจัดการ jQuery ได้โดยไม่ละเมิดคำสั่ง CSP require-trusted-types-for
  • เปลี่ยนให้คำขอสคริปต์แบบอะซิงก์ส่วนใหญ่ใช้แท็ก <script> เพื่อหลีกเลี่ยงข้อผิดพลาด CSP ที่เกิดจากการใช้สคริปต์อินไลน์
  • ใน slim build มีการลบ Deferreds และ Callbacks ออก ทำให้มีขนาดต่ำกว่า 20k bytes แบบ gzip และเล็กกว่า build ปกติประมาณ 8k gzipped bytes
  • หากยังต้องรองรับ IE11 แนะนำให้ใช้ main build แทน slim build หรือเพิ่ม native Promises polyfill
  • ก่อนออกเวอร์ชันจริงจะมีการเผยแพร่คู่มืออัปเกรดแบบครอบคลุม และเตรียม jQuery Migrate plugin ไว้เป็นตัวช่วยสำหรับการย้ายระบบ
  • รุ่นเบต้ามีให้ใช้งานผ่าน jQuery CDN และ npm ส่วน CDN ของบุคคลที่สามจะไม่โฮสต์รุ่นเบต้า และจะโฮสต์รุ่นจริง 4.0.0 ในภายหลัง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-08
ความคิดเห็นบน Hacker News

  • ถ้าสงสัยว่าอะไรยังขับเคลื่อน jQuery หลังปี 2024 อยู่ ให้จำไว้ว่า WordPress ยังคิดเป็นมากกว่า 1/3 ของเว็บ และตัวติดตั้งส่วนใหญ่กับปลั๊กอินจำนวนมหาศาลยังพึ่งพา jQuery อย่างมาก
    เป็นเรื่องดีที่การถอด API หรือฟังก์ชันที่มีกำหนดเลิกใช้คืบหน้าไป และ jQuery ก็น่าจะยังคงครองบทบาทสำคัญบนเว็บต่อไปอีกหลายปี

    • นอกจากนี้ jQuery ยังยอดเยี่ยมมาก
      ตลอดราว 15 ปีที่ผ่านมา อุตสาหกรรมนี้หลงไปกับ JavaScript framework ที่ซับซ้อนและหวือหวาเกินจำเป็น แต่สำหรับ 99% ของเว็บเพจ สิ่งที่ต้องใช้ JavaScript จริง ๆ ก็แค่ผูก event แบบ dynamic กับฟอร์มที่สร้างขึ้นแบบ dynamic จัดการสถานะ error และเรียก Ajax ไม่กี่ครั้ง ที่เหลือมักเป็นการทำเกินจำเป็น
      คิดว่าอุตสาหกรรมจะค่อย ๆ ออกจากความซับซ้อนของ React ไปสู่ความเรียบง่ายอย่าง htmx, Phoenix LiveView, Ruby on Rails Turbo และแม้แต่ jQuery ธรรมดา ๆ
    • ไม่ว่าใครจะว่าอย่างไร jQuery ก็ยังทรงพลัง สำคัญ และมีอิทธิพลมาก
      ถ้าถอด jQuery ออกจากซอฟต์แวร์ทั้งหมด เว็บไซต์จำนวนมากทั่วอินเทอร์เน็ตคงหยุดทำงาน
    • นี่ไม่ใช่แค่เรื่องของ WordPress
      บริษัทเก่าที่เคยทำงานด้วยรัน ผลิตภัณฑ์ SaaS ระดับ enterprise ด้วยโค้ด jQuery หลายหมื่นบรรทัด
      ตราบใดที่ยังไม่จำเป็นจริง ๆ ก็จะไม่มีการเขียนใหม่ด้วย JS framework สมัยใหม่ โค้ดส่วนใหญ่เขียนขึ้นเมื่อกว่า 10 ปีก่อนเพื่อตอบความต้องการเฉพาะของลูกค้าบางราย และเหตุผลที่ว่าใช้ framework สมัยใหม่แล้วจะช่วยดึงดูดคนก็ใช้ไม่ได้ บริษัทจ่ายเงินให้ frontend engineer แค่ 75,000–90,000 ดอลลาร์ อัตราการลาออกก็ต่ำ และวิศวกรส่วนใหญ่ตอนนี้ทำงานมาเกิน 5 ปีแล้ว
      ที่สำคัญที่สุดคือ stack ปัจจุบันทำงานได้ดี และลูกค้าเก่าก็พอใจ งานวิศวกรรมซอฟต์แวร์จำนวนมากเกิดขึ้นใน ธุรกิจน่าเบื่อ แบบนี้ในเมืองที่ค่าครองชีพต่ำกว่า hub ของ big tech อย่าง Bay Area หรือ Seattle มาก
    • นักพัฒนา WordPress เหมือน ช่างประปา ของวงการเทคโนโลยี
      ไม่ได้หรูหรา แต่มีคนต้องการมากจนทำเงินได้ดี
      ถ้าวันหนึ่งเกษียณจากโลกสตาร์ทอัพ big tech ที่วิ่งตามกระแสล่าสุด ก็อยากหาเงินอย่างสุจริตด้วยการทำเว็บ WordPress แล้วเลิกงานตอนบ่าย 3 ทุกวัน
    • ไม่นานมานี้เกือบจะโพสต์ลง HN แล้ว แต่ยังหา โมเดลการจัดการ/บับเบิล event chain ดี ๆ ที่ทำให้ DOM member กับ instance ของ abstract class trigger event ที่ใช้แทนกันได้ไม่เจอ
      เคยสร้าง event dispatcher เองหลายที่ แต่ jQuery ทำส่วนนี้ได้ถูกต้องจริง ๆ ทุกวันนี้ก็แทบใช้ jQuery เฉพาะงาน event handling แต่มีประโยชน์มากจนใส่ไว้ในแทบทุกโปรเจกต์ฝั่ง client
      สิ่งที่อยากถามคือมีใครรู้จักไลบรารีน้ำหนักเบาที่จัดการทั้ง $(window).trigger('click') และ $(myClassInstance).trigger('myCustomEvent',{data}) ด้วย API เดียวกัน รวมถึงการ listen แบบ asynchronous ไหม
      ด้วยการมาของ fetch() และ CSS selector ตอนนี้ส่วนอื่น ๆ ของ jQuery อาจไม่จำเป็นแล้ว แต่ก็สงสัยว่าจำเป็นต้องประดิษฐ์ล้อใหม่หรือเปล่า ก่อนจะบอกว่าการที่ class instance dispatch event เป็น code smell ต้องบอกว่าถ้าจะสร้าง reactive framework ตั้งแต่ศูนย์ นี่เป็นสิ่งจำเป็น
      ตัวอย่างเช่น class คอมโพเนนต์พื้นฐานของผม listen custom resize event บางอย่างที่เกิดบนหน้าจอที่มีมันอยู่ และหน้าจอนั้นจะส่ง event ให้เฉพาะคอมโพเนนต์ที่ต้องจัด layout ภายในใหม่โดยที่หน้าจอไม่ scroll เท่านั้น class ของหน้าจอ listen window.resize แต่จะ dispatch เฉพาะเมื่อ layout มีปัญหา การติด DOM resize listener แยกของทุกคอมโพเนนต์ไว้กับ window ไม่สมเหตุสมผลเลย

  • แปลกใจที่ยังเห็นคนใน HN มอง jQuery เป็นแค่ไลบรารีเลือก DOM อยู่เรื่อย ๆ
    จริง ๆ แล้วมันเป็นชุดเครื่องมือที่รองรับกว้างและเสถียรมาก ไม่ได้มีแค่การเลือก DOM แต่ยังมี การปรับแต่ง property, คำขอ Ajax, การจัดการ event, animation และฟังก์ชัน utility ทั่วไปด้วย
    แถมแม้จะมีความสามารถ native ที่ใช้แทน jQuery ได้ API ก็ไม่ได้ลื่นไหลเท่ากัน
    ถ้างานของคุณแค่ต้องเติมความสามารถเล็กน้อยบน HTML ฝั่ง server และยังไม่ต้องใช้ JS UI framework เต็มรูปแบบ jQuery ก็เป็น dependency ที่เสถียร เชื่อถือได้ และเข้ากันได้ข้าม browser โดยมีต้นทุนเพียงเล็กน้อย

    • หลายปีก่อนเลิกใช้ jQuery แล้วย้ายไปใช้ JavaScript ล้วน จากนั้นก็ไม่เคยมองย้อนกลับไปอีก
      native JS มีทุกอย่างที่ jQuery มี และโดยมากไม่มีแค่ กองปลั๊กอิน ที่ดูแลไม่ดีและทำเสร็จครึ่ง ๆ กลาง ๆ เท่านั้น ปลั๊กอินแบบนั้นมักทำได้แค่สิ่งที่ตัวเองตั้งใจทำ และอย่างอื่นก็ไม่ค่อยช่วยอะไร
      selector แบบล้วนจะยืดยาวกว่า แต่ code editor ทั่วไปก็ช่วยให้พิมพ์ได้เร็วเท่ากัน ไม่ได้จะหาเรื่อง แต่ไม่ค่อยเข้าใจว่าทำไมคนจำนวนมากยังใช้ jQuery กันอยู่
      https://youmightnotneedjquery.com/
    • ถ้าดูฐานผู้เขียนใน HN ก็ไม่ได้แปลกขนาดนั้น
      เพราะเมื่อไหร่ที่ต้องการอะไรเกินการเลือก DOM นิดหน่อย หลายคนก็หยิบ JS framework ขนาดใหญ่ ที่กำลังฮิตในตอนนั้นมาใช้ทันที และก็ทำกันแบบนั้นมาตลอด
    • พูดว่า “คนที่มองว่า jQuery เป็นแค่ไลบรารีเลือก DOM” แล้วต่อมาก็ลิสต์เรื่องการเลือกกับฟังก์ชัน native ต่าง ๆ อยู่ดี
    • ใส่ jQuery เข้าโปรเจกต์ง่ายกว่ามาก
      ไม่ต้องใช้ build tool กับเรื่องปวดหัวที่พ่วงมาด้วย React ก็ทำแบบนั้นได้เหมือนกัน แต่ฟีเจอร์ที่ให้มาเทียบกันไม่ได้

  • ในโลกที่หลายคนพยายามกำจัดร่องรอยสุดท้ายของ jQuery กันอย่างจริงจัง ผมสงสัยจริง ๆ ว่าตอนนี้ใครยังพัฒนาอะไรด้วย jQuery อย่างจริงจังอยู่บ้าง
    สิ่งส่วนใหญ่ที่เมื่อก่อนทำด้วย jQuery ตอนนี้อยู่ในเบราว์เซอร์แล้ว และผมมองว่า querySelectorAll เป็นตัวอย่างที่ชัดที่สุด

    • ผมอายุมากขึ้น และเทคโนโลยีใหม่ ๆ ก็น่าตื่นเต้นน้อยลง เลยรู้สึกว่า $.ajax() ง่ายกว่า promise, await, async ของ native JS มาก
      ผมเคยลองใช้ JS ล้วนในโปรเจกต์ส่วนตัวเล็ก ๆ หลายอันเพื่อให้คุ้นเคย แต่สำหรับผม การจัดการด้วย $.ajax() เป็นวิธีที่ทำได้ทันทีเหมือน muscle memory
      อีกอย่าง โค้ดที่ผมใช้สำหรับจัดการ DOM ก็น่าจะมีคนใช้จริงแค่ราว 20 คน ผมไม่ได้รับผิดชอบ UI แต่เป็นฝั่งแบ็กเอนด์ แค่ต้องเขียนฟรอนต์เอนด์ด้วยเพราะไม่มีใครทำให้
    • อ้างอิงจากแบบสำรวจ Stack Overflow ปีที่แล้ว jQuery ได้รับความนิยมเป็นอันดับสาม
      https://survey.stackoverflow.co/2023/#section-most-popular-t...
    • เพิ่งทำงานให้บริษัทหนึ่งที่กำลังกำจัดร่องรอยสุดท้ายของ React อยู่นาน แล้วเปลี่ยนไปใช้ HTMX
      ส่วนตัวผมมองว่า HTMX เป็นผู้สืบทอดทางจิตวิญญาณของ jQuery ในบางแง่
    • ผมเองก็กำลังพยายามกำจัด jQuery อย่างจริงจังเหมือนกัน แต่คนคุ้นเคยกับเครื่องมือแล้ว และการเขียนใหม่ก็มีต้นทุน จึงดูเหมือนจะขาดทั้งแรงจูงใจหรือเหตุผลทางธุรกิจที่มากพอจะเอาออก
      ถ้าเริ่มโปรเจกต์ใหม่ด้วย jQuery ก็น่าสงสัยอยู่ แต่ก็มีนักพัฒนาที่คุ้นกับการจัดการแบบ jQuery มากกว่าวิธี JavaScript ล้วนอย่างชัดเจน
    • นักพัฒนาเดี่ยวหรือทีมเล็ก ๆ ที่ไม่ชอบ toolchain สมัยใหม่ใช้กัน
      ตัวอย่างที่ดีคือ levelsio: https://twitter.com/levelsio/status/1750175827197567165
      ผมก็อยู่ฝั่งนั้นและยังใช้ jQuery อยู่
      SaaS ปัจจุบันคือ https://www.snipcss.com ซึ่งเป็นส่วนขยายที่มีโค้ด UI ไม่มาก ส่วน SaaS ถัดไปจะเป็นส่วนขยายเว็บอัตโนมัติที่ใช้ ChatGPT และมี UI ค่อนข้างเยอะ ทั้งคู่ใช้ jQuery
      เหตุผลหลักที่ไม่ไปใช้ JS ล้วนกับ querySelectorAll คือผมชอบวิธีผูก event โดยเฉพาะการผูกไว้ที่ parent เพื่อเล็งเป้าไปยัง child elements ที่ถูกเพิ่มแบบไดนามิกได้ ชอบ function chaining และโค้ดก็น้อยกว่า JS ล้วน

  • ยอดเยี่ยมมาก แต่ผม รอ 4.0 นานเกินไป จนสุดท้ายสร้าง jQuery ของตัวเองที่มีความแตกต่างหลัก ๆ อยู่หลายอย่าง
    แอนิเมชัน, tween, timeline ใช้ CSS ล้วนแทนระบบ custom ของ jQuery จัดการ element เดี่ยวกับ list ได้อย่างโปร่งใส และเลือกแนวทางแบบ inline

    • ผมคิดมาตลอดว่าควรมี ทางเลือกแทน jQuery ที่ทันสมัยและเบาแบบนี้ ทำได้ดี และผมก็ชอบไวยากรณ์ด้วย
      ผมเองก็กำลังทำสิ่งคล้าย ๆ กันอยู่ โดยมีมากกว่า inline event และ standard array methods [0]
      ถ้ามีบทความหรือ screencast อธิบายว่า surreal กับโปรเจกต์คู่ css-scope-inline ใช้ locality of behavior อย่างไรคงดี ผมอยากเข้าใจเพื่อจะได้ดูแลต่อระยะยาวและใส่ไว้ในโปรเจกต์ของผมด้วย
      อยากคุยเรื่องปรัชญาเกี่ยวกับเว็บด้วย คิดว่ามีหลายอย่างที่น่าจะตรงกัน
      [0] https://hyperspace.so/All.js.png

  • รู้สึกเหมือนได้ย้อนกลับไปสมัยเป็นจูเนียร์ราวปี 2008 ตอนนั้นถกเถียงกับ tech lead อย่างดุเดือดเรื่องจะเพิ่ม jQuery เข้าโปรเจกต์
    เหตุผลของเขาคือขนาดไลบรารีหลัง minify ที่ 40KB เป็นภาระต่อเวลาโหลดหน้าเว็บมากเกินไป
    จากนั้นก็ใช้เวลาทั้งสัปดาห์เขียน Ajax call เองและทดสอบการรองรับหลายเบราว์เซอร์ แต่สุดท้ายก็ทำให้มันทำงานบน Internet Explorer 5 ไม่สำเร็จ
    ในยุคนั้น jQuery แก้ปัญหาปวดหัวได้มากจริง ๆ และสุดท้ายเขาก็เพิ่มไลบรารีเข้าโปรเจกต์

    • คนมักลืมเรื่องนี้ แต่เบราว์เซอร์สมัยก่อนแตกต่างกันมาก และ jQuery เป็น กาว ที่สมเหตุสมผลเพียงอย่างเดียวในการยึด codebase ไว้ในแง่นั้น
    • ขอปรบมือให้ tech lead ที่สู้ในศึกที่ดี

  • ทีม jQuery ทำได้ดีมาก ผมคงชอบ jQuery ไปตลอด
    มันเป็นเครื่องมือที่ ทำให้งานเสร็จ จริง ๆ

    • Bootstrap, PHP, JQuery, WP คือสแตกของคนที่สร้างผลงานจริง

  • ตอนนี้เบราว์เซอร์รองรับการเลือก DOM ได้ดีขึ้นมากแล้ว เลยสงสัยว่าทำไมในปี 2024 ยังใช้ jQuery กันอยู่
    ไม่ได้ตั้งใจจะดูถูก และคิดว่าการที่ยังพัฒนาต่ออยู่ก็เจ๋งดี แต่ผมงงว่า use case คืออะไร

    • มี selector ที่ค่อนข้างสะดวกหลายตัวที่ document.querySelector() ไม่รองรับ
      เช่น :selected, :checked และยังมีอีกหลายตัวที่ผมเคยเจอจริงอยู่สองสามครั้ง
      โดยรวมแล้ว DOM API ขัดกับความรู้สึกของผมเกี่ยวกับการออกแบบ API ที่ดีแทบทั้งหมด ผมก็มีข้อตำหนิต่อ jQuery API เหมือนกัน แต่มันดีกว่ามาก และลื่นไหลกว่าอย่างมากเวลาอ่านและเขียน
    • น่าจะเพราะโปรเจกต์ legacy หรือเปล่า
      ผมดูแล .NET เว็บแอป เก่าอายุประมาณ 15 ปีอยู่ และก็กลับไปใช้ jQuery ความฝันที่จะรีแฟกเตอร์หรือเขียนใหม่ทั้งหมดด้วยของที่ทันสมัยกว่าอย่าง Web Components นั้นดี แต่ในความเป็นจริงคงไม่มีวันทำแน่
    • เดาว่าเพราะ API ที่สะดวกและ ecosystem ขนาดใหญ่
    • ผมชอบ jQuery สำหรับหน้าแอดมิน
      ถ้าเป็นหน้าที่มีพนักงานภายในดูแค่ 20 คน jQuery ก็เบาพอ โหลดตรงจาก CDN ได้ ไม่ต้องใช้ transpiler ใด ๆ และโดยพื้นฐานก็จัดการสิ่งที่ต้องการได้ครบ

  • เป็นข้อมูลประกอบว่า เราสร้าง ตัวแก้ไขแบบลากแล้ววางของแพลตฟอร์ม low-code ทั้งหมด ด้วย jQuery
    รวมถึง editor, control ทั้งหมด หรือก็คือ UI components และไม่ต้องพูดถึงว่าโค้ดสุดท้ายที่生成ออกมาก็เป็น jQuery ล้วนเช่นกัน
    แต่ผู้บริหารองค์กรใหญ่มักถาม sales engineer ว่าทำไมไม่ใช้ React หรือ Angular อะไรพวกนั้น
    ดังนั้นผมดีใจมากที่ได้อ่านว่า jQuery ยังเกี่ยวข้องมากขนาดนี้ และดีใจที่ผู้ร่วมก่อตั้งซึ่งเป็น CTO ของเรายังสนับสนุนทางเลือกนี้ต่อไปโดยไม่พยายามย้ายสแตก

  • จำได้ว่าตอนที่ jQuery เพิ่งออกมาใหม่ ๆ
    ผมเคยจัดพรีเซนต์ภายในชื่อ “Don’t Fear the $” เพื่อโน้มน้าวเพื่อนร่วมงาน และอธิบายข้อดีต่าง ๆ ที่ jQuery มอบให้

  • จำได้ถึงยุครุ่งเรืองของ jQuery ตอนที่เราใช้มันเป็นตัวแทน Mootools
    ตอนนี้มีคนจำนวนมากย้ายจาก React ไป HTMX กันอยู่ บางทีเว็บอาจวนกลับมาจนเราได้เห็นการใช้ jQuery แบบล้วน ๆ ก็ได้

    • แม้จะผ่านยุคใกล้เคียงกันมา แต่ก็ไม่ได้คิดถึงความวุ่นวายเหล่านั้นเลย
      แค่คิดว่าจะสร้างแอปสมัยใหม่ที่มีทั้งการเข้าถึงสำหรับผู้พิการ, การรองรับมือถือ, การอัปเดตแบบเรียลไทม์, การแสดงผลภาพข้อมูล และแม้แต่ฟีเจอร์ PWA บางอย่าง ด้วย jQuery เพียงอย่างเดียว ก็ฟังดูน่าหงุดหงิดมากแล้ว
      ผมก็กำลังรอดูว่า กระแส HTMX ที่ร้อนแรงเกินไป จะชนกับความเป็นจริงเมื่อไร วิธีโปรแกรมแอปด้วยแอตทริบิวต์ปลอม ๆ คล้าย DSL น่าจะเบื่อได้เร็ว
    • HTMX ทำให้นึกถึง Mootools
      เป็นไลบรารี JS ขนาดเล็กและเฉพาะทางมาก
    • HTMX เหมือน $().load()
    • คำว่า “จำนวนมาก” อาจจะเกินจริงไปหน่อย