JavaScript का जन्म और मृत्यु (2014)

 (destroyallsoftware.com)
1 पॉइंट द्वारा GN⁺ 6 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 1995 से 2035 तक JavaScript और programming के इतिहास को SF·कॉमेडी·गंभीर व्याख्यान के रूप में पेश किया गया है
  • दायरा सिर्फ JavaScript तक सीमित नहीं है, बल्कि programming के पूरे इतिहास तक फैला हुआ है
  • JavaScript के बारे में पक्ष या विपक्ष में खड़े हुए बिना तटस्थ दृष्टिकोण अपनाया गया है
  • भाषा की कमियों पर ईमानदारी से चर्चा करते हुए भी industry पर उसके अंतिम प्रभाव को बहुत सकारात्मक माना गया है
  • मुख्य संदेश यह है कि JavaScript ने अपनी कमियों के बावजूद programming industry पर बहुत बड़ा सकारात्मक प्रभाव छोड़ा

व्याख्यान का अवलोकन

  • JavaScript और programming के व्यापक इतिहास को 1995 से 2035 तक ट्रैक करने वाले प्रारूप में प्रस्तुत किया गया है
  • व्याख्यान का स्वरूप SF, कॉमेडी और पूरी तरह गंभीर व्याख्यान का मिश्रण है
  • यह JavaScript के समर्थन या विरोध में दिया गया व्याख्यान नहीं है, और इसे किसी एक पक्ष की स्थिति में समेटा नहीं गया है
  • JavaScript की कमियों पर खुलकर बात की गई है, लेकिन industry पर उसके अंतिम प्रभाव का मूल्यांकन बहुत सकारात्मक रूप में किया गया है

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

