Figma की TypeScript में यात्रा

 (figma.com)
5 पॉइंट द्वारा GN⁺ 2024-05-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Figma का TypeScript में सफर: कस्टम प्रोग्रामिंग भाषा को कंपाइल करके हटाना

  • Figma ने मोबाइल रेंडरिंग आर्किटेक्चर के मुख्य हिस्से को Skew नाम की custom programming language में लिखा था
    • इसे रनटाइम/प्लेयर इंजन में अतिरिक्त performance पाने के लिए बनाया गया था
    • बताया गया है कि उन्होंने एक भी दिन का डेवलपमेंट रुके बिना Skew को स्वचालित तरीके से TypeScript में कैसे migrate किया

Skew भाषा की शुरुआत और सीमाएँ

  • Skew Figma में शुरू में एक side project था
    • उस समय दोनों यानी web और मोबाइल पर चलने वाला prototype viewer जल्दी बनाना जरूरी था
    • यह एक पूरी तरह कंपाइल होने वाली JavaScript प्रोग्रामिंग भाषा बन गई, जो बेहतर optimization और तेज़ compile time को संभव बनाती थी
  • समय के साथ Skew code जमा होने पर उसकी सीमाएँ साफ दिखने लगीं
    • नए इंजीनियरों के लिए इसे समझना मुश्किल था
    • बाकी codebase के साथ आसान integration नहीं हो पाती थी
    • Figma के बाहर developer ecosystem सीमित था
    • स्केल होने पर विस्तार की कठिनाइयाँ उसके शुरुआती लाभ पर भारी पड़ने लगीं

TypeScript में माइग्रेशन को संभव बनाने वाले कारण

  • मोबाइल ब्राउज़र में WebAssembly सपोर्ट का विस्तार
  • Skew इंजन के core components को C++ इंजन के संबंधित components से replace किया गया
    • TypeScript पर जाने से performance loss काफी कम हुआ
  • टीम के बढ़ने से developer experience पर ध्यान देने के लिए संसाधन अलग करना संभव हुआ

codebase परिवर्तन की प्रक्रिया

  • लक्ष्य: Skew का पूरा codebase TypeScript में बदलना
    • manual rewrite की बजाय automated migration चुना गया
    • डेवलपमेंट स्पीड गिरने से रोकना और users के लिए runtime errors या performance drops से बचना
  • 3 चरणों वाला rollout process
    1. Skew authoring, Skew build
      • original build process वही रखा गया, transpiler बनाया गया, और TypeScript code को GitHub में check-in किया गया
    2. Skew authoring, TypeScript build
      • production traffic rollout सीधे TypeScript codebase से शुरू किया गया
      • डेवलपर अभी भी Skew लिखते रहे, और transpiler Skew को TS में बदलता रहा
    3. TypeScript authoring, TypeScript build
      • development के लिए TS code को source of truth बनाना
      • autogenerated process रोककर codebase से Skew code हटाया गया

ट्रांसपाइलर पर नोट्स

  • कम्पाइलर frontend और backend से बना था
    • frontend: इनपुट code को parse करके समझना, type checking और syntax checking करना
    • इसे IR (intermediate representation) में बदलना - ताकि original code का semantics और logic पूरी तरह capture हो जाए
    • backend: IR को अलग-अलग target languages में बदलना
  • ट्रांसपाइलर एक special type का compiler है जो human-readable code generate करता है

माइग्रेशन के दौरान सामने आई चुनौतियाँ

  • array destructuring की perf समस्या
    • JavaScript array destructuring न use करने पर लगभग 25% तक performance बेहतर हो सकता है
  • Skew की "devirtualization" optimization
    • rollout में अतिरिक्त चरण जोड़कर सुनिश्चित किया गया कि devirtualization codebase के behavior को break न करे
  • TypeScript में initialization order बहुत important होता है
    • ट्रांसपाइलर को ऐसा code generate करना होगा जो इस order का सम्मान करे

डेवेलपर अनुभव के लिए Source Map का उपयोग

  • migration आसान करने और debugging smooth रखने के लिए डेवलपर productivity पर फोकस किया गया
  • Source Maps से compiled code और source code को लिंक किया गया
    • ब्राउज़र सिर्फ JavaScript समझता है
    • Source Map के जरिए ब्राउज़र को पता चलता है कि compiled JavaScript bundle में source code के किस स्थान पर breakpoint रुकना चाहिए
  • 3 चरण की प्रक्रिया में Source Map निर्माण
    1. TypeScript → JavaScript source map बनाना
    2. प्रत्येक Skew source file के लिए Skew → TypeScript source map बनाना
    3. source maps को compose करके Skew से JavaScript mapping बनाना

conditional compilation का केस

  • Skew में top-level "if" statement से conditional compilation की अनुमति थी
    • compile-time constants से conditions सेट की जाती थीं
    • একই codebase के अलग-अलग build targets define करने का विकल्प मिलता था
  • TypeScript में conditional compilation मौजूद नहीं है
    • इसे bundling चरण में shift किया गया
    • esbuild के "defines" और dead code elimination फीचर का उपयोग किया गया
    • bundle size में थोड़ा बढ़ोतरी साइड-इफेक्ट के रूप में आई

