ഒരു ബിൽഡ് പൂർത്തിയാകാൻ കാത്തിരിക്കുന്ന ഡെവലപ്പർമാരുള്ള മുറിയിൽ വിചിത്രമായ ഒരുതരം നിശബ്ദതയുണ്ട്. കണ്ണുകൾ രണ്ടാമത്തെ മോണിറ്ററുകളിലേക്ക് നീങ്ങുന്നു. വിരലുകൾ ഫോണുകളിൽ സ്ക്രോൾ ചെയ്യുന്നു. ആരും ആഗ്രഹിക്കാത്ത ഒരു കോഫി കുടിക്കാനായി ആരോ എഴുന്നേൽക്കുന്നു. നിങ്ങൾ ആധുനികമായ ഒരു JavaScript കോഡ്ബേസിൽ സമയം ചിലവഴിച്ചിട്ടുണ്ടെങ്കിൽ, ഈ ഇടവേള നിങ്ങൾക്ക് അറിയാമായിരിക്കും. ഇതൊരു വിശ്രമമല്ല. ഇത് നിങ്ങളുടെ ചിന്താഗതിയിലുണ്ടാകുന്ന ഒരു തടസ്സമാണ്.
നമ്മൾ ഫ്രെയിംവർക്കുകളെക്കുറിച്ച് ഒരുപാട് സംസാരിക്കാറുണ്ട്. React, Vue, Svelte, അടുത്ത ആഴ്ച വരാൻ പോകുന്നവ എന്തായാലും सबका ശ്രദ്ധയും പിടിച്ചുപറ്റുന്നു. കോൺഫറൻസുകൾ ഫ്രെയിംവർക്ക് പ്രഖ്യാപനങ്ങൾക്കായി ബുക്ക് ചെയ്യപ്പെടുന്നു. ബ്ലോഗ് പോസ്റ്റുകൾ സിന്റാക്സ് ഷുഗറിനെക്കുറിച്ച് (syntax sugar) വിശകലനം ചെയ്യുന്നു. എന്നാൽ ഉപയോക്താക്കൾ ശ്രദ്ധിക്കുന്ന ഈ ബഹളങ്ങൾക്കിടയിൽ, നിങ്ങൾ കോഡ് എഴുതുന്ന രീതി തന്നെ മാറ്റാൻ പോകുന്ന തരത്തിൽ അടിസ്ഥാനപരമായ മാറ്റങ്ങൾ സംഭവിക്കുന്നുണ്ട്. ഈ വിപ്ലവം ഒരു ഫ്രണ്ട്എൻഡ് ഫ്രെയിംവർക്കിൽ നിന്നല്ല വരുന്നത്. അത് ടൂളിംഗ് ലെയറിലാണ് (tooling layer) സംഭവിക്കുന്നത്, അത് Rust, Go എന്നിവയിലാണ് എഴുതപ്പെടുന്നത്.
വർഷങ്ങളായി, JavaScript ടൂളുകൾ നിർമ്മിച്ചിരുന്നത് JavaScript ഉപയോഗിച്ചാണ്. അത് യുക്തിസഹമായിരുന്നു. നാളത്തെ സിന്റാക്സ് ഇന്ന് എങ്ങനെ എഴുതാം എന്ന് Babel ഒരു തലമുറയെ പഠിപ്പിച്ചു. ബ്രൗസറുകൾക്ക് ഉപയോഗിക്കാൻ കഴിയുന്ന രീതിയിൽ Webpack നമ്മുടെ കോഡുകളെ ബണ്ടിൽ ചെയ്തു. നമ്മൾ കോഡ് കമിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് തന്നെ ESLint ബഗുകൾ കണ്ടെത്തി. ഈ ടൂളുകൾ രൂപകൽപ്പന ചെയ്തത് ചെറിയ വെബ് ആവശ്യങ്ങൾക്കായിരുന്നു. അവ പ്രതീക്ഷിച്ചത് ഏതാനും നൂറ് മോഡ്യൂളുകളെയാണ്, പതിനായിരങ്ങളെ അല്ല. അവ പ്രതീക്ഷിച്ചത് സിംഗിൾ റെപ്പോസിറ്ററുകളെയാണ്, ഒരു ഷെയർഡ് UI പാക്കേജിലെ മാറ്റം ഡസൻ കണക്കിന് ആപ്ലിക്കേഷനുകളെ ബാധിക്കുന്ന മോണോറെപ്പോസിറ്ററുകളെ (monorepos) അല്ല.
പിന്നീട് ആപ്പുകൾ വളർന്നു. കോഡ്ബേസുകൾ വലിയ റെപ്പോസിറ്ററികളായി മാറി. ടൂളുകൾ പഴയതുപോലെ തന്നെ തുടർന്നു, അതോടെ ലേറ്റൻസി (latency) വർദ്ധിച്ചു തുടങ്ങി. രണ്ട് സെക്കൻഡ് മാത്രം എടുത്തിരുന്ന ഒരു ഹോട്ട് റീലോഡ് പന്ത്രണ്ടും പിന്നീട് മുപ്പതും സെക്കൻഡുകൾ എടുക്കാൻ തുടങ്ങി. ഉച്ചഭക്ഷണത്തിന് മുമ്പ് മുഴുവൻ ടെസ്റ്റ് സ്യൂട്ടും റൺ ചെയ്യുന്നത് ഒരു സ്വപ്നമായി മാറി. ആയിരം തവണ പരിശോധിച്ച ഫയലുകളിൽ പോലും ലിന്ററുകൾ തടസ്സപ്പെട്ടു. പേപ്പറിൽ നോക്കുമ്പോൾ ഓരോ താമസവും ചെറുതായി തോന്നാം. എന്നാൽ പ്രായോഗികമായി, ഈ ഇടവേളകൾ ഏകാഗ്രത തകർക്കുന്നു. ജോലികൾ കൂട്ടിച്ചേർത്ത് ചെയ്യാൻ (batch your work), ഒരു പരിഹാരം ശരിയായോ എന്ന് പരിശോധിക്കുന്നതിന് മുമ്പ് മടികാണിക്കാൻ, ഫീഡ്ബാക്ക് ലഭിക്കാനുള്ള താമസം കാരണം പരീക്ഷണങ്ങൾ ഒഴിവാക്കാൻ ഇവ നിങ്ങളെ പ്രേരിപ്പിക്കുന്നു.
അടുത്ത തലമുറയിലെ ടൂളുകൾ JavaScript-ന്റെ വഴിയിൽ തടസ്സമാകാതെ പ്രവർത്തിച്ചുകൊണ്ട് ആ ലേറ്റൻസിയെ നേരിടുന്നു.
പുതിയ എൻജിൻ റൂം
ചില പ്രത്യേക ജോലികൾ എങ്ങനെ വീണ്ടെടുക്കപ്പെടുന്നു എന്ന് നോക്കൂ.
Transformation എന്നാൽ പണ്ട് Babel എന്നായിരുന്നു അർത്ഥം. JSX-നെയും stage-3 പ്രൊപ്പോസലുകളെയും സാധാരണ ES5-ലേക്ക് മാറ്റുന്ന ഒരു യൂണിവേഴ്സൽ പ്രീപ്രോസസറായിരുന്നു അത്. അത് ഇപ്പോഴും മികച്ച സോഫ്റ്റ്വെയറാണ്, പക്ഷേ അത് സിംഗിൾ-ത്രെഡഡ് ആയ JavaScript ഉപയോഗിച്ച് JavaScript പാഴ്സ് ചെയ്യുന്ന രീതിയിലാണ് പ്രവർത്തിക്കുന്നത്. ഇവിടെയാണ് OXC കടന്നുവരുന്നത്, ഇതൊരു Rust അടിസ്ഥാനമാക്കിയുള്ള ടൂൾചെയിൻ ആണ്. Babel ചെയ്യുന്ന അതേ ജോലികൾ തന്നെ ഇത് ചെയ്യുന്നു, എന്നാൽ ബെഞ്ച്മാർക്കുകൾ പ്രകാരം ഇത് ഏകദേശം 40 മടങ്ങ് വേഗതയുള്ളതും 70% കുറഞ്ഞ മെമ്മറി ഉപയോഗിക്കുന്നതുമാണ്. ഇത് വെറുമൊരു ചെറിയ പുരോഗതിയല്ല. ഇത് നിങ്ങൾ ശ്രദ്ധിക്കുന്ന ഒരു ടൂളിനും, പ്രവർത്തിക്കുന്നത് നിങ്ങൾ അറിയാത്ത ഒരു ടൂളിനും ഇടയിലുള്ള വ്യത്യാസമാണ്.
Bundling ആണ് ഏറ്റവും കൂടുതൽ ബുദ്ധിമുട്ട് ഉണ്ടാക്കിയിരുന്നത്. ഒരു പതിറ്റാണ്ടോളം Webpack ആണ് സ്റ്റാൻഡേർഡ്, പക്ഷേ അതിന്റെ ആന്തരിക ഘടന മറ്റൊരു സ്കെയിലിന് വേണ്ടി നിർമ്മിച്ചതാണ്. അതിന്റെ Rust പിൻഗാമിയായ Turbopack വെറുതെ വേഗത്തിൽ റീകംപൈൽ ചെയ്യുക മാത്രമല്ല ചെയ്യുന്നത്. എന്താണ് മാറിയതെന്ന് കൃത്യമായി മനസ്സിലാക്കാനും ആ ഭാഗം മാത്രം റീബിൽഡ് ചെയ്യാനും ഇത് അഗ്രസീവ് ആയ മെമ്മോയിസേഷൻ (memoization) ഉപയോഗിക്കുന്നു. ഒരു വലിയ ആപ്ലിക്കേഷനിൽ, ഒരു സിംഗിൾ കോമ്പോണന്റ് മാറ്റുന്നത് ഒരു ഫുൾ ഗ്രാഫ് ട്രാവേഴ്സലിന് (graph traversal) കാരണമാകരുത്. Turbopack ഉപയോഗിക്കുമ്പോൾ, ബിൽഡുകൾ ഇൻസ്റ്റന്റ് ആയി മാറുന്നു. നോക്കിനിൽക്കാൻ ഒന്നുമില്ലാത്തതിനാൽ പ്രോഗ്രസ് ബാർ പോലും അപ്രത്യക്ഷമാകുന്നു.
Testing അതിന്റേതായ താമസം ഉണ്ടാക്കുന്നുണ്ട്. Jest JavaScript ടെസ്റ്റിംഗിനെ പുനർനിർവചിച്ചു, എങ്കിലും വാച്ച് മോഡിൽ (watch mode) ഓരോ കീസ്ട്രോക്കിലും അത് നിങ്ങളുടെ കോഡ്ബേസ് വീണ്ടും പഠിച്ചെടുക്കുന്നത് പോലെ തോന്നും. Vitest മറ്റൊരു രീതിയാണ് സ്വീകരിക്കുന്നത്. ഇത് സ്വന്തമായി ഒരു ഡിപെൻഡൻസി ട്രീ നിർമ്മിക്കുന്നതിന് പകരം Vite-ന്റെ മോഡ്യൂൾ ഗ്രാഫ് വീണ്ടും ഉപയോഗിക്കുന്നതിനാൽ, വാച്ച് മോഡിൽ Jest-നേക്കാൾ ഏകദേശം 8.5 മടങ്ങ് വേഗതയിൽ ഇത് പ്രവർത്തിക്കുന്നു. ഇവിടെ നേട്ടം വെറും വേഗത മാത്രമല്ല, മറിച്ച് ഏകോപനം (coherence) കൂടിയാണ്. നിങ്ങളുടെ ടെസ്റ്റ് റണ്ണറും ഡെവ് സെർവറും നിങ്ങളുടെ പ്രോജക്റ്റ് എങ്ങനെയുള്ളതാണെന്ന കാര്യത്തിൽ ഒരേപോലെ പ്രവർത്തിക്കുന്നു.
Linting ഉം സമാനമായ ഒരു പ്രശ്നം നേരിടുന്നുണ്ട്. ESLint-ന്റെ ഫ്ലെക്സിബിലിറ്റി അതിന്റെ കരുത്താണ്; അതിന്റെ റൂളുകൾ വെറും JavaScript ഫംഗ്ഷനുകളാണ്, അവ AST-യിൽ പ്രവർത്തിക്കുന്നു. ആ ഫ്ലെക്സിബിലിറ്റി കൂടുതൽ സമയം എടുക്കുന്നു. Rust-ൽ എഴുതപ്പെട്ട Oxlint, സാധാരണ ഉപയോഗങ്ങളിൽ മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിച്ച് അതിവേഗം പ്രവർത്തിക്കുന്നു. ഇത് ESLint-നേക്കാൾ 50 മുതൽ 100 മടങ്ങ് വരെ വേഗതയുള്ളതാണ്. പ്രായോഗികമായി പറഞ്ഞാൽ, നിങ്ങളുടെ എഡിറ്ററിലെ സേവ് ആനിമേഷൻ കഴിയുന്നതിന് മുമ്പ് തന്നെ ലിന്റിംഗ് പൂർത്തിയാകും. പ്രശ്നം പരിഹരിച്ചതിന് ശേഷവും സെക്കൻഡുകളോളം നീണ്ടുനിൽക്കുന്ന ചുവന്ന വരകൾ (red squiggles) ഇനി നിങ്ങൾ സഹിക്കേണ്ടി വരില്ല.
ഒരുപക്ഷേ ഏറ്റവും പ്രതീകാത്മകമായ മാറ്റം സംഭവിക്കുന്നത് type checking-ൽ ആണ്. Microsoft നിലവിൽ TypeScript compiler Go ഭാഷയിൽ പുനർനിർമ്മിക്കുകയാണ്. ആദ്യകാല ബെഞ്ച്മാർക്കുകൾ ശ്രദ്ധേയമാണ്: പുതിയ രീതിയിൽ VS Code ഏകദേശം 8 മടങ്ങ് വേഗത്തിൽ ലോഡ് ആകുന്നു, type checking ഏകദേശം 10 മടങ്ങ് വേഗത്തിലുമാണ്. ഇതിന്റെ അർത്ഥം എന്താണെന്ന് ചിന്തിച്ചുനോക്കൂ. TypeScript എന്നത് JavaScript-ന്റെ വിജയഗാഥയാണ്. അത് JavaScript-ലേക്ക് കംപൈൽ ചെയ്യുന്ന ഒരു ഭാഷയാണ്, JavaScript ഇക്കോസിസ്റ്റങ്ങളെ type-check ചെയ്യാൻ ഉപയോഗിക്കുന്നു, ഇപ്പോൾ അതിന്റെ സ്വന്തം കംപൈലർ ഒരു native systems language-ലേക്ക് മാറുകയാണ്, കാരണം ഇക്കോസിസ്റ്റത്തിന് ആവശ്യമായ പെർഫോമൻസ് നൽകാൻ JavaScript-ന് കഴിയില്ല. വേഗതയ്ക്കായി ആ ടൂൾ അതിന്റെ തന്നെ പാതയെ വിഴുങ്ങുകയാണ്.
ഇതിലൊന്നും React-നെ പ്രതിസ്ഥാപിക്കുന്നില്ല. ഇത് Next.js-നെ ഇല്ലാതാക്കുകയോ TypeScript-നെ കാലഹരണപ്പെടുത്തുകയോ ചെയ്യുന്നില്ല. ഫ്രെയിംവർക്കുകൾ ഇപ്പോഴും നിങ്ങളുടെ കമ്പോണന്റ് മോഡലും റൂട്ടിംഗും നിർണ്ണയിക്കുന്നു. ഈ പുതിയ ടൂളുകൾ അടിത്തട്ടിലുള്ള കാര്യങ്ങൾ കൂടുതൽ വേഗത്തിലാക്കുന്നു എന്ന് മാത്രം. അവ റോഡുകളാണ്, കാറല്ല.
വേഗത പെരുമാറ്റത്തെ മാറ്റുമ്പോൾ
ടൂളിംഗിനെക്കുറിച്ചുള്ള ചർച്ചകൾ പലപ്പോഴും ബെഞ്ച്മാർക്ക് ചാർട്ടുകളിൽ കുടുങ്ങിപ്പോകാറുണ്ട്. അക്കങ്ങൾ താരതമ്യം ചെയ്യാൻ എളുപ്പമാണ്. എന്നാൽ യഥാർത്ഥ സ്വാധീനം മനുഷ്യന്റെ പെരുമാറ്റത്തിലാണ്.
ഫീഡ്ബാക്ക് സെക്കൻഡുകളിൽ നിന്ന് മില്ലിസെക്കൻഡുകളിലേക്ക് മാറുമ്പോൾ, നിങ്ങൾ ജോലികൾ വേഗത്തിൽ പൂർത്തിയാക്കുക മാത്രമല്ല ചെയ്യുന്നത്. നിങ്ങൾ അവ വ്യത്യസ്തമായ രീതിയിൽ ചെയ്യുന്നു. നിങ്ങൾ മാറ്റങ്ങൾ കുമിഞ്ഞുകൂട്ടി വെക്കുന്നത് നിർത്തുന്നു. ഒരു വരി എഴുതുന്നു, ഫലം കാണുന്നു, ക്രമീകരിക്കുന്നു. ടെസ്റ്റുകൾ റൺ ചെയ്യുന്നത് അവ പെട്ടെന്ന് ഫലം നൽകുന്നത് കൊണ്ടാണ്, അല്ലാതെ നിങ്ങളുടെ pull request ആവശ്യപ്പെടുന്നത് കൊണ്ടല്ല. മാറ്റങ്ങൾ വരുത്തി നോക്കുന്നത് (refactor) പരാജയപ്പെട്ടാലും അത് തിരുത്താൻ സമയം നഷ്ടപ്പെടാത്തതുകൊണ്ട് നിങ്ങൾ അത് പരീക്ഷിക്കുന്നു. മെഷീൻ നിങ്ങളെ തിരികെ വിളിക്കാൻ കാത്തുനിൽക്കുന്നതിന് പകരം നിങ്ങൾ പ്രശ്നത്തിൽ തന്നെ മുഴുകിയിരിക്കുന്നു.
മനഃശാസ്ത്രജ്ഞർ ഇതിനെ 'flow' എന്ന് വിളിക്കുന്നു. പ്രവർത്തനവും അതിന്റെ ഫലവും തമ്മിലുള്ള ശക്തമായ ബന്ധം ഇതിന് ആവശ്യമാണ്. ഒരു ഗിറ്റാറിസ്റ്റ് വായിക്കുമ്പോൾ ആംപ്ലിഫയർ ഓരോ നോട്ടിനും താമസം വരുത്തിയാൽ അവന് വായിക്കാൻ കഴിയില്ല. ഒരു പെയിന്റർ ബ്രഷ് പകുതി സെക്കൻഡ് വൈകി പ്രവർത്തിച്ചാൽ നിറങ്ങൾ കൂട്ടിക്കലർത്താൻ കഴിയില്ല. ഡെവലപ്പർമാരും വ്യത്യസ്തരല്ല. ലേറ്റൻസി (Latency) എന്നത് വെറുമൊരു അസ്വസ്ഥതയല്ല. അത് ചിന്തയ്ക്ക് മേലുള്ള ഒരു നികുതിയാണ്.
അതുകൊണ്ട്, ഉൽപ്പാദനക്ഷമതയിലെ വർദ്ധനവ് സാങ്കേതികമായത് മാത്രമല്ല. അത് ശീലമാണ്. വേഗതയേറിയ ടൂളുകൾ നിങ്ങളെ പരീക്ഷണം നടത്താൻ പഠിപ്പിക്കുന്നു. പതുക്കെ പ്രവർത്തിക്കുന്ന ടൂളുകൾ നിങ്ങളെ മടിച്ചുനിൽക്കാൻ പഠിപ്പിക്കുന്നു. ഒരു വർഷം കഴിയുമ്പോൾ, ഈ വ്യത്യാസം തികച്ചും വ്യത്യസ്തമായ സോഫ്റ്റ്വെയറുകളായി മാറുന്നു. പെട്ടെന്നുള്ള ഫീഡ്ബാക്ക് ലഭിക്കുന്ന ടീം കൂടുതൽ ആത്മവിശ്വാസത്തോടെ കാര്യങ്ങൾ പുറത്തിറക്കുന്നു. പരീക്ഷിക്കാനുള്ള ചിലവ് പൂജ്യമായതുകൊണ്ട് അവർ ജോലികളെ ചെറിയ ഭാഗങ്ങളായി വിഭജിക്കുന്നു. ബഗുകൾ 20 മിനിറ്റ് കഴിഞ്ഞ് CI-ൽ കാണുന്നതിന് പകരം ആ നിമിഷം തന്നെ കണ്ടെത്തുന്നത് കൊണ്ട് അവരുടെ കോഡ് റിവ്യൂകൾ വേഗത്തിലാകുന്നു.
അദൃശ്യമായ ജോലി
അതുകൊണ്ടാണ് വാർത്തകൾ തെറ്റിദ്ധരിപ്പിക്കുന്നത്. ഫ്രെയിംവർക്കുകളെക്കുറിച്ച് എഴുതാൻ എളുപ്പമാണ്. അവയ്ക്ക് ലോഗോകളും API-കളും ട്വിറ്ററിലെ ചർച്ചകളും ഉണ്ട്. എന്നാൽ ഇൻഫ്രാസ്ട്രക്ചർ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത് തന്നെ അദൃശ്യമായിരിക്കാനാണ്. ഒരു ബണ്ട്ലർ (bundler) കോൺഫിഗർ ചെയ്യാൻ നിങ്ങൾ ആവേശത്തോടെ ഉണരില്ല. അത് അപ്രത്യക്ഷമാകണമെന്നാണ് നിങ്ങൾ ആഗ്രഹിക്കുന്നത്. എന്നാൽ നല്ല ഇൻഫ്രാസ്ട്രക്ചർ ചെയ്യുന്നത് കൃത്യമായി അതാണ്. ദൃശ്യമായ പാളി (visible layer) ഭാരം കുറഞ്ഞതായി നിലനിർത്താൻ അത് ഭാരം ചുമക്കുന്നു.
നിങ്ങൾ ഒരു ടീമിനെ നയിക്കുകയോ അല്ലെങ്കിൽ പഴയ ഒരു കോഡ്ബേസ് (legacy codebase) പരിപാലിക്കുകയോ ആണെങ്കിൽ, ഇത് നിങ്ങളുടെ മുൻഗണനകളെ സ്വാധീനിക്കേണ്ടതുണ്ട്. React-ൽ നിന്ന് Vue-ലേക്ക് മാറുന്നത് നിങ്ങളുടെ കമ്പോണന്റ് ട്രീയെ മാറ്റിയേക്കാം. എന്നാൽ Webpack-ൽ നിന്ന് Turbopack-ലേക്കോ അല്ലെങ്കിൽ Babel-ൽ നിന്ന് OXC-ലേക്കോ മാറുന്നത് നിങ്ങളുടെ മുഴുവൻ പ്രവൃത്തിദിനത്തെയും മാറ്റിയേക്കാം. രണ്ടാമത്തെ കാര്യം മാനേജ്മെന്റിനെ ബോധ്യപ്പെടുത്താൻ പ്രയാസമാണ്, കാരണം അതിന് പുതിയൊരു ഹോംപേജ് ഡെമോ ഇല്ല. പകരം, ബിൽഡ് ടെർമിനലിന് മുന്നിൽ നിന്ന് നെടുവീർപ്പിടുന്നത് നിർത്തുന്ന ഒരു ടീം മാത്രമേ അവിടെ ഉണ്ടാകൂ.
നിങ്ങളെ യഥാർത്ഥത്തിൽ പതുക്കെയാക്കുന്നത് എന്താണെന്ന് പരിശോധിക്കുക. 2015-ൽ നിർമ്മിച്ച ഒരു ടൂൾചെയിൻ ഉപയോഗിച്ച് നിങ്ങൾ ഒരു മോഡേൺ മോണോറെപ്പോ (monorepo) പ്രവർത്തിപ്പിക്കുന്നുണ്ടെങ്കിൽ, നിങ്ങൾ സൂക്ഷ്മത പാലിക്കുകയല്ല ചെയ്യുന്നത്. മറിച്ച്, നിങ്ങൾ ദിവസേനയുള്ള ഒരു ഘർഷണ നികുതി (friction tax) നൽകിക്കൊണ്ടിരിക്കുകയാണ്. ഇതിനുള്ള പരിഹാരം പുതിയൊരു ഫ്രണ്ട്എൻഡ് പാരാഡൈം പഠിക്കുക എന്നതല്ല, മറിച്ച് എൻജിൻ മാറ്റുക എന്നതാണ്.
ഫ്രെയിംവർക്കുകൾ വന്നുകൊണ്ടേയിരിക്കും. അവയ്ക്ക് ട്വീറ്റുകളും കോൺഫറൻസ് പ്രസംഗങ്ങളും ലഭിച്ചുകൊണ്ടേയിരിക്കും. എന്നാൽ JavaScript എഴുതുന്ന രീതിയിലുണ്ടാകുന്ന യഥാർത്ഥ മാറ്റം സംഭവിക്കുന്നത് അതിന്റെ അടിത്തട്ടിലാണ്, നിങ്ങളുടെ സമയത്തെ വിലപ്പെട്ടതായി കാണുന്ന കംപൈൽഡ് ഭാഷകളിലൂടെയാണ്. അതാണ് വിപ്ലവം. ഒരു ലിസ്റ്റ് റെൻഡർ ചെയ്യാനുള്ള പുതിയ രീതിയല്ല, മറിച്ച് നിങ്ങളുടെ വഴിയിൽ തടസ്സമാകാതെ നിങ്ങളെ ചിന്തിക്കാൻ അനുവദിക്കുന്നത്ര വേഗതയുള്ള ഒരു ടൂൾചെയിൻ ആണ് അത്.