1 टिप्पणियां

 
GN⁺ 6 시간 전
Hacker News की राय

  • इसने 2020~2025 में वैश्विक आपदा आने की भविष्यवाणी तो काफ़ी सटीक की थी, बस आपदा का प्रकार गलत निकला, यह अच्छी बात है(?)
    बिल्कुल JavaScript जैसा

    • इसे लगभग NaN% सटीकता कहा जा सकता है

  • हैरानी है कि अभी तक किसी ने यह नहीं कहा कि इस शख्स ने हमें यह शाहकार दिया
    अगर नहीं देखा है, तो जो कर रहे हैं उसे रोककर इसे देखें। आज के दिन के सबसे बेहतरीन 5 मिनट की गारंटी है
    https://www.destroyallsoftware.com/talks/wat

    • इनके सारे टॉक्स शानदार हैं
      Boundaries सॉफ्टवेयर आर्किटेक्चर पर मैंने जो भी वीडियो देखे हैं, उनमें सबसे ज़्यादा insightful था, और आज भी जटिल applications डिज़ाइन करते समय उसकी सीख याद आती है
      यह उन लोगों के लिए भी एक अच्छा शुरुआती संसाधन है जो हर जगह बिखरी state के साथ imperative logic के आदी हैं और functional programmer की तरह सोचना सीखना चाहते हैं
      https://www.destroyallsoftware.com/talks/boundaries
    • इस प्रेज़ेंटेशन में कुछ गलतियां हैं, और मैंने जो देखीं उनमें से सिर्फ़ दो लिख रहा हूँ
      Array(16) कॉल करने के बाद वह कहता है कि 16 separators हैं, लेकिन असल में सिर्फ़ 15 हैं, इसलिए Batman वाला मज़ाक थोड़ा टूट जाता है
      और {}+[] का इस्तेमाल करके यह समझाता है कि object में list जोड़ रहे हैं, फिर यह कहकर मज़ाक उड़ाता है कि नतीजा []+{} से अलग है जो [object Object] देता है, लेकिन असल में अगर ({}+[]) लिखा जाए तो वह भी [object Object] देता है
      {}+[] अलग क्यों है, इसे पहेली के रूप में छोड़ता हूँ। संकेत: Gurer vf ab bowrpg gurer.

  • JavaScript सच में compile target बन गया, उस समय वीडियो में asm.js था, लेकिन अब WebAssembly आ चुका है
    इसे वास्तविक रूप से लागू होते और native के क़रीब चलते देखकर लगता है कि भविष्यवाणी काफ़ी हद तक सही थी
    मैं ज़्यादातर TypeScript इस्तेमाल करता हूँ, और Electron की वजह से web technologies desktop apps में पैक होकर web syntax को सामान्य programs के भीतर भी ले आई हैं
    Electron को भारी और कमज़ोर कहा जाता है, लेकिन Mac·Windows·Linux को एक साथ support करने का यह सबसे तेज़ तरीक़ा भी है
    यहाँ “मौत” का मतलब यह है कि JavaScript को सीधे लिखना कम हो जाएगा, लेकिन वह हर जगह मौजूद foundation layer बन जाएगा, और मुझे लगता है कि असल में यही हुआ है

    • Flutter भी है, और यह सिर्फ़ desktop operating systems ही नहीं बल्कि iOS और Android को भी support करता है
      development speed भी काफ़ी तेज़ मानी जा सकती है
      हालांकि Electron या native apps के मुक़ाबले performance कैसी है, यह मुझे ठीक से नहीं पता
      अगर टीम छोटी हो, तो speed optimization से ज़्यादा असल में ship करना कहीं बेहतर होता है
    • JavaScript एक तरह से नई assembly layer है
      compiler परिभाषा के अनुसार इंसानों द्वारा पढ़े जा सकने वाले code को machine code में बदलता है
      JavaScript का फ़ायदा यह है कि Google ने V8 के साथ इसे हद तक धकेला, NodeJS ने backend में एक आकर्षक environment बनाया, और फिर यह PDF की तरह हर जगह मौजूद हो गया—एक बार लिखो, हर जगह चलाओ
      WebAssembly पर अब तक इसकी बढ़त का कारण भी यही बहुमुखीपन है, क्योंकि WebAssembly, JavaScript जितना व्यापक रूप से उपलब्ध नहीं है
      आजकल JavaScript लगभग TypeScript का पर्याय बन गया है, और यह बहुत बड़ी छलांग थी। यहाँ छिपा हुआ हीरो मेरे हिसाब से Angular 2 था
      Angular ने शुरू से TypeScript चुना, हालांकि native JavaScript version भी दिया, लेकिन सच कहें तो वह version लगभग इस्तेमाल लायक नहीं था और उस समय उसकी काफ़ी आलोचना हुई थी
      दिलचस्प बात यह है कि React आख़िरी शरणस्थल है जो TypeScript को default विकल्प के रूप में सामने नहीं रखता, लेकिन NextJS जैसे बड़े projects पहले से ही मूल रूप से TypeScript पर निर्भर हैं, इसलिए ReactJS भी आख़िरकार झुक जाएगा
      यह पहली बार नहीं है कि innovation पहले दूसरे projects में आती है और ReactJS बाद में उसका पीछा करता है; यहाँ भी मुझे लगता है Angular आगे है
      JavaScript और Python चुनो, तो बहुत बड़ी गलती होने की संभावना कम रहती है
    • अगर उस “मौत” का मतलब यह है कि JavaScript सीधे इस्तेमाल न होकर सिर्फ़ foundation layer बन जाए, तो शायद यह मेरी timeline नहीं है
      लोग अब भी बहुत बड़ी मात्रा में JS सीधे लिख रहे हैं, और WebAssembly ने भी अभी तक web applications के सामान्य runtime environment पर कब्ज़ा नहीं किया है
      ऐसी कंपनियों के उदाहरण मिल सकते हैं जो WebAssembly के ऊपर कुछ बना रही हैं, लेकिन उसे Gary द्वारा कही गई तरह के बड़े बदलाव के साथ नहीं मिलाना चाहिए
    • वीडियो की बातों में JIT इतना अच्छा हो गया था कि उसने virtual memory और memory protection को ही हटा दिया
      ऐसा बिल्कुल नहीं हुआ
    • अगर website ही काफ़ी है, तो app बनाने की ज़रूरत क्यों है?
      उसके लिए कई web browsers चलाने की भी ज़रूरत नहीं है

  • हर कुछ साल में लोग बेहतर JavaScript ईजाद करते हैं, और फिर उसे वापस JavaScript में transpile कर देते हैं

    • बड़े पैमाने पर adoption हमेशा अच्छी design पर भारी पड़ता है
    • आख़िर में सब कुछ assembly code ही है
      JavaScript में compile करने में अपने आप में कोई बुनियादी समस्या नहीं है, और high-level languages वे कई guarantees लागू कर सकती हैं जो शुद्ध JavaScript सीधे नहीं देती
      अब तक जिन लगभग सभी language guarantees का हमने इस्तेमाल किया है, वे raw assembly में टूट सकती हैं

  • समस्या यह है कि यहाँ जितनी तेज़ प्रगति की भविष्यवाणी की गई थी, Wasm की रफ़्तार उतनी नहीं रही
    DOM manipulation न होने की वजह से अब भी JS को glue code की तरह इस्तेमाल करना पड़ता है, या फिर HTML और CSS को पूरी तरह छोड़कर Flutter या कुछ Rust GUI की तरह सब कुछ canvas पर render करना पड़ता है
    लेकिन web की feature set खो देना अफ़सोस की बात है

    • Flutter चुनने वाले लोग शायद यह मानेंगे कि हर browser में canvas से मिलने वाली consistency, अलग-अलग तरीके से लागू web feature sets पाने से ज़्यादा क़ीमती है
    • DOM और JS को अलग नहीं किया जा सकता
      DOM API को इस धारणा के साथ डिज़ाइन किया गया था कि उसे JS से access किया जाएगा, और JS का डिज़ाइन और उसकी कुछ “अनोखी” विशेषताएँ भी आंशिक रूप से DOM के साथ काम करने के लिए ही बनीं
    • JS, WASM की तुलना में कहीं ज़्यादा सुलभ है
      इसे तुरंत debug किया जा सकता है, LLM में डालकर देखा जा सकता है, और किसी wrapper की ज़रूरत भी नहीं होती, इसलिए इसके साथ छेड़छाड़, प्रयोग और काम करना बहुत आसान है

  • 2014 में Canadian Undergraduate Software Engineering Conference(CUSEC) में Gary Bernhardt का यह टॉक लाइव देखा था
    PNaCl ठीक एक साल पहले आया था, और Google इसे Chrome और ChromeOS के अंदर OpenSSH और RDP clients को cross-compile, run और sandbox करने के लिए इस्तेमाल कर रहा था, जबकि Mozilla/Firefox ने उसके जवाब में asm.js प्रस्तावित किया था
    उस समय यह बस मज़ेदार लगा था, लेकिन अब पीछे मुड़कर देखें तो हैरानी होती है कि उन विचारों का काफ़ी हिस्सा बचा रह गया

  • Gary Bernhardt का Wat lightning talk मेरे पसंदीदा प्रेज़ेंटेशनों में से एक था
    यह इस लेख के शीर्षक वाले टॉक से मुश्किल से 2 साल पहले का है
    [1]: https://www.destroyallsoftware.com/talks/wat

  • लगभग सब कुछ स्क्रिप्ट के मुताबिक हुआ
    अब बस ब्राउज़र टेक्नोलॉजी पर पूरी तरह आधारित किसी और operating system या WASM OS का इंतज़ार करना है
    webOS और Firefox OS कम से कम अपने समय से 20 साल आगे थे

    • बिल्कुल नहीं
      WASM उस दावे की पुष्टि नहीं करता, बल्कि उसका खंडन करता है
      उस दावे का मतलब यह है कि JavaScript-compatible source भविष्य की नींव बनेगा, और यह कि भले ही सामान्य JavaScript एक बहुत खराब आधार हो, JavaScript engines जो किसी compatible subset को efficiently interpret करने के लिए बहुत ज़्यादा optimized हैं, वे भविष्य का general-purpose platform बन सकते हैं
      WASM इसे बुनियादी रूप से ठुकराता है, क्योंकि वह एक नया आधार बनाता है जो JavaScript-compatible नहीं है और जिसे low-level target बनने के लिए design किया गया है
      यह कहना कि WASM उस दावे की पुष्टि करता है, उतना ही अजीब है जितना यह कहना कि ऐसा भविष्य, जहाँ सबके पास ब्राउज़र के अंदर Rust interpreter हो, उस दावे की पुष्टि करता है
      अगर आप ऐसा कहते हैं, तो आखिरकार आप सिर्फ यही कह रहे हैं कि web browsers किसी भी भाषा में किसी भी तरह का code चलाएँगे, और वे पहले से ही यही कर रहे हैं
      वीडियो साफ़ तौर पर “चौंकाने वाली” संभावनाओं की बात करता है, इसलिए यह मानना कि वह सामान्य रूप से हर संभव भविष्य से भी मेल खाता है, तर्कसंगत नहीं है
    • क्या ChromeOS का ज़िक्र न करने की कोई तकनीकी वजह है?
      मैं यह सिर्फ़ जिज्ञासा से पूछ रहा हूँ
      और webOS के जो screenshots मैंने देखे हैं, उन्होंने मुझे उसके पुनर्जीवन की कामना कराई है। सिर्फ़ smart TV में नहीं, बल्कि दूसरी जगहों पर भी

  • Bernhardt की 2035 timeline का आधा हिस्सा हम पहले ही पार कर चुके हैं
    JavaScript अभी मरा नहीं है, लेकिन ऐसा ज़रूर लगता है कि वह WebAssembly के भीतर अपना शोकलेख खुद लिख रहा है

    • आपके परिवार की कई पीढ़ियाँ मर जाने के बाद भी संभव है कि आख़िरी JS instruction अभी भी चल रहा हो
      जब तक वैश्विक परमाणु युद्ध नहीं होता, मैं इस पर दांव लगाऊँगा कि JS ज़्यादातर इंसानों से ज़्यादा समय तक ज़िंदा रहेगा
    • मैं हर महीने कई ग्राहकों की sites की समीक्षा करता हूँ, और वे सब किसी न किसी रूप में JavaScript इस्तेमाल करती हैं
      PHP की तरह यह कभी नहीं मरेगा

  • JavaScript अब तक की सबसे महान programming language है