TypeScript युग में प्रोटोटाइपिंग डेवेलपमेंट

  • Skew code को TypeScript में migrate करके Figma की core codebase को आधुनिक बनाया गया
    • अंदरूनी और बाहरी code के साथ कहीं ज्यादा आसान integration का रास्ता खुला
    • डेवलपर्स को अधिक कुशल तरीके से काम करने में मदद मिली
  • उस समय TypeScript शायद best choice नहीं था, लेकिन अब यह निश्चित रूप से सही विकल्प है
  • TypeScript migration के सारे फायदे लेने के लिए आगे का work जारी है
    • बाकी codebase के साथ बेहतर integration
    • package management बहुत आसान हुआ
    • TypeScript ecosystem की नई features सीधे उपयोग करना आदि

GN⁺ के विचार

  • Figma ने अपनी custom language Skew से TypeScript में बदलने की प्रक्रिया बहुत systematized और चरणबद्ध तरीके से की। बिना कोई डेवलपमेंट डाउntime लिए automated migration करना प्रभावशाली रहा। कंपनी के बढ़ने पर जमा होने वाले technical debt को संभालने और बदलते ecosystem के साथ sync होने का यह अच्छा example है।

  • एक custom language से generic language की तरफ़ शिफ्ट, खासकर performance-first design से, WebAssembly जैसी तकनीकी बदलावों से संभव हुआ। किसी technology को चुनते समय सिर्फ तुरंत ज़रूरत नहीं, बल्कि उसकी future direction और evolution को भी देखना ज़रूरी है।

  • डेवलपर अनुभव पर फोकस करते हुए Source Maps का उपयोग, conditional compilation को handle करने के तरीके जैसे कई practical details यहाँ दिए गए हैं, जो उपयोगी हैं। पुराने legacy के साथ compatibility रखते हुए धीरे-धीरे migration करना खास असरदार लगता है।

  • इतने बड़े codebase में ऐसा काम करने के लिए automated code converter अनिवार्य होता है। Skew compiler से बना transpiler इस काम का core था। इसमें compiler theory और internal implementation की solid understanding जरूरी है।

  • programming language migration सिर्फ code बदलने का काम नहीं है; इसका असर पूरी development culture और ecosystem पर पड़ता है। इसे सावधानी से करना चाहिए, लेकिन अगर organization में capacity हो तो यह एक meaningful challenge हो सकता है.

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

1 टिप्पणियां

 
GN⁺ 2024-05-05
Hacker News टिप्पणी

  • Andrew Chan, जो इस प्रोजेक्ट में जुड़े थे, के अनुसार Figma लगभग 10 वर्षों तक अन्य हिस्सों में TypeScript इस्तेमाल करता रहा, और अधिकांश समय Skew की तुलना में TypeScript ज़्यादा था। Skew केवल मोबाइल इंजिन, प्रोटोटाइपिंग प्लेयर और मिररिंग जैसी कुछ उत्पाद शृंखलाओं में इस्तेमाल हुआ था।

  • यह आश्चर्यजनक था कि Figma के पास JavaScript के लिए एक कस्टम भाषा थी, और यह और भी आश्चर्य की बात थी कि वह TypeScript से तेज़ था। बाद में उन्होंने इसे धीमे TypeScript पर माइग्रेट कर दिया।

  • पूर्व Figma CTO Evan Wallace के अनुसार, Skew अधिक सख्त type system की वजह से बेहतर optimization संभव होने के कारण TypeScript से लगभग 1.5~2 गुना तेज था।

  • array destructuring के दौरान JavaScript का सीधे array indexing करने के बजाय array पर iteration करने वाला iterator बनाना दिलचस्प है। मुझे समझ नहीं आता कि JavaScript सीधे indexing क्यों नहीं करता।

  • ऐसा लगता है कि Skew में सिर्फ callbacks थे। async/await जैसे आधुनिक JavaScript फीचर और अधिक flexible type system का भी जिक्र किया गया था।

  • Figma ने custom TypeScript DSL + compiler लिखकर permissions जैसी security समस्याओं को सुलझाया।

  • बड़ी कंपनियों के पास अपनी-अपनी internal tools, languages और Kubernetes होते हैं, लेकिन उन्हें शेयर न करना एक अफ़सोस की बात है। अगर Skew open source होता, तो शायद बेहतर TypeScript बन सकता था।

  • Figma के WebAssembly इस्तेमाल करने के कारण को लेकर उत्सुकता है।

  • सीख: कस्टम भाषा मत बनाइए।

  • TypeScript के खिलाफ राय दिलचस्प लगी। TypeScript लगभग हर लाइन code में सुधार लाने वाला टूल है और इसके नुकसान लगभग न के बराबर हैं। लगता है कि विरोध करने वाले शायद नया सीखने से डरते हैं, या समय नहीं देना चाहते, या इसकी उपयोगिता को गलत समझते हैं। अगर हम सच में TypeScript विरोधियों से सहमत हैं, तो इसके कारणों पर और गहराई से सोचना होगा; नहीं तो बड़ा नुकसान उठाना पड़ेगा।