ਇੱਕ ਬਿਲਡ ਦੇ ਖਤਮ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਡਿਵੈਲਪਰਾਂ ਨਾਲ ਭਰੇ ਕਮਰੇ ਵਿੱਚ ਇੱਕ ਅਜੀਬ ਕਿਸਮ ਦੀ ਚੁੱਪ ਹੁੰਦੀ ਹੈ। ਅੱਖਾਂ ਦੂਜੇ ਮੋਨੀਟਰਾਂ ਵੱਲ ਜਾਂਦੀਆਂ ਹਨ। ਅੰਗੂਠੇ ਫ਼ੋਨਾਂ 'ਤੇ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹਨ। ਕੋਈ ਅਜਿਹੀ ਕੌਫੀ ਲੈਣ ਲਈ ਉੱਠਦਾ ਹੈ ਜਿਸਦੀ ਉਸਨੂੰ ਅਸਲ ਵਿੱਚ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਆਧੁਨਿਕ JavaScript ਕੋਡਬੇਸ ਵਿੱਚ ਕੁਝ ਸਮਾਂ ਬਿਤਾਇਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਰੁਕਾਵਟ ਨੂੰ ਜਾਣਦੇ ਹੋ। ਇਹ ਕੋਈ ਬ੍ਰੇਕ ਨਹੀਂ ਹੈ। ਇਹ ਤੁਹਾਡੀ ਸੋਚ ਵਿੱਚ ਇੱਕ ਖਾਲੀਪਣ ਹੈ।

ਅਸੀਂ ਫਰੇਮਵਰਕਾਂ ਬਾਰੇ ਬਹੁਤ ਗੱਲ ਕਰਦੇ ਹਾਂ। React, Vue, Svelte, ਅਤੇ ਅਗਲੇ ਹਫ਼ਤੇ ਜੋ ਵੀ ਨਵਾਂ ਆਵੇਗਾ, ਸਾਰਾ ਧਿਆਨ ਖਿੱਚ ਲੈਂਦਾ ਹੈ। ਕਾਨਫਰੰਸਾਂ ਫਰੇਮਵਰਕ ਐਲਾਨਾਂ 'ਤੇ ਵਿਕ ਜਾਂਦੀਆਂ ਹਨ। ਬਲੌਗ ਪੋਸਟਾਂ ਸਿੰਟੈਕਸ ਸ਼ੂਗਰ (syntax sugar) ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੀਆਂ ਹਨ। ਪਰ ਇਸ ਸਾਰੀ ਉਪਰਲੀ ਰੌਲੇ-ਰੱਪੇ ਤੋਂ ਹੇਠਾਂ, ਜ਼ਮੀਨ ਇਸ ਤਰ੍ਹਾਂ ਬਦਲ ਰਹੀ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਡ ਲਿਖਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦੇਵੇਗੀ। ਇਹ ਕ੍ਰਾਂਤੀ ਕਿਸੇ ਫਰੰਟਐਂਡ ਫਰੇਮਵਰਕ ਤੋਂ ਨਹੀਂ ਆ ਰਹੀ। ਇਹ ਟੂਲਿੰਗ ਲੇਅਰ (tooling layer) ਵਿੱਚ ਹੋ ਰਹੀ ਹੈ, ਅਤੇ ਇਹ Rust ਅਤੇ Go ਵਿੱਚ ਲਿਖੀ ਜਾ ਰਹੀ ਹੈ।

