क्या JavaScript को 2 भाषाओं में विभाजित किया जाना चाहिए?

 (devclass.com)
9 पॉइंट द्वारा GN⁺ 2024-10-28 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • Google के एक इंजीनियर ने आधिकारिक standardization committee के सामने JavaScript को दो भाषाओं में विभाजित करने का प्रस्ताव पेश किया
    • प्रस्ताव है कि इसे runtime engine में implement होने वाले core और compiler tools पर निर्भर अधिक फीचर्स वाले एक variant में बांटा जाए
  • यह प्रस्तुति इसी महीने की शुरुआत में हुई Ecma TC39 बैठक में दी गई
    • TC39, Ecma International की वह समिति है जो JavaScript (औपचारिक रूप से ECMAScript) specification को आगे बढ़ाती है
  • प्रस्तुति Google के Shu-yu Guo ने दी, और स्लाइड्स Mozilla, Apple, Moddable और Sony के सह-लेखकों के साथ मिलकर तैयार की गईं
    • Shu-yu, JIT, VM, compiler और standardization के विशेषज्ञ हैं
  • लेखकों के तर्क
    • भाषा के नए फीचर लगभग हमेशा security को खराब करते हैं, और performance पर तटस्थ या नकारात्मक असर डालते हैं
    • reliability कभी-कभी खराब होती है, और app functionality केवल तब बेहतर होती है जब डेवलपर नए फीचर्स का उपयोग करें
    • JavaScript VM (virtual machine) गति के दबाव के कारण पहले ही बहुत जटिल हो चुका है, और इससे security से समझौता होता है. साथ ही, जब नए फीचर्स अपनाए नहीं जाते, तब यह और भी बुरा लगता है
    • security flaws और runtime की 'complexity cost' अरबों उपयोगों को प्रभावित करती है, जबकि इसके लाभ वास्तव में केवल उन्हीं डेवलपर्स और applications तक सीमित रहते हैं जो इस जटिलता का उपयोग करते हैं, इसलिए JavaScript की आधारभूत तकनीक सरल होनी चाहिए
  • इसमें कई संगठन शामिल हैं, लेकिन यह initiative कुछ हद तक Google-नेतृत्व वाला दिखाई देता है
    • एक स्लाइड में यह disclaimer शामिल है: "यह संभावित समाधान Google का पसंदीदा समाधान है और जरूरी नहीं कि अन्य implementers का भी समाधान हो"
  • प्रस्तावित समाधान
    • मौजूदा फीचर्स को वापस लेने के बजाय, आगे से अधिकांश नए फीचर्स को engine में नहीं बल्कि tools में implement करने के लिए approach बदलना
    • engine में implement होने वाली भाषा को "JS0" और tools में implement होने वाली भाषा को "JSSugar" कहा गया है
    • यह JavaScript के लिए विशेष रूप से उपयुक्त विचार है, क्योंकि कई डेवलपर वास्तव में TypeScript में कोड लिखते हैं और Babel, Webpack, TypeScript compiler जैसे compilers पर निर्भर रहते हैं
    • यदि इसे अपनाया गया, तो भविष्य के syntax फीचर्स JSSugar में जाएंगे, जबकि केवल API और functional फीचर्स ही JS0 में जाएंगे
    • compatible engines को केवल JS0 को support करना होगा
    • JSSugar को support करने का बोझ tool implementers पर स्थानांतरित हो जाएगा
      • इसके एक side effect के रूप में, tool implementers को standard process में अधिक शामिल होना पड़ेगा और शायद एक नया technical group बनाना पड़ सकता है
  • यह प्रस्ताव पहले से ही विवादास्पद है
    • कुछ डेवलपर्स मांग कर रहे हैं कि JavaScript tools को आधिकारिक दर्जा न दिया जाए, और कई JavaScript डेवलपर इन tools पर कम निर्भर रहना चाहते हैं
    • security, performance और reliability को प्राथमिकता देने पर व्यापक सहमति है, लेकिन JavaScript को मध्यवर्ती tools पर निर्भर बनाने की अवधारणा लोकप्रिय नहीं है
    • एक डेवलपर ने तो "RIP Vanilla JS" भी कहा

