𝗧𝗵𝗲 𝗕𝗶𝗿𝘁𝗵 𝗮𝗻𝗱 𝗗𝗲𝗮𝘁𝗵 𝗼𝗳 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁
JavaScript உலாவியில் குறைந்த அதிகாரங்களுடன் இயங்குகிறது. இருப்பினும், இது சர்வர்கள், பில்ட் டூல்கள் (build tools) மற்றும் பைப்லைன்களை (pipelines) இயக்குகிறது. இது திட்டமிடப்பட்ட ஒன்றல்ல. இது 1995-இல் எடுக்கப்பட்ட ஒரு முடிவின் மீது மேற்கொள்ளப்பட்ட தொடர்ச்சியான திருத்தங்களே (patches) ஆகும்.
இது ஏன் நடந்தது என்பதைப் புரிந்துகொள்வது, இன்று நீங்கள் உங்கள் ஸ்டேக்கை (stack) வடிவமைக்கும் முறையை மாற்றும்.
கேரி பெர்ன்ஹார்டின் (Gary Bernhardt) 2014 உரையானது கடந்த கால நினைவுகளைப் பற்றியது அல்ல. அது கட்டமைப்பு ரீதியான உராய்வை (architectural friction) கண்டறியும் ஒரு பகுப்பாய்வு. அவர் ஒரு முரண்பாடான சுழற்சியைக் குறிப்பிட்டார்: JavaScript ஒரு விளையாட்டு மொழியாக (toy language) இருந்தது, ஆனால் உலாவியில் அதன் ஏகபோக உரிமை (monopoly) இருந்ததால் அது உயிர் பிழைத்தது. அந்த ஏகபோக உரிமைதான் அதை உலகில் அதிகம் பயன்படுத்தப்படும் மொழியாக மாற்றியது.
இதில் உள்ள சிக்கல் எளிமையானது. உலாவியானது குறியீட்டை (code) பாதுகாப்பாகவும் வேகமாகவும் இயக்க வேண்டும். இந்த இரண்டு இலக்குகளும் ஒன்றுக்கொன்று முரணானவை.
2014-இல், WebAssembly ஆனது JavaScript-ஐ மாற்றீடு செய்யும் என்று எதிர்பார்க்கப்பட்டது. அது முழுமையாக நடக்கவில்லை. WebAssembly என்பது Figma அல்லது Google Earth போன்றவற்றுக்கு நிலையானது மற்றும் பயனுள்ளது. ஆனால் ஒரு பயன்பாட்டு மொழியாக (application language) அது JavaScript-ஐ மாற்றவில்லை.
மாறாக, JavaScript உருமாறியது. பெர்ன்ஹார்ட் கண்டறிந்த உராய்வுகளைச் சரிசெய்ய TypeScript, bundlers மற்றும் Bun போன்ற புதிய runtimes உருவாகியுள்ளன.
JavaScript கற்பதைத் தவிர்க்க இந்த உரையைப் பயன்படுத்தாதீர்கள். செயல்திறன் சிக்கல் (performance problem) இல்லாமல் WebAssembly-க்கு மாறுவதை நியாயப்படுத்த இதைப் பயன்படுத்தாதீர்கள்.
உங்கள் ஸ்டேக்கிற்கான ஒரு சரிபார்ப்புப் பட்டியலாக (checklist) இதைப் பயன்படுத்துங்கள்:
- நான் இதைச் சிறந்த கருவியாகக் கருதிப் பயன்படுத்துகிறேனா?
- அல்லது இங்கே வேலை செய்யக்கூடிய ஒரே விஷயம் இது என்பதால் பயன்படுத்துகிறேனா?
- கருவிகளின் கூடுதல் சுமை (overhead) உராய்வைத் தீர்க்கிறதா அல்லது அதை வேறு இடத்திற்கு நகர்த்துகிறதா?
- நான் இன்று புதிதாகத் தொடங்கினால், இதையே தேர்ந்தெடுப்பேனா?
- எனது பயன்பாட்டிற்கு (use case) இந்த செயல்திறன் வரம்பு (performance ceiling) போதுமானதா?
TypeScript கம்பைல் நேரத்தில் (compile time) வகைகளை (types) கையாள உதவுகிறது. ஆனால் உங்கள் வகைகள்க்கும் நெட்வொர்க் வழியாக வரும் தரவுக்கும் இடையிலான இடைவெளியை அது சரிசெய்யாது. உங்களுக்கு இன்னும் runtime validation தேவைப்படும்.
மிக முக்கியமான பாடம் இதுதான்: உங்கள் தொழில்நுட்பம் அதன் தகுதியின் அடிப்படையில் இயங்குகிறதா அல்லது ஏகபோக உரிமையால் இயங்குகிறதா என்பதைத் தெரிந்து கொள்ளுங்கள்.
2014-இன் கணிப்பின் அடிப்படையில் உங்கள் runtime-ஐ மாற்றாதீர்கள். ஒரு தடையை (bottleneck) காட்டும் அளவிடப்பட்ட தரவுகள் கிடைக்கும்போது மட்டும் அதை மாற்றவும்.
ஆதாரம்: https://dev.to/jtorchia/the-birth-and-death-of-javascript-2014-what-still-holds-and-what-doesnt-2hae