ਸਾਲਾਂ ਤੱਕ, JavaScript ਟੂਲ JavaScript ਨਾਲ ਬਣਾਏ ਗਏ ਸਨ। ਇਹ ਸਹੀ ਲੱਗਦਾ ਸੀ। Babel ਨੇ ਇੱਕ ਪੀੜ੍ਹੀ ਨੂੰ ਅੱਜ ਹੀ ਭਵਿੱਖ ਦੇ ਸਿੰਟੈਕਸ ਲਿਖਣਾ ਸਿਖਾਇਆ। Webpack ਨੇ ਸਾਡੇ ਵੱਖਰੇ ਕੋਡ ਨੂੰ ਅਜਿਹੀ ਚੀਜ਼ ਵਿੱਚ ਬੰਨ੍ਹ ਦਿੱਤਾ ਜਿਸਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਆਸਾਨੀ ਨਾਲ ਚਲਾ ਸਕਣ। ESLint ਨੇ ਕੋਡ ਕਮਿਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੱਗਸ (bugs) ਫੜ ਲਏ। ਇਹ ਟੂਲ ਇੱਕ ਛੋਟੇ ਵੈੱਬ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਨ। ਉਹਨਾਂ ਨੇ ਕੁਝ ਸੌ ਮੋਡਿਊਲ ਮੰਨੇ ਸਨ, ਦਸ ਹਜ਼ਾਰ ਨਹੀਂ। ਉਹਨਾਂ ਨੇ ਸਿੰਗਲ ਰੈਪੋਜ਼ (single repos) ਮੰਨੇ ਸਨ, ਮੋਨੋਰੇਪੋਜ਼ (monorepos) ਨਹੀਂ ਜਿੱਥੇ ਇੱਕ ਸਾਂਝੇ UI ਪੈਕੇਜ ਵਿੱਚ ਬਦਲਾਅ ਦਰਜਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

ਫਿਰ ਐਪਸ ਵਧਦੀਆਂ ਗਈਆਂ। ਕੋਡਬੇਸ ਵੱਡੀਆਂ ਰੈਪੋਜ਼ਟਰੀਆਂ ਵਿੱਚ ਬਦਲ ਗਏ। ਟੂਲ ਉਹੀ ਰਹੇ, ਅਤੇ ਦੇਰੀ (latency) ਵਧਦੀ ਗਈ। ਇੱਕ 'ਹੌਟ ਰੀਲੋਡ' (hot reload) ਜਿਸ ਵਿੱਚ ਦੋ ਸਕਿੰਟ ਲੱਗਦੇ ਸਨ, ਉਹ ਬਾਰਾਂ, ਫਿਰ ਤੀਹ ਸਕਿੰਟ ਦਾ ਹੋ ਗਿਆ। ਦੁਪਹਿਰ ਦੇ ਖਾਣੇ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰਾ ਟੈਸਟ ਸੂਟ ਚਲਾਉਣਾ ਇੱਕ ਸੁਪਨਾ ਬਣ ਗਿਆ। Linters ਉਹਨਾਂ ਫਾਈਲਾਂ 'ਤੇ ਅਟਕਣ ਲੱਗੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਹਜ਼ਾਰ ਵਾਰ ਚੈੱਕ ਕਰ ਚੁੱਕੇ ਸਨ। ਕਾਗਜ਼ 'ਤੇ ਹਰ ਦੇਰੀ ਛੋਟੀ ਲੱਗਦੀ ਹੈ। ਅਸਲ ਵਿੱਚ, ਇਹ ਰੁਕਾਵਟਾਂ ਧਿਆਨ ਨੂੰ ਖਿੰਡਾ ਦਿੰਦੀਆਂ ਹਨ। ਇਹ ਤੁਹਾਨੂੰ ਆਪਣਾ ਕੰਮ ਇਕੱਠਾ (batch) ਕਰਨ ਲਈ, ਕੋਈ ਫਿਕਸ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਚੈੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਿਚਕਿਚਾਉਣ ਲਈ, ਅਤੇ ਪ੍ਰਯੋਗਾਂ ਤੋਂ ਬਚਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਫੀਡਬੈਕ ਦੀ ਕੀਮਤ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ।

ਟੂਲਿੰਗ ਦੀ ਅਗਲੀ ਪੀੜ੍ਹੀ ਸਿਰਫ਼ JavaScript ਦੇ ਰਸਤੇ ਤੋਂ ਹਟ ਕੇ ਉਸ ਦੇਰੀ 'ਤੇ ਹਮਲਾ ਕਰਦੀ ਹੈ।

ਨਵਾਂ ਇੰਜਣ ਰੂਮ

ਦੇਖੋ ਕਿ ਕਿਵੇਂ ਖਾਸ ਕੰਮਾਂ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।

