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 prototype के आंतरिक Array methods रहे push, sort, splice हटा दिए गए हैं, जिससे उन methods पर निर्भर plugins प्रभावित हो सकते हैं
  • focusout, blur, focusin, focus से जुड़े event order में jQuery का पुराना override हटा दिया गया है, और अब IE को छोड़कर ब्राउज़र मौजूदा W3C क्रम blurfocusoutfocusfocusin का पालन करेंगे
  • jQuery.ajax अब binary data और FormData को सपोर्ट करता है, और पहले की तरह अनजान data type मानकर string में बदलने के बजाय अब यह अपने-आप संभाला जाएगा
  • dataType: "json" और callback साथ दिए जाने पर JSONP request में अपने-आप promote कर देने वाला jQuery.ajax व्यवहार हटा दिया गया है
  • jQuery source को AMD से ES modules में migrate किया गया है, और packaging tool को RequireJS से Rollup में बदला गया है
  • Trusted Types सपोर्ट जोड़ा गया है, जिससे TrustedHTML में wrapped HTML को require-trusted-types-for CSP directive का उल्लंघन किए बिना jQuery manipulation methods के input के रूप में इस्तेमाल किया जा सकता है
  • ज़्यादातर asynchronous script requests अब <script> टैग का उपयोग करती हैं, ताकि inline script के उपयोग से होने वाली CSP errors से बचा जा सके
  • slim build से Deferreds और Callbacks हटा दिए गए हैं, जिससे इसका आकार gzip के आधार पर 20k bytes से कम हो गया है, और यह सामान्य build से लगभग 8k gzipped bytes छोटा है
  • अगर IE11 सपोर्ट चाहिए, तो slim build की जगह main build का उपयोग करने या native Promises polyfill जोड़ने की सलाह दी गई है
  • औपचारिक रिलीज़ से पहले एक व्यापक upgrade guide जारी की जाएगी, और migration में मदद के लिए jQuery Migrate plugin तैयार किया जाएगा
  • बीटा रिलीज़ jQuery CDN और npm पर उपलब्ध है, जबकि third-party CDN इस बीटा को host नहीं करेंगे और बाद में 4.0.0 औपचारिक रिलीज़ को host करेंगे