GN⁺ की राय

  • यह प्रस्ताव JavaScript development ecosystem में बड़ा बदलाव ला सकता है. इस बात को लेकर चिंता है कि डेवलपर्स को नए syntax फीचर्स इस्तेमाल करने के लिए compilers पर अधिक निर्भर होना पड़ेगा
  • हालांकि, runtime engine की जटिलता कम करने और security व performance सुधारने का लक्ष्य अपने आप में सकारात्मक है. लंबे समय में यह JavaScript के विकास में मदद कर सकता है
  • इसी तरह का approach अपनाने वाली दूसरी भाषा Dart है. Dart डेवलपर-फ्रेंडली syntax देती है और JavaScript में compile होकर browser में चलती है
  • इस प्रस्ताव को अपनाते समय existing code के साथ compatibility, developer experience, tool support जैसे विभिन्न कारकों पर सावधानी से विचार करना होगा. साथ ही, community की राय को पर्याप्त रूप से शामिल करने की प्रक्रिया भी जरूरी होगी
  • JavaScript वेब development की आधारभूत भाषा है, इसलिए आगे भी इस पर सक्रिय चर्चा और विकास जारी रहने की उम्मीद है

संबंधित पढ़ाई

4 टिप्पणियां

 
kandk 2024-10-29

लगता है कि वे एक और layer जोड़कर उस layer में DX को बेहतर बनाने वाली चीजें जोड़ना चाहते हैं।
 
savvykang 2024-10-29

बहुत से JavaScript डेवलपर इन टूल्स पर कम निर्भर रहना चाहते हैं
JavaScript को मध्यवर्ती टूल्स पर निर्भर बनाने वाला विचार लोकप्रिय नहीं है

अभी सिर्फ JSX को ही लें, तो पूरा ecosystem इस तरह बना है कि transpile की ज़रूरत पड़े, इसलिए मुझे यह अव्यावहारिक राय लगती है। लगता है वे मानते हैं कि NodeJS ही सब कुछ है।
 
aer0700 2024-10-29

शायद मैंने इसे पूरी तरह सही समझा है या नहीं, पता नहीं, लेकिन C++ में BOOST नाम की एक चीज़ है, तो यह कुछ वैसा ही महसूस होता है। अगर Google का प्रस्ताव मान लिया जाता है और मौजूदा लाइब्रेरीज़ को JSSugar में इंटीग्रेट किया जाता है, तो उसमें क्या-क्या जाएगा? Babel?
 
GN⁺ 2024-10-28
Hacker News की राय

  • Java का Hotspot VM दूसरी भाषाओं के लिए बड़ी सफलता लेकर आया। JavaScript के लिए भी core language को target करना और syntactic sugar को pre-compile करना तर्कसंगत है

    • JavaScript दो भाषाओं में बंटा हुआ है: इंटरनेट की assembly language के रूप में JavaScript, और frontend web development language के रूप में JavaScript
    • नए language features को उन हिस्सों में transpile करना बेहतर है जो मौजूदा runtime में अच्छी तरह supported और optimized हैं। इसके लिए transpiling की ज़रूरत पड़ती है, लेकिन यह आधुनिक build tools इस्तेमाल करने जैसा ही है

  • WebAssembly पर ध्यान केंद्रित करना बेहतर है। JavaScript को scripting के लिए इस्तेमाल करना चाहिए, और बड़े applications के लिए दूसरी भाषाओं का उपयोग होना चाहिए

  • VanillaJS पसंद करने वाले व्यक्ति के रूप में, जबरन बदले जाने वाले language features को लेकर असंतोष है। API सुधारों पर ध्यान देना चाहिए ताकि web apps native apps के बराबर हो सकें

  • BigInt के लिए कोई use case नहीं है, इस दावे से असहमति है। भले ही Google के frontend developers इसका उपयोग न करें, दूसरे JS developers इसका इस्तेमाल कर रहे हैं। language evolution पर ध्यान देना चाहिए

  • JavaScript और Wasm को अलग रखा जाना चाहिए था। इसके बजाय Wasm को ऐसा second-class citizen बना दिया गया जिसे web API access नहीं मिल सकता

  • प्रस्तावित समाधान मूल समस्या को हल नहीं करता और tools पर निर्भरता बढ़ाता है। performance और complexity कम करने के लिए JavaScript को किसी नई भाषा में बदलना चाहिए

  • TC39 और developer community के बीच अलगाव के कारण समस्याएँ पैदा हो रही हैं। TypeScript tools standardized नहीं हैं, और इसे Rust में port करने की भी कोई योजना नहीं है

  • Google के V8 engine के maintenance issues के कारण JavaScript changes का प्रस्ताव किया गया है। security issues और complexity cost का असर users पर पड़ता है। C++ की जगह किसी दूसरी भाषा को आज़माना चाहिए