Transformation ਦਾ ਮਤਲਬ ਪਹਿਲਾਂ Babel ਹੁੰਦਾ ਸੀ। ਇਹ ਇੱਕ ਯੂਨੀਵਰਸਲ ਪ੍ਰੀਪ੍ਰੋਸੈਸਰ ਸੀ, ਜੋ JSX ਅਤੇ stage-3 ਪ੍ਰਪੋਜ਼ਲ ਨੂੰ ਸਾਦੇ ES5 ਵਿੱਚ ਬਦਲਦਾ ਸੀ। ਇਹ ਅਜੇ ਵੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਾਫਟਵੇਅਰ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਸਿੰਗਲ-ਥ੍ਰੈਡਡ JavaScript ਹੈ ਜੋ JavaScript ਨੂੰ ਹੀ ਪਾਰਸ (parse) ਕਰ ਰਹੀ ਹੈ। ਹੁਣ OXC ਦਾ ਦੌਰ ਹੈ, ਜੋ ਕਿ ਇੱਕ Rust-ਅਧਾਰਤ ਟੂਲਚੇਨ ਹੈ। ਇਹ ਉਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ Babel ਕਰਦਾ ਹੈ, ਪਰ ਬੈਂਚਮਾਰਕ ਦੱਸਦੇ ਹਨ ਕਿ ਇਹ ਲਗਭਗ 40 ਗੁਣਾ ਤੇਜ਼ ਹੈ ਅਤੇ 70% ਘੱਟ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਹ ਕੋਈ ਛੋਟਾ-ਮੋਟਾ ਸੁਧਾਰ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਅਜਿਹੇ ਟੂਲ ਅਤੇ ਇੱਕ ਅਜਿਹੇ ਟੂਲ ਵਿਚਕਾਰ ਅੰਤਰ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਅਤੇ ਇੱਕ ਅਜਿਹੇ ਟੂਲ ਵਿਚਕਾਰ ਜਿਸਦੇ ਚੱਲਣ ਦਾ ਤੁਹਾਨੂੰ ਅਹਿਸਾਸ ਵੀ ਨਹੀਂ ਹੁੰਦਾ।

Bundling ਉਹ ਜਗ੍ਹਾ ਸੀ ਜਿੱਥੇ ਸਭ ਤੋਂ ਵੱਧ ਮੁਸ਼ਕਲ ਆਉਂਦੀ ਸੀ। Webpack ਇੱਕ ਦਹਾਕੇ ਤੱਕ ਮਿਆਰ ਸੀ, ਪਰ ਇਸਦੀ ਅੰਦਰੂਨੀ ਬਣਤਰ ਵੱਖਰੇ ਪੈਮਾਨੇ ਲਈ ਬਣਾਈ ਗਈ ਸੀ। Turbopack, ਜੋ ਕਿ ਇਸਦਾ Rust ਉੱਤਰਾਧਿਕਾਰੀ ਹੈ, ਸਿਰਫ਼ ਤੇਜ਼ੀ ਨਾਲ ਰੀਕੰਪਾਈਲ ਹੀ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਿਆ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਉਸੇ ਹਿੱਸੇ ਨੂੰ ਮੁੜ ਬਣਾਉਣ ਲਈ 'ਐਗਰੈਸਿਵ ਮੈਮੋਇਜ਼ੇਸ਼ਨ' (aggressive memoization) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇੱਕ ਵੱਡੇ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ, ਇੱਕ ਸਿੰਗਲ ਕੰਪੋਨੈਂਟ ਨੂੰ ਬਦਲਣ ਨਾਲ ਤੁਹਾਡਾ ਪੂਰਾ ਗ੍ਰਾਫ ਟ੍ਰੈਵਰਸਲ (graph traversal) ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। Turbopack ਦੇ ਨਾਲ, ਬਿਲਡਸ ਤੁਰੰਤ ਹੋਣ ਦੇ ਨੇੜੇ ਪਹੁੰਚ ਜਾਂਦੇ ਹਨ। ਪ੍ਰੋਗਰ

ਸ਼ਾਇਦ ਸਭ ਤੋਂ ਪ੍ਰਤੀਕਾਤਮਕ ਤਬਦੀਲੀ type checking ਵਿੱਚ ਹੋ ਰਹੀ ਹੈ। Microsoft ਇਸ ਸਮੇਂ TypeScript compiler ਨੂੰ Go ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖ ਰਿਹਾ ਹੈ। ਸ਼ੁਰੂਆਤੀ benchmarks ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਹਨ: ਨਵੇਂ implementation ਨਾਲ VS Code ਲਗਭਗ 8 ਗੁਣਾ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਅਤੇ type checking ਖੁਦ ਲਗਭਗ 10 ਗੁਣਾ ਤੇਜ਼ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਸਮਝੋ। TypeScript JavaScript ਦੀ ਸਫਲਤਾ ਦੀ ਕਹਾਣੀ ਹੈ। ਇਹ ਇੱਕ ਅਜਿਹੀ ਭਾਸ਼ਾ ਹੈ ਜੋ JavaScript ਵਿੱਚ compile ਹੁੰਦੀ ਹੈ, JavaScript ecosystems ਨੂੰ type-check ਕਰਨ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਹੁਣ ਇਸਦਾ ਆਪਣਾ compiler ਇੱਕ native systems language ਵਿੱਚ ਜਾ ਰਿਹਾ ਹੈ ਕਿਉਂਕਿ JavaScript ਉਹ performance ਨਹੀਂ ਦੇ ਸਕਦੀ ਜਿਸਦੀ ecosystem ਨੂੰ ਲੋੜ ਹੈ। ਇਹ ਟੂਲ ਆਪਣੀ ਰਫ਼ਤਾਰ ਵਧਾਉਣ ਲਈ ਆਪਣੇ ਹੀ ਰਸਤੇ ਨੂੰ ਖਾ ਰਿਹਾ ਹੈ।

ਇਹ ਕੁਝ ਵੀ React ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦਾ। ਇਹ Next.js ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦਾ ਜਾਂ TypeScript ਨੂੰ ਬੇਕਾਰ ਨਹੀਂ ਬਣਾਉਂਦਾ। Frameworks ਅਜੇ ਵੀ ਤੁਹਾਡੇ component model ਅਤੇ routing ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ। ਇਹ ਨਵੇਂ ਟੂਲਸ ਸਿਰਫ਼ ਹੇਠਲੇ ਪੱਧਰ ਦੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦੇ ਹਨ। ਉਹ ਸੜਕ ਹਨ, ਕਾਰ ਨਹੀਂ।

ਜਦੋਂ ਰਫ਼ਤਾਰ ਵਿਵਹਾਰ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ

Tooling ਬਾਰੇ ਗੱਲਾਂ ਅਕਸਰ benchmark charts ਵਿੱਚ ਫਸ ਜਾਂਦੀਆਂ ਹਨ। ਅੰਕੜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਪਰ ਅਸਲ ਪ੍ਰਭਾਵ ਮਨੁੱਖੀ ਵਿਵਹਾਰ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।

ਜਦੋਂ feedback ਸਕਿੰਟਾਂ ਤੋਂ ਮਿਲੀਸੈਕਿੰਡਾਂ ਵਿੱਚ ਆਉਣ ਲੱਗ ਜਾਵੇ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਕੰਮ ਤੇਜ਼ੀ ਨਾਲ ਖਤਮ ਨਹੀਂ ਕਰਦੇ। ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਖਤਮ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਬਦਲਾਅ ਇਕੱਠੇ ਕਰਕੇ ਰੱਖਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ। ਤੁਸੀਂ ਇੱਕ ਲਾਈਨ ਲਿਖਦੇ ਹੋ, ਨਤੀਜਾ ਦੇਖਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਸੁਧਾਰ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ tests ਚਲਾਉਂਦੇ ਹੋ ਕਿਉਂਕਿ ਉਹ ਤੁਰੰਤ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਤੁਹਾਡਾ pull request ਉਹਨਾਂ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਅਜਿਹਾ refactor ਅਜ਼ਮਾਉਂਦੇ ਹੋ ਜੋ ਸ਼ਾਇਦ ਕੰਮ ਨਾ ਕਰੇ ਕਿਉਂਕਿ ਇਸਨੂੰ undo ਕਰਨ ਦੀ ਕੋਈ ਕੀਮਤ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਮਸ਼ੀਨ ਦੇ ਵਾਪਸ ਆਉਣ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ ਸਮੱਸਿਆ ਦੇ ਅੰਦਰ ਹੀ ਰਹਿੰਦੇ ਹੋ।