1 टिप्पणियां

 
GN⁺ 2024-02-08
Hacker News की राय
  • अगर आप सोच रहे हैं कि 2024 के बाद भी jQuery को चलाए रखने वाली ताकत क्या है, तो याद रखें कि WordPress अब भी वेब के 1/3 से अधिक हिस्से पर है और ज़्यादातर इंस्टॉलेशन व अनगिनत प्लगइन्स jQuery पर काफी निर्भर हैं
    deprecated होने वाली APIs या functions को हटाने में प्रगति होना अच्छी बात है, और jQuery के आगे भी कई वर्षों तक वेब पर हावी रहने की संभावना है

    • इसके अलावा jQuery शानदार है
      पिछले लगभग 15 वर्षों से इंडस्ट्री जरूरत से ज्यादा जटिल और चमकदार JavaScript frameworks में उलझी रही है, लेकिन dynamically generated forms पर dynamic binding लगाना, error states संभालना और कुछ Ajax calls करना—99% web pages को जितनी JavaScript चाहिए, वह बस इतनी ही है; बाकी अक्सर जरूरत से ज्यादा होता है
      लगता है इंडस्ट्री React की जटिलता से हटकर htmx, Phoenix LiveView, Ruby on Rails Turbo, और सीधे-सरल jQuery जैसी simplicity की ओर जाएगी
    • कोई कुछ भी कहे, jQuery अब भी शक्तिशाली है, महत्वपूर्ण है और उसका प्रभाव बड़ा है
      अगर सभी software से jQuery हटा दिया जाए, तो इंटरनेट भर में काफी बड़ी संख्या में websites रुक जाएंगी
    • यह सिर्फ WordPress की समस्या नहीं है
      जिस कंपनी में मैं पहले काम करता था, वह एक enterprise SaaS product को jQuery code की दसियों हजार लाइनों पर चलाती थी
      जब तक बिल्कुल जरूरी न हो जाए, इसे किसी modern JS framework में दुबारा लिखने का काम नहीं होगा। इसका अधिकांश code 10 साल से भी पहले खास ग्राहक-जरूरतों के हिसाब से लिखा गया था, और modern framework इस्तेमाल करने से hiring में मदद मिलेगी—यह तर्क भी वहां नहीं चलता। कंपनी frontend engineers को सिर्फ 75k–90k dollars देती है, attrition भी कम है, और मौजूदा engineers में ज़्यादातर 5 साल से अधिक समय से काम कर रहे हैं
      सबसे बढ़कर, मौजूदा stack ठीक से काम करता है और पुराने ग्राहक भी संतुष्ट हैं। software engineering का काफी बड़ा हिस्सा Bay Area या Seattle जैसे big-tech hubs की तुलना में बहुत कम cost of living वाले शहरों में ऐसे ही boring businesses में होता है
    • WordPress developers tech industry के plumbers जैसे हैं
      काम glamourous नहीं है, लेकिन जरूरतमंद लोग इतने ज्यादा हैं कि अच्छा पैसा कमाया जा सकता है
      अगर कभी latest trends के पीछे भागने वाली big-tech startup दुनिया से retire हुआ, तो ईमानदारी से पैसा कमाते हुए WordPress sites बनाना और हर दिन दोपहर 3 बजे काम खत्म करना चाहूंगा
    • कुछ समय पहले HN पर पोस्ट करने वाला था पर किया नहीं; अब भी कोई बढ़िया event chain handling/bubbling model नहीं मिला है, जो DOM members और abstract class instances को आपस में interchangeable events trigger करने दे
      मैंने कई जगह खुद event dispatchers बनाए हैं, लेकिन jQuery यह हिस्सा सही तरह से करता है। आज भी लगभग सिर्फ event handling के लिए jQuery इस्तेमाल करता हूं, लेकिन यह इतना उपयोगी है कि लगभग हर client-side project में शामिल कर देता हूं
      जो पूछना चाहता था वह यह था कि क्या कोई ऐसी lightweight library जानता है जो $(window).trigger('click') और $(myClassInstance).trigger('myCustomEvent',{data}) को एक ही API से, async listening तक संभाल सके
      fetch() और CSS selectors के उभार के कारण अब लगता है कि jQuery का बाकी हिस्सा छोड़ा जा सकता है, लेकिन जब जरूरत नहीं तो पहिया फिर से क्यों बनाया जाए? class instances द्वारा events dispatch करना code smell है कहने से पहले, अगर reactive framework शुरू से बनाना हो तो यह जरूरी है
      उदाहरण के लिए, मेरी base component class उस screen में होने वाले कुछ custom resize events को सुनती है जिसमें वह शामिल है, और वह screen उन components को ही events भेजती है जिन्हें scroll किए बिना अपने अंदर layout बदलना होता है। screen class window.resize सुनती है, लेकिन layout मुश्किल होने पर ही dispatch करती है। हर component के लिए अलग-अलग DOM resize listener window पर लगाना कोई समझदारी नहीं है
  • HN पर लगातार ऐसे लोग दिखते हैं जो jQuery को सिर्फ DOM selection library समझते हैं, यह देखकर हैरानी होती है
    असल में यह widely supported और बहुत stable toolkit है, जो DOM selection के साथ-साथ attribute manipulation, Ajax requests, event handling, animations और general-purpose utility functions भी देता है
    इसके अलावा, jQuery की जगह लेने वाली native features मौजूद हों तब भी उनकी API उतनी smooth नहीं होती
    अगर काम सिर्फ server-side HTML के ऊपर थोड़ी functionality जोड़ने का है और पूरा JS UI framework जरूरी नहीं है, तो jQuery एक stable, reliable और cross-browser-compatible dependency के रूप में बहुत छोटी कीमत है

    • कुछ साल पहले jQuery छोड़कर pure JavaScript पर आया और फिर कभी पीछे मुड़कर नहीं देखा
      native JS में jQuery वाली सारी चीजें हैं, और आम तौर पर बस poorly maintained, आधे-अधूरे plugins के ढेर नहीं हैं। ऐसे plugins अक्सर सिर्फ वही करते हैं जो वे करना चाहते हैं, उसके अलावा खास कुछ नहीं देते
      pure selectors ज्यादा verbose जरूर हैं, लेकिन कोई भी ठीक-ठाक code editor typing speed बराबर करा देता है। बहस करने का इरादा नहीं, लेकिन अब भी इतने लोग jQuery क्यों इस्तेमाल करते हैं, यह ठीक से समझ नहीं आता
      https://youmightnotneedjquery.com/
    • HN के लेखकों के वर्ग को देखते हुए यह इतना हैरान करने वाला नहीं है
      DOM selection से थोड़ा ज्यादा कुछ चाहिए होते ही बहुत लोग उस समय trend में चल रहा बड़ा JS framework उठा लेते हैं, और हमेशा से ऐसा ही करते आए हैं
    • “जो लोग jQuery को बस DOM selection library समझते हैं” कहने के बाद, आगे selection और native functions की ही सूची दी जा रही है
    • project में jQuery जोड़ना कहीं ज्यादा आसान है
      build tools और उनसे जुड़ी सिरदर्द वाली चीजों की जरूरत नहीं। React के साथ भी ऐसा किया जा सकता है, लेकिन जो features मिलते हैं वे तुलना लायक नहीं हैं
  • ऐसी दुनिया में जहां बहुत से लोग jQuery के आखिरी निशान भी सक्रिय रूप से हटाने की कोशिश कर रहे हैं, मैं सच में जानना चाहता हूं कि अभी jQuery से सक्रिय development कौन कर रहा है
    पहले jQuery से किए जाने वाले ज्यादातर काम अब browser में मौजूद हैं, और मुझे लगता है querySelectorAll इसका सबसे मजबूत उदाहरण है

    • उम्र बढ़ गई है और नई technologies कम रोमांचक लगने लगी हैं, इसलिए native JS के promise, await, async की तुलना में $.ajax() मुझे कहीं ज्यादा सरल लगता है
      आदत डालने के लिए मैंने कुछ छोटे personal projects में pure JS भी इस्तेमाल किया, लेकिन मेरे लिए $.ajax() से संभालना muscle memory की तरह तुरंत हो जाने वाला तरीका है
      ऊपर से DOM manipulation के लिए मैं जो code लिखता हूं, उसे असल में इस्तेमाल करने वाले शायद करीब 20 लोग होंगे। मैं UI वाला नहीं, backend वाला हूं; बस कोई और करने वाला नहीं है, इसलिए frontend भी लिखता हूं
    • पिछले साल के Stack Overflow survey के हिसाब से jQuery तीसरा सबसे लोकप्रिय था
      https://survey.stackoverflow.co/2023/#section-most-popular-t...
    • अभी-अभी एक कंपनी में React के आखिरी निशान काफी देर तक हटाकर उन्हें HTMX से बदलने का काम किया
      निजी तौर पर, मुझे HTMX कुछ मायनों में jQuery का आध्यात्मिक उत्तराधिकारी लगता है
    • मैं भी jQuery हटाने की सक्रिय कोशिश कर रहा हूं, लेकिन लोग tools के आदी हो चुके हैं और फिर से लिखने में cost आती है, इसलिए लगता है कि इसे हटाने जितनी इच्छाशक्ति या business justification कम है
      कोई नया project jQuery से शुरू करना संदिग्ध लगता है, लेकिन ऐसे developers निश्चित रूप से हैं जो pure JavaScript तरीके की तुलना में jQuery-style में काम करने के कहीं ज्यादा आदी हैं
    • इसे ऐसे solo developers या छोटी teams इस्तेमाल करती हैं जिन्हें modern toolchain पसंद नहीं है
      अच्छा उदाहरण levelsio है: https://twitter.com/levelsio/status/1750175827197567165
      मैं भी उसी तरफ हूं और अब भी jQuery इस्तेमाल करता हूं
      मौजूदा SaaS https://www.snipcss.com नाम का extension है जिसमें UI code ज्यादा नहीं है, और अगला SaaS ChatGPT-based web automation extension होगा जिसमें UI काफी होगा। दोनों jQuery इस्तेमाल करते हैं
      querySelectorAll इस्तेमाल करने वाले pure JS की तरफ न जाने की मुख्य वजह यह है कि मुझे events attach करने का तरीका पसंद है, खासकर parent पर attach करके dynamically जोड़े गए child elements को target कर पाना; function chaining अच्छी लगती है; और pure JS की तुलना में code कम होता है
  • शानदार। हालांकि मैंने 4.0 का बहुत लंबा इंतजार करते-करते आखिरकार कुछ मुख्य अंतर वाला अपना jQuery बना लिया
    animation, tween और timeline के लिए jQuery के custom system की जगह pure CSS इस्तेमाल करता है, single element और lists को transparent तरीके से handle करता है, और inline approach अपनाता है

    • मुझे हमेशा लगता था कि इस तरह का modern और हल्का jQuery alternative होना चाहिए। अच्छा बनाया है और syntax भी पसंद आया
      मैं भी कुछ ऐसा ही implement कर रहा था, जिसमें inline events और standard array methods से ज्यादा शामिल था [0]
      अच्छा होगा अगर surreal और companion project css-scope-inline में locality of behavior कैसे implement होती है, इस पर कोई article या screencast हो। मैं समझना चाहता हूं ताकि इसे long-term maintain कर सकूं और अपने projects में भी डाल सकूं
      web को लेकर philosophy पर भी बात करना चाहूंगा। कुछ चीजों पर शायद हमारी सोच काफी मिलती हो
      [0] https://hyperspace.so/All.js.png
  • ऐसा लग रहा है जैसे 2008 के आसपास junior days में लौट गया हूं। project में jQuery जोड़ने को लेकर tech lead से मेरी तीखी बहस हुई थी
    उनका तर्क था कि minified library size 40KB page loading time पर बहुत बड़ा बोझ डालेगा
    फिर उन्होंने Ajax calls खुद लिखने और multiple browser support test करने में पूरा एक हफ्ता लगा दिया, लेकिन आखिर में Internet Explorer 5 पर चलाने में नाकाम रहे
    उस दौर में jQuery ने सच में बहुत सारी परेशानियां हल की थीं, और आखिरकार उन्होंने project में library जोड़ दी

    • लोग यह बात अक्सर भूल जाते हैं कि पुराने browsers एक-दूसरे से काफी अलग थे, और उस लिहाज से jQuery codebase को थामे रखने वाला इकलौता समझदार glue था
    • अच्छी लड़ाई लड़ने वाले tech lead को सलाम
  • jQuery team ने बढ़िया किया। लगता है jQuery हमेशा पसंद रहेगा
    यह बस काम पूरा करा देने वाला tool है

    • Bootstrap, PHP, JQuery, WP असल में output बनाने वालों का stack है
  • अब जब browser का DOM selection support काफी बेहतर हो गया है, तो 2024 में jQuery क्यों इस्तेमाल करें, यह जानने की उत्सुकता है
    मैं इसे नीचा नहीं दिखा रहा, और यह अच्छा लगता है कि development अब भी जारी है, लेकिन use case क्या है, यह समझ नहीं आता

    • ऐसे कई काफी सुविधाजनक selectors हैं जिन्हें document.querySelector() support नहीं करता
      जैसे :selected, :checked वगैरह, और कुछ और भी थे जिनसे मैं असल में कई बार टकराया हूं
      कुल मिलाकर DOM API, अच्छे API design को लेकर मेरी ज्यादातर समझ के खिलाफ जाती है। jQuery API से भी शिकायतें हैं, लेकिन वह कहीं बेहतर है और पढ़ने-लिखने का flow ज्यादा natural है
    • शायद legacy projects की वजह से
      मैं करीब 15 साल पुराना .NET web app maintain करता हूं और jQuery पर लौट आया हूं। Web Components जैसी ज्यादा modern चीजों से पूरी refactoring या rewrite करने का सपना अच्छा है, लेकिन असल में हम ऐसा कभी नहीं करेंगे
    • अंदाजा लगाऊं तो convenient API और विशाल ecosystem की वजह से
    • admin pages के लिए मुझे jQuery पसंद है
      अगर page सिर्फ 20 internal employees देखते हैं, तो jQuery पर्याप्त हल्का है, CDN से सीधे load किया जा सकता है, किसी transpilation की जरूरत नहीं, और basic तौर पर जरूरत की हर चीज संभाल देता है
  • reference के लिए, हमने पूरा low-code platform का drag-and-drop editor jQuery से बनाया है
    editor, सभी controls यानी UI components शामिल हैं, और कहने की जरूरत नहीं कि आखिर में generate होने वाला code भी pure jQuery है
    लेकिन बड़ी कंपनियों के executives sales engineer से अक्सर पूछते हैं कि React या Angular वगैरह क्यों नहीं
    इसलिए आज भी jQuery इतना relevant है यह पढ़कर सच में अच्छा लगा, और खुशी है कि co-founder और CTO stack बदलने की कोशिश नहीं कर रहे और इस choice को लगातार support कर रहे हैं

  • मुझे याद है जब jQuery पहली बार आया था
    सहकर्मियों को समझाने के लिए मैंने “Don’t Fear the $” नाम से एक internal presentation रखी थी और jQuery के फायदे समझाए थे

  • मुझे jQuery का सुनहरा दौर याद है, जब हम इसे Mootools के विकल्प के तौर पर इस्तेमाल करते थे
    अब बहुत से लोग React से HTMX की ओर जा रहे हैं, तो शायद एक पूरा चक्कर लगाकर हम वेब को फिर से सिर्फ pure jQuery इस्तेमाल करते हुए भी देख लें

    • मैं भी उसी तरह के दौर से गुज़रा हूँ, लेकिन उस अफरा-तफरी की याद नहीं आती
      accessibility, mobile support, real-time updates, visualization, और कुछ PWA features तक वाली modern app सिर्फ jQuery से बनाने की बात सोचकर ही सच में खराब लगता है
      HTMX hype के reality से टकराने का भी इंतज़ार है। DSL जैसे fake attributes से app programming करने का तरीका जल्दी ही उबाऊ लगने लगेगा
    • HTMX मुझे Mootools की याद दिलाता है
      यह एक छोटी और बहुत specialized JS library है
    • HTMX, $().load() जैसा है
    • “बहुत” कहना शायद थोड़ा बढ़ा-चढ़ाकर कहना हो सकता है