स्मूश क्या हो गया?!
JavaScript भाषा की Array.prototype.flatten
नाम की सुविधा के लिए, एक प्रपोज़ल ऐसा होता है जो वेब के साथ काम नहीं करता. Firefox Nightly में उपलब्ध सुविधा को शिपिंग करने की वजह से, कम से कम एक लोकप्रिय वेबसाइट पर असर पड़ा. यह देखते हुए कि समस्या वाला कोड, बड़े पैमाने पर उपलब्ध Mooटूल लाइब्रेरी
का हिस्सा है, इसलिए हो सकता है कि कई और वेबसाइटों पर इसका असर पड़ा हो. (हालांकि, 2018 में नई वेबसाइटों के लिए आम तौर पर Moo टूल का इस्तेमाल नहीं किया जाता, लेकिन पहले यह बहुत लोकप्रिय हुआ करता था और अब भी कई प्रोडक्शन वेबसाइटों पर मौजूद है.)
प्रस्ताव के लेखक ने मज़ाक़ में flatten
का नाम बदलकर smoosh
करने का सुझाव दिया, ताकि साथ में काम करने में आने वाली समस्या से बचा जा सके. यह चुटकुला सभी लोगों को समझ नहीं आया था. कुछ लोगों को लगा कि नया नाम पहले ही तय कर लिया गया है
और चीज़ें तेज़ी से बढ़ गईं.
Array.prototype.flatten
क्या करता है?
मूल रूप से Array.prototype.flat
को Array.prototype.flatten
के तौर पर पेश किया गया था. यह तय किए गए depth
तक बार-बार सपाट होता है, जो डिफ़ॉल्ट रूप से 1
होता है.
// Flatten one level:
const array = [1, [2, [3]]];
array.flat();
// → [1, 2, [3]]
// Flatten recursively until the array contains no more nested arrays:
array.flat(Infinity);
// → [1, 2, 3]
इस प्रस्ताव में Array.prototype.flatMap
शामिल है, जो कि Array.prototype.map
जैसा है. हालांकि, यह नतीजे को एक नए अरे में बदल देता है.
[2, 3, 4].flatMap((x) => [x, x * 2]);
// → [2, 4, 3, 6, 4, 8]
MooTool क्या कर रहा है जिससे यह समस्या होती है?
Mootools, Array.prototype.flatten
के अपने नॉन-स्टैंडर्ड वर्शन के बारे में बताता है:
Array.prototype.flatten = /* non-standard implementation */;
MooTool का flatten
लागू करने का तरीका, सुझाए गए स्टैंडर्ड से अलग है.
हालांकि, यह समस्या नहीं है! जब ब्राउज़र Array.prototype.flatten
को नेटिव तौर पर शिप करते हैं, तो MooTool नेटिव लागू करने की प्रक्रिया को बदल देता है. इससे यह पक्का होता है कि Moo टूल के काम करने के तरीके पर निर्भर कोड,
सही तरीके से काम करता है. भले ही, नेटिव flatten
उपलब्ध हो या नहीं.
अब तक, बहुत बढ़िया!
माफ़ करें, इसके बाद कुछ और हो जाता है. MooTool अपने सभी कस्टम अरे तरीकों को Elements.prototype
पर कॉपी करता है (जहां Elements
, Mooटूल के लिए खास तौर पर बना एपीआई है):
for (var key in Array.prototype) {
Elements.prototype[key] = Array.prototype[key];
}
for
-in
, “गिनती की जा सकने वाली” प्रॉपर्टी की जगह फिर से काम करता है. इनमें Array.prototype.sort
जैसे नेटिव तरीके शामिल नहीं हैं. हालांकि, इसमें Array.prototype.foo = whatever
जैसी नियमित रूप से असाइन की गई प्रॉपर्टी भी शामिल हैं. हालांकि, —
और यानी किकर. अगर किसी ऐसी प्रॉपर्टी को ओवरराइट किया जाता है जिसकी गिनती नहीं की जा सकती, जैसे कि
Array.prototype.sort = whatever
, तो इसकी गिनती नहीं की जा सकती.
फ़िलहाल, Array.prototype.flatten = mooToolsFlattenImplementation
गिनती की जा सकने वाली flatten
प्रॉपर्टी बनाता है. इसलिए, इसे बाद में Elements
में कॉपी कर दिया गया है. हालांकि, अगर ब्राउज़र flatten
का नेटिव वर्शन शिप करते हैं, तो उसे समझा नहीं जा सकता. साथ ही, उसे Elements
पर कॉपी नहीं किया जाता. Mooटूल'Elements.prototype.flatten
पर निर्भर कोई भी कोड अब काम नहीं कर रहा है.
हालांकि, ऐसा लगता है कि नेटिव Array.prototype.flatten
को संख्या के तौर पर बदलने से समस्या ठीक हो जाएगी. हालांकि, इससे सिस्टम के साथ काम करने से जुड़ी और भी समस्याएं आ सकती हैं. इसके बाद, for
-in
पर निर्भर हर वेबसाइट किसी अरे (यह गलत तरीका है, लेकिन ऐसा होता है) को फिर से लागू करने के लिए, flatten
प्रॉपर्टी के लिए अचानक से एक और लूप इटरेशन शुरू कर दिया जाएगा.
यहां सबसे बड़ी समस्या बिल्ट-इन ऑब्जेक्ट में बदलाव करने की है. नेटिव प्रोटोटाइप का दायरा बढ़ाना आम तौर पर आज के समय में एक गलत तरीका माना जाता है, क्योंकि यह दूसरी लाइब्रेरी और तीसरे पक्ष के कोड के साथ ठीक से काम नहीं करता. उन चीज़ों में बदलाव न करें जिन पर आपका मालिकाना हक नहीं है!
हम सिर्फ़ मौजूदा नाम को ही बनाए रखकर वेब का उल्लंघन क्यों नहीं करते?
साल 1996 में, सीएसएस के बड़े पैमाने पर उपलब्ध होने और “HTML5” बनने से काफ़ी पहले, Space Jam वेबसाइट लाइव हुई. आज भी वेबसाइट ठीक उसी तरह काम कर रही है जिस तरह 22 साल पहले करती थी.
ऐसा कैसे हुआ? क्या किसी ने इतने सालों से उस वेबसाइट को मैनेज किया और जब भी ब्राउज़र वेंडर जब भी कोई नई सुविधा भेजते हैं, तो क्या वह इसे अपडेट करता रहता है?
वेब पर ज़्यादा इस्तेमाल होने वाले एचटीएमएल, सीएसएस, JavaScript, और दूसरे सभी स्टैंडर्ड के लिए “वेब को न तोड़ें” सबसे सही डिज़ाइन सिद्धांत है. अगर ब्राउज़र की किसी नई सुविधा को शिपिंग करने से मौजूदा वेबसाइटें काम करना बंद कर देती हैं, तो यह सभी के लिए खराब है:
- प्रभावित वेबसाइटों पर जाने वाले लोगों को अचानक खराब उपयोगकर्ता अनुभव मिलना चाहिए;
- वेबसाइट के मालिकों ने बिना कोई बदलाव किए, एक बेहतरीन वेबसाइट बनाने की जगह काम न करने वाली वेबसाइट पर जाने की कोशिश की.
- इस नई सुविधा को भेजने वाले ब्राउज़र वेंडर की बाज़ार में हिस्सेदारी कम हो जाती है. ऐसा इसलिए होता है, क्योंकि उपयोगकर्ता, “यह ब्राउज़र X में काम करता है” पर ध्यान देने के बाद ब्राउज़र स्विच कर रहे हैं;
- काम करने से जुड़ी समस्या का पता लगने पर, दूसरे ब्राउज़र वेंडर इसे भेजने से मना कर देते हैं. सुविधा की जानकारी असलियत से मेल नहीं खाती (“कुछ भी नहीं, सिर्फ़ काल्पनिक है”), जिसे स्टैंडर्ड तय करने की प्रोसेस के लिए ठीक नहीं माना जाता.
हां, तो पुराने ज़माने में MooTool गलत है — लेकिन, वेब को तोड़ने से उन्हें किसी तरह की कोई परेशानी नहीं होती, बल्कि लोगों को सज़ा मिलती है. इन उपयोगकर्ताओं को यह नहीं पता होता कि मू टूल क्या है. इसके अलावा, हम दूसरा समाधान ढूंढ सकते हैं और उपयोगकर्ता वेब का इस्तेमाल करना जारी रख सकते हैं. इसका चुनाव करना आसान है.
क्या इसका मतलब यह है कि खराब एपीआई को वेब प्लैटफ़ॉर्म से कभी नहीं हटाया जा सकता?
यह कई बातों पर निर्भर करता है. बहुत कम मामलों में, खराब सुविधाओं को वेब से हटाया जा सकता है. यहां तक कि सिर्फ़ यह पता लगाना भी काफ़ी मुश्किल है कि किसी सुविधा को हटाना हो सकता है. इससे यह पता लगाया जा सकता है कि कितने वेब पेजों के काम करने के तरीके में बदलाव हुआ है. हालांकि, जब सुविधा ज़रूरत के हिसाब से असुरक्षित हो, उपयोगकर्ताओं के लिए नुकसानदेह हो या जब इसका इस्तेमाल बहुत ही कम किया जाता हो, तो ऐसा किया जा सकता है.
<applet>
, <keygen>
, और showModalDialog()
ऐसे खराब एपीआई के उदाहरण हैं जिन्हें वेब प्लैटफ़ॉर्म से हटा दिया गया है.
हम सिर्फ़ Mooटूल की समस्याओं को ठीक क्यों नहीं कर देते?
Mooटूल को पैच करना एक अच्छा आइडिया है, ताकि यह पहले से मौजूद ऑब्जेक्ट को फैला न सके. हालांकि, इससे समस्या का हल नहीं निकलता. भले ही Mootools को पैच किया गया वर्शन रिलीज़ करना हो, लेकिन इस वर्शन का इस्तेमाल करने वाली सभी मौजूदा वेबसाइटों को अपडेट करना होगा, ताकि कम्पैटबिलटी से जुड़ी समस्या हल न हो.
क्या लोग सिर्फ़ MooTool की कॉपी अपडेट नहीं कर सकते?
एक आदर्श दुनिया में, MooTool एक पैच रिलीज़ कर देता था और MooTool का इस्तेमाल करने वाली हर वेबसाइट अगले दिन शानदार तरीके से अपडेट हो जाती थी. समस्या हल हो गई, ठीक है?!
माफ़ करें, इस बात पर कोई भरोसा नहीं किया जा सकता. अगर कोई व्यक्ति किसी तरह से प्रभावित वेबसाइटों के पूरे सेट की पहचान कर लेता है, हर एक की संपर्क जानकारी खोजने में, सभी वेबसाइट मालिकों से संपर्क करके उनको अपडेट करने (यानी उनके पूरे कोड बेस को फिर से फिर से तैयार करने) के लिए मना लेता है, तो इस पूरी प्रक्रिया में कई साल लग सकते हैं.
ध्यान रखें कि इनमें से कई वेबसाइटें पुरानी हैं और उनका रखरखाव नहीं किया जाता है. अगर रखरखाव करने वाला व्यक्ति अब भी आपके आस-पास है, तो हो सकता है कि वह आप जैसे ज़्यादा कुशल वेब डेवलपर न हो. हम यह उम्मीद नहीं कर सकते कि सभी लोग अपनी 8 साल पुरानी वेबसाइट पर जाएं और उसे बदलेंगे.
TC39 प्रोसेस कैसे काम करती है?
TC39 वह कमिटी है जो ECMAScript स्टैंडर्ड की मदद से, JavaScript लैंग्वेज को बेहतर बनाने के लिए ज़िम्मेदार है.
#SmooshGate को देखकर कुछ लोगों को लगा कि “TC39, flatten
का नाम बदलकर smoosh
करना चाहता है”, लेकिन यह मज़ाक़ था, जिसे बाहरी लोगों के साथ शेयर नहीं किया गया.
प्रस्ताव का नाम बदलने जैसे अहम फ़ैसले आसानी से नहीं लिए जाते. साथ ही, इन्हें किसी एक व्यक्ति ने भी नहीं लिया होता है. साथ ही, GitHub पर दी गई एक टिप्पणी के आधार पर, इन्हें रातों-रात नहीं लिया जाता.
सुविधा के प्रस्तावों के लिए, TC39 एक साफ़ स्टेजिंग प्रोसेस पर काम करता है.
TC39 मीटिंग के दौरान, ECMAScript प्रस्तावों और उनमें होने वाले किसी भी बड़े बदलाव (नाम बदलने के तरीके सहित) पर चर्चा की जाती है. उनके आधिकारिक होने से पहले उन्हें पूरी कमिटी से मंज़ूरी लेनी होगी. Array.prototype.flatten
के मामले में, यह प्रस्ताव पहले ही कानूनी समझौते के कई चरणों से गुज़र चुका है. तीसरे चरण तक इससे पता चलता है कि यह सुविधा वेब ब्राउज़र में लागू की जा सकती है. लागू करने के दौरान खास जानकारी से जुड़ी
अन्य समस्याएं आना आम बात है. ऐसे में, उसे भेजने की कोशिश करने के बाद सबसे ज़रूरी सुझाव मिला: यह सुविधा अपनी मौजूदा स्थिति में वेब को तोड़ती है. इस तरह की समस्याओं का अनुमान लगाना मुश्किल होता है. इस वजह से भी TC39 प्रोसेस, ब्राउज़र के ज़रिए कोई सुविधा शिप करने के बाद ही खत्म नहीं हो जाती.
TC39, सहमति के आधार पर काम करता है. इसका मतलब है कि किसी भी नए बदलाव पर कमिटी को अपनी सहमति देनी होगी. भले ही smoosh
ने गंभीर सुझाव दिया हो, लेकिन
ऐसा लगता है कि कमिटी का कोई सदस्य compact
या chain
जैसे सामान्य नाम के पक्ष में इस पर आपत्ति जताता.
flatten
के नाम को बदलकर smoosh
करने (भले ही यह कोई चुटकुला न हो) पर कभी भी TC39 की मीटिंग में चर्चा नहीं की गई है. फ़िलहाल, इस विषय पर TC39 का आधिकारिक नज़रिया पता नहीं है. कोई भी एक व्यक्ति TC39 के सभी सदस्यों की ओर से तब तक बात नहीं कर सकता,
जब तक अगली मीटिंग में इस पर सबकी सहमति नहीं हो जाती.
आम तौर पर, TC39 मीटिंग में अलग-अलग बैकग्राउंड वाले लोग शामिल होते हैं. कुछ लोगों को प्रोग्रामिंग लैंग्वेज डिज़ाइन का अनुभव होना चाहिए. कुछ लोग ब्राउज़र या JavaScript इंजन पर काम कर रहे होते हैं. इसके अलावा, JavaScript डेवलपर समुदाय का प्रतिनिधित्व करने के लिए, ऐसेट की संख्या बढ़ रही है.
आखिरकार, SmooshGate को कैसे हल किया गया?
मई 2018 की TC39 मीटिंग के दौरान, flatten
का नाम बदलकर flat
करके #SmooshGate को आधिकारिक तौर पर हल कर लिया गया था.
Array.prototype.flat
और Array.prototype.flatMap
, V8 v6.9 और Chrome 69
में शिप किए गए हैं.