ਇਸਨੂੰ ਮਨੋਵਿਗਿਆਨੀ flow ਕਹਿੰਦੇ ਹਨ। ਇਸ ਲਈ ਕਾਰਵਾਈ (action) ਅਤੇ ਨਤੀਜੇ (consequence) ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸਖ਼ਤ ਲੂਪ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਗਿਟਾਰਵਾਦਕ ਉਦੋਂ ਨਹੀਂ ਵਜਾ ਸਕਦਾ ਜੇਕਰ amp ਹਰ ਨੋਟ ਵਿੱਚ ਦੇਰੀ ਕਰੇ। ਇੱਕ ਚਿੱਤਰਕਾਰ ਰੰਗ ਨਹੀਂ ਮਿਲਾ ਸਕਦਾ ਜੇਕਰ ਬੁਰਸ਼ ਅੱਧ-ਸਕਿੰਟ ਦੇਰੀ ਨਾਲ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ। Developers ਵੀ ਇਸ ਤੋਂ ਵੱਖਰੇ ਨਹੀਂ ਹਨ। Latency ਸਿਰਫ਼ ਇੱਕ ਪਰੇਸ਼ਾਨੀ ਨਹੀਂ ਹੈ। ਇਹ ਸੋਚਣ 'ਤੇ ਲੱਗਿਆ ਇੱਕ ਟੈਕਸ ਹੈ।

ਇਸ ਲਈ, ਉਤਪਾਦਕਤਾ ਵਿੱਚ ਵਾਧਾ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਨਹੀਂ ਹੈ। ਇਹ ਆਦਤ ਬਾਰੇ ਹੈ। ਤੇਜ਼ ਟੂਲ ਤੁਹਾਨੂੰ ਪ੍ਰਯੋਗ ਕਰਨ ਲਈ ਸਿਖਾਉਂਦੇ ਹਨ। ਹੌਲੀ ਟੂਲ ਤੁਹਾਨੂੰ ਹਿਚਕਿਚਾਉਣ ਲਈ ਸਿਖਾਉਂਦੇ ਹਨ। ਇੱਕ ਸਾਲ ਦੇ ਦੌਰਾਨ, ਇਹ ਅੰਤਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਜਿਸ ਟੀਮ ਕੋਲ ਤੁਰੰਤ feedback ਹੁੰਦਾ ਹੈ, ਉਹ ਵਧੇਰੇ ਭਰੋਸੇ ਨਾਲ ਕੰਮ ship ਕਰਦੀ ਹੈ। ਉਹ ਕੰਮ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਦੇ ਹਨ ਕਿਉਂਕਿ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਕੀਮਤ ਜ਼ੀਰੋ ਹੈ। ਉਹਨਾਂ ਦੇ code reviews ਘਟ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਬੱਗ ਉਸੇ ਸਮੇਂ ਫੜੇ ਜਾਂਦੇ ਹਨ, ਨਾ ਕਿ ਵੀਹ ਮਿੰਟ ਬਾਅਦ CI ਵਿੱਚ।

ਅਦਿੱਖ ਕੰਮ

ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਹੈੱਡਲਾਈਨਾਂ ਗੁੰਮਰਾਹਕੁੰਨ ਹੁੰਦੀਆਂ ਹਨ। Frameworks ਬਾਰੇ ਲਿਖਣਾ ਆਸਾਨ ਹੈ। ਉਹਨਾਂ ਦੇ ਲੋਗੋ, APIs, ਅਤੇ Twitter ਡਰਾਮਾ ਹੁੰਦਾ ਹੈ। Infrastructure ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਅਦਿੱਖ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ bundler ਨੂੰ configure ਕਰਨ ਲਈ ਉਤਸ਼ਾਹਿਤ ਹੋ ਕੇ ਨਹੀਂ ਉੱਠਦੇ। ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇਹ ਗਾਇਬ ਹੋ ਜਾਵੇ। ਪਰ ਗਾਇਬ ਹੋਣਾ ਹੀ ਇੱਕ ਚੰਗੇ infrastructure ਦਾ ਕੰਮ ਹੈ। ਇਹ ਭਾਰ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਤਾਂ ਜੋ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਪਰਤ ਹਲਕੀ ਰਹਿ ਸਕੇ।

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਟੀਮ ਦੀ ਅਗਵਾਈ ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਕਿਸੇ legacy codebase ਨੂੰ ਬਣਾਈ ਰੱਖ ਰਹੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਆਪਣੀਆਂ ਤਰਜੀਹਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। React ਤੋਂ Vue ਵਿੱਚ ਜਾਣਾ ਤੁਹਾਡੇ component tree ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ। Webpack ਤੋਂ Turbopack ਵਿੱਚ ਜਾਂ Babel ਤੋਂ OXC ਵਿੱਚ ਜਾਣਾ ਤੁਹਾਡੇ ਪੂਰੇ ਕੰਮ ਦੇ ਦਿਨ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ। ਦੂਜੇ ਮਾਮਲੇ ਨੂੰ ਮੈਨੇਜਮੈਂਟ ਨੂੰ ਸਮਝਾਉਣਾ ਔਖਾ ਹੈ ਕਿਉਂਕਿ ਉੱਥੇ ਕੋਈ ਨਵਾਂ homepage demo ਨਹੀਂ ਹੁੰਦਾ। ਉੱਥੇ ਸਿਰਫ਼ ਇੱਕ ਅਜਿਹੀ ਟੀਮ ਹੁੰਦੀ ਹੈ ਜੋ ਆਪਣੇ build terminal ਨੂੰ ਦੇਖ ਕੇ ਹੁਣ ਨਿਰਾਸ਼ਾ ਵਿੱਚ ਸਾਹ ਨਹੀਂ ਲੈਂਦੀ।

ਇਸ ਗੱਲ ਦੀ ਜਾਂਚ ਕਰੋ ਕਿ ਅਸਲ ਵਿੱਚ ਤੁਹਾਨੂੰ ਕੀ ਰੋਕ ਰਿਹਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ 2015 ਵਿੱਚ ਬਣੇ toolchain 'ਤੇ ਇੱਕ ਆਧੁਨਿਕ monorepo ਚਲਾ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਾਵਧਾਨ ਨਹੀਂ ਹੋ ਰਹੇ। ਤੁਸੀਂ ਰੋਜ਼ਾਨਾ ਇੱਕ friction tax ਭੁਗਤ ਰਹੇ ਹੋ। ਇਸਦਾ ਹੱਲ ਕੋਈ ਨਵਾਂ frontend paradigm ਸਿੱਖਣਾ ਨਹੀਂ ਹੈ। ਇਹ engine ਨੂੰ ਬਦਲਣਾ ਹੈ।

Frameworks ਆਉਂਦੇ ਰਹਿਣਗੇ। ਉਹਨਾਂ ਨੂੰ tweets ਅਤੇ ਕਾਨਫਰੰਸ ਦੇ keynotes ਮਿਲਦੇ ਰਹਿਣਗੇ। ਪਰ JavaScript ਨੂੰ ਲਿਖਣ ਦੇ ਅਹਿਸਾਸ ਵਿੱਚ ਅਸਲ ਤਬਦੀਲੀ under the hood ਹੋ ਰਹੀ ਹੈ, ਉਹਨਾਂ compiled languages ਵਿੱਚ ਜੋ ਤੁਹਾਡੇ ਸਮੇਂ ਨੂੰ ਕੀਮਤੀ ਮੰਨਦੀਆਂ ਹਨ। ਇਹੀ ਕ੍ਰਾਂਤੀ ਹੈ। ਕਿਸੇ ਲਿਸਟ ਨੂੰ render ਕਰਨ ਦਾ ਨਵਾਂ ਤਰੀਕਾ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਅਜਿਹਾ toolchain ਜੋ ਇੰਨਾ ਤੇਜ਼ ਹੈ ਕਿ ਉਹ ਤੁਹਾਡੇ ਰਸਤੇ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ ਅਤੇ ਤੁਹਾਨੂੰ ਸੋਚਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ।