17 ਅਪ੍ਰੈ 2025·8 ਮਿੰਟ
ਕਿਵੇਂ JavaScript ਨੇ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਪੂਰੀਆਂ ਕੰਪਨੀਆਂ 'ਤੇ ਕਬਜ਼ਾ ਕੀਤਾ
ਬ੍ਰਾਉਜ਼ਰ ਸਕ੍ਰਿਪਟ ਤੋਂ Node.js ਸਰਵਰ ਤੱਕ, JavaScript ਦੇ ਉਭਾਰ ਨੇ ਟੂਲਿੰਗ, ਭਰਤੀ ਅਤੇ ਉਤਪਾਦ ਸ਼ਿਪਿੰਗ ਨੂੰ ਦੁਬਾਰਾ ਰੂਪ ਦਿੱਤਾ—ਇੱਕ ਹੀ ਭਾਸ਼ਾ ਪੂਰੀਆਂ ਕੰਪਨੀਆਂ ਚਲਾਉਣ ਲੱਗੀ।
ਬ੍ਰਾਉਜ਼ਰ ਸਕ੍ਰਿਪਟ ਤੋਂ Node.js ਸਰਵਰ ਤੱਕ, JavaScript ਦੇ ਉਭਾਰ ਨੇ ਟੂਲਿੰਗ, ਭਰਤੀ ਅਤੇ ਉਤਪਾਦ ਸ਼ਿਪਿੰਗ ਨੂੰ ਦੁਬਾਰਾ ਰੂਪ ਦਿੱਤਾ—ਇੱਕ ਹੀ ਭਾਸ਼ਾ ਪੂਰੀਆਂ ਕੰਪਨੀਆਂ ਚਲਾਉਣ ਲੱਗੀ।
JavaScript ਦੀ ਸ਼ੁਰੂਆਤ ਵੈੱਬਪੇਜਾਂ ਵਿੱਚ ਥੋੜੀ ਜਿਹੀ ਇੰਟਰਐਕਟਿਵਿਟੀ ਜੋੜਨ ਲਈ ਹੋਈ ਸੀ—ਛੋਟੇ ਸਕ੍ਰਿਪਟ ਜੋ ਫਾਰਮ ਵੈਧਤਾ ਜਾਂਚਦੇ, ਇਮੇਜ ਬਦਲਦੇ ਜਾਂ ਡਰੌਪਡਾਊਨ ਦਿਖਾਉਂਦੇ। ਇਹ ਗਾਈਡ ਵੇਖਾਂਦੀ ਹੈ ਕਿ ਉਹ “ਛੋਟੀ ਮਦਦਗਾਰ ਭਾਸ਼ਾ” ਕਿਵੇਂ ਪੂਰੀ ਕੰਪਨੀ-ਵਿਆਪੀ ਪਲੇਟਫਾਰਮ ਬਣੀ: ਉਹੀ ਕੋਰ ਟੈਕਨੋਲੋਜੀ ਹੁਣ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ, ਸਰਵਰ, ਬਿਲਡ ਸਿਸਟਮ, ਆਟੋਮੇਸ਼ਨ ਅਤੇ ਅੰਦਰੂਨੀ ਟੂਲ ਚਲਾਉਂਦੀ ਹੈ।
ਵਿਆਵਹਾਰਕ ਤੌਰ 'ਤੇ, JavaScript ਇਕੋ ਭਾਸ਼ਾ ਹੈ ਜੋ ਹਰ ਮੈਜਰ ਬ੍ਰਾਊਜ਼ਰ ਸਿੱਧਾ ਚਲਾ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਐਸਾ ਕੋਡ ਯੂਜ਼ਰਾਂ ਨੂੰ ਭੇਜਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੁਝ ਵੀ ਇੰਸਟਾਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ, ਤਾਂ JavaScript ਯੂਨੀਵਰਸਲ ਵਿਕਲਪ ਹੈ। ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਭਾਗ ਲੈ ਸਕਦੀਆਂ ਹਨ—ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਉਹ JavaScript ਵਿੱਚ ਕੰਪਾਇਲ ਹੋ ਕੇ ਆਉਂਦੀਆਂ ਹਨ ਜਾਂ ਸਰਵਰ 'ਤੇ ਚਲਦੀਆਂ ਹਨ—ਜਦਕਿ JavaScript ਡੈਸਟਿਨੇਸ਼ਨ 'ਤੇ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਚਲਦੀ ਹੈ।
ਪਹਿਲਾ ਹੈ ਬ੍ਰਾਊਜ਼ਰ ਦੌਰ, ਜਿੱਥੇ JavaScript ਪੰਨੇ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਦਾ ਮਿਆਰੀ ਤਰੀਕਾ ਬਣ گئی: ਕਲਿੱਕ ਦੇ ਜਵਾਬ ਵਿੱਚ ਰੀਐਕਟ ਕਰਨਾ, DOM ਨੂੰ ਸੋਧਣਾ, ਅਤੇ ਜਿਵੇਂ ਜਿਵੇਂ ਵੈੱਬ ਸਥਿਰ ਦਸਤਾਵੇਜ਼ ਤੋਂ ਅੱਗੇ ਵਧਿਆ, ਰਿਚਰ ਅਨੁਭਵ ਪੈਦਾ ਕਰਨ ਵਿੱਚ ਯੋਗ ਬਣਨਾ।
ਦੂਜਾ ਹੈ ਬੈਕਐਂਡ ਦੌਰ, ਜਿੱਥੇ ਤੇਜ਼ ਇੰਜਨਾਂ ਅਤੇ Node.js ਨੇ ਸਰਵਰਾਂ 'ਤੇ JavaScript ਚਲਾਉਣਾ ਯਥਾਰਥ ਕੀਤਾ। ਇਸਨੇ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਵਿੱਚ ਇਕੋ ਭਾਸ਼ਾ ਖੋਲ੍ਹ ਦਿੱਤੀ, ਅਤੇ ਇਕ ਪੈਕੇਜ ਇਕੋਸਿਸਟਮ ਨੇ ਰੀਯੂਜ਼ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ।
ਤੀਜਾ ਹੈ ਬਿਜ਼ਨਸ ਪਰੇਸ਼ਨ ਦੌਰ, ਜਿੱਥੇ JavaScript ਟੂਲਿੰਗ "ਗਲੂ" ਬਣ ਗਈ: ਬਿਲਡ ਪਾਈਪਲਾਈਨ, ਟੈਸਟਿੰਗ, ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ, ਡੈਸ਼ਬੋਰਡ, ਆਟੋਮੇਸ਼ਨ ਸਕ੍ਰਿਪਟ ਅਤੇ ਇੰਟੀਗਰੇਸ਼ਨ। ਇੱਥੇ ਤੱਕ ਕਿ ਉਹ ਟੀਮਾਂ ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ “JavaScript ਟੀਮ” ਨਹੀਂ ਮੰਨਦੀਆਂ, ਅਕਸਰ ਰੋਜ਼ਾਨਾ JavaScript-ਅਧਾਰਿਤ ਟੂਲਾਂ ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ।
ਅਸੀਂ ਵੱਡੇ ਮੋੜਾਂ 'ਤੇ ਧਿਆਨ ਦੇਵਾਂਗੇ—ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ, ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਉਤਥਾਨ, Node.js, npm, ਅਤੇ ਫਰੇਮਵਰਕ-ਚਲਿਤ ਐਪਸ ਵੱਲ ਸ਼ਿਫਟ—ਨਾ ਕਿ ਹਰ ਲਾਇਬ੍ਰੇਰੀ ਜਾਂ ਟਰੇਂਡ ਦੀ ਫ਼ਿਲਹਾਲ ਦੀ ਸੂਚੀ ਬਣਾਈਏ।
JavaScript 1995 ਵਿੱਚ Netscape 'ਤੇ ਬਣਾਈ ਗਈ ਸੀ ਤਾਂ ਜੋ ਵੈੱਬਪੇਜਾਂ ਵਿੱਚ ਇੰਟਰਐਕਟੀਵਿਟੀ ਜੋੜੀ ਜਾ ਸਕੇ ਬਿਨਾਂ ਸਰਵਰ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਜਾਂ ਪੂਰੀ "ਸੌਫਟਵੇਅਰ ਇੰਸਟਾਲੇਸ਼ਨ" ਦੇ। Brendan Eich ਨੇ ਪਹਿਲੀ ਵਰਜ਼ਨ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਈ, ਅਤੇ ਇਹਦਾ ਮੂਲ ਲਕਸ਼ਣ ਨਿਰਾਲਾ ਸੀ: ਵੈੱਬ ਲੇਖਕਾਂ ਨੂੰ ਫਾਰਮਾਂ ਦੀ ਜਾਂਚ ਕਰਨ, ਬਟਨ ਕਲਿੱਕ ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਆ ਕਰਨ এবং ਪੰਨਿਆਂ ਨੂੰ ਹੋਰ ਜ਼ਿ਼ਂਦਾ ਮਹਿਸੂਸ ਕਰਵਾਉਣ ਦੇ ਯੋਗ ਬਣਾਉਣਾ।
ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਸੀਮਾਵਾਂ ਨੇ ਇਹ ਨਿਰਧਾਰਤ ਕੀਤਾ ਕਿ JavaScript ਕਿੰਨਾ ਹੋ ਸਕਦਾ ਹੈ। ਕੰਪਿਊਟਰ ਥੱਲੇ ਤੇਜ਼ ਨਹੀਂ ਸਨ, ਬ੍ਰਾਊਜ਼ਰ ਬੁਨਿਆਦੀ ਸਨ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਸਾਈਟਾਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਲੇਖਾਂ ਅਤੇ ਕੁਝ ਤਸਵੀਰਾਂ ਨਾਲ ਸਧਾਰਨ ਸਨ। ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਹਲਕੇ ਅਤੇ ਮਾਫੀਯਾਬ ਰੱਖਣਾ ਪੈਂਦਾ ਸੀ—ਛੋਟੇ ਟੁਕੜੇ ਜੋ ਪੰਨੇ ਨੂੰ ਫ੍ਰੀਜ਼ ਕੀਤੇ ਬਿਨਾਂ ਚਲ ਸਕਦੇ।
ਇਸ ਲਈ ਸ਼ੁਰੂਆਤੀ JavaScript ਅਕਸਰ HTML ਵਿੱਚ ਛਿੱਟ-ਛਿੱਟ ਕਰਕੇ "ਥੋੜ੍ਹੀ ਲਾਜਿਕ" ਵਾਂਗ ਲੱਗਦੀ ਸੀ: ਦੇਖੋ ਕਿ ਈਮੇਲ ਫੀਲਡ ਵਿੱਚ @ ਹੈ ਜਾਂ ਨਹੀਂ, ਇੱਕ alert ਦਿਖਾਓ, ਜਾਂ ਲਿੰਕ 'ਤੇ ਹੋਵਰ ਕਰਨ ਤੇ ਇਕ ਇਮੇਜ ਬਦਲੋ।
ਇਸ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਵੈੱਬ ਪੰਨਾ ਮੁੱਖ ਤੌਰ 'ਤੇ ਜੋ ਕੁਝ ਦਿਖਾਉਂਦਾ ਸੀ ਉਹੀ ਕਰਦਾ ਸੀ। JavaScript ਨੂੰ ਪੰਨੇ ਵਿੱਚ ਸਿੱਧਾ ਜੋੜਨ ਨਾਲ, ਇਹ ਯੂਜ਼ਰ ਕਾਰਵਾਈਆਂ ਦਾ ਫੌਰਨ ਜਵਾਬ ਦੇ ਸਕਦਾ ਸੀ। ਇੱਕ ਛੋਟਾ ਸਕ੍ਰਿਪਟ ਵੀ ਕਹਿ ਸਕਦਾ ਸੀ:
ਇਹ ਬਰਾਊਜ਼ਰ ਦੇ ਇੱਕ ਡੌਕਯੂਮੈਂਟ ਦਰਸ਼ਕ ਤੋਂ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਰਨਟਾਈਮ ਬਣਨ ਦੀ ਸ਼ੁਰੂਆਤ ਸੀ।
ਨੁਕਸ ਇਹ ਸੀ ਕਿ ਪਰਿਣਾਮ ਅਣਪੂਛ ਹੋ ਸਕਦੇ ਸਨ। ਬ੍ਰਾਊਜ਼ਰ ਹਮੇਸ਼ਾ JavaScript ਨੂੰ ਇਕੋ ਜਿਹਾ ਨਹੀਂ ਸਮਝਦੇ ਸਨ, ਅਤੇ ਪੰਨੇ ਨਾਲ ਇੰਟਰਐਕਟ ਕਰਨ ਵਾਲੇ API (ਸ਼ੁਰੂਆਤੀ DOM ਵਿਹਾਰ, ਇਵੈਂਟ ਮਾਡਲ ਅਤੇ ਐਲਿਮੈਂਟ ਵਿਧੀਆਂ) ਬਹੁਤ ਵੱਖ-ਵੱਖ ਸਨ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਹਰ ਬ੍ਰਾਊਜ਼ਰ ਲਈ ਵੱਖ-ਵੱਖ ਕੋਡ ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ, ਟੈਸਟ ਕਰਨਾ ਪੈਂਦਾ ਸੀ, ਅਤੇ ਇਸ ਗੱਲ ਨੂੰ ਸਵੀਕਾਰਣਾ ਪੈਂਦਾ ਸੀ ਕਿ ਜੋ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਕੰਮ ਕਰਦਾ ਉਹ ਦੂਜੇ 'ਤੇ ਟੁੱਟ ਸਕਦਾ ਹੈ।
1990 ਦੇ ਅੰਤ ਅਤੇ 2000 ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ, ਬ੍ਰਾਊਜ਼ਰ نئی-ਨਵੀਂ ਫੀਚਰ ਜਲਦੀ ਜਲਦੀ ਰਿਲੀਜ਼ ਕਰਕੇ ਇਕ-ਦੂਜੇ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰ ਰਹੇ ਸਨ। Netscape ਅਤੇ Internet Explorer ਸਿਰਫ਼ ਤੇਜ਼ੀ ਵਿੱਚ ਨਹੀਂ, ਬਲਕਿ JavaScript ਵਿਹਾਰ, DOM API ਅਤੇ ਮਲਕੀਅਤੀ ਐਕਸਟੈਂਸ਼ਨਾਂ 'ਚ ਵੀ ਮੁਕਾਬਲਾ ਕਰ ਰਹੇ ਸਨ।
ਡਿਵੈਲਪਰਾਂ ਲਈ ਇਹ ਮਤਲਬ ਸੀ ਕਿ ਉਹੀ ਸਕ੍ਰਿਪਟ ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਕੰਮ ਕਰ ਸਕਦਾ ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਟੁੱਟ ਸਕਦਾ ਸੀ। ਤੁਸੀਂ ਅਜਿਹੇ ਬੱਗ ਦੇਖਦੇ ਜਿੱਥੇ ਤੁਸੀਂ ਆਪਣੀ ਗਲਤੀ ਨਹੀਂ ਮੰਨਦੇ: ਵੱਖ-ਵੱਖ ਇਵੈਂਟ ਮਾਡਲ, ਗੁੰਮ ਹੋਏ ਮੈਥਡ, ਅਤੇ ਅਸਥਿਰ ਐਜ ਕੇਸ। ਸਾਈਟ ਸ਼ਿਪ ਕਰਨ ਲਈ ਅਕਸਰ ਇਕੋ ਲਾਜਿਕ ਦੇ ਦੋ ਵਰਜ਼ਨ ਲਿਖਣੇ ਪੈਂਦੇ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ-ਡਿਟੈਕਸ਼ਨ ਹੈਕਸ ਦੀ ਲੋੜ ਪੈਂਦੀ।
ਇਸ ਗਲ-ਬਹਿਬੁੱਧੀ ਨੂੰ ਘਟਾਉਣ ਲਈ, JavaScript ਨੂੰ ਇੱਕ ਸਾਂਝਾ ਪਰਿਭਾਸ਼ਾ ਦੀ ਲੋੜ ਸੀ ਜੋ ਕਿਸੇ ਇਕ ਬ੍ਰਾਊਜ਼ਰ ਵੇਂਡਰ ਦੇ ਕਬਜ਼ੇ 'ਚ ਨਾ ਹੋਵੇ। ਉਹ ਪਰਿਭਾਸ਼ਾ bani ECMAScript—ਉਸ ਮਿਆਰ ਜੋ ਕੋਰ ਭਾਸ਼ਾ ਨੂੰ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ (ਸਿੰਟੈਕਸ, ਟਾਈਪਸ, ਫੰਕਸ਼ਨ, ਆਬਜੈਕਟ ਆਦਿ)।
ਇੱਕ ਮਾਨਸਿਕ ਮਾਡਲ:
ਜਿਵੇਂ ਹੀ ਵੇਂਡਰ ECMAScript ਵਰਜ਼ਨਾਂ 'ਤੇ ਮੱਤ ਇਕੱਠਾ ਕਰਨ ਲੱਗੇ, ਭਾਸ਼ਾ ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਵੱਧ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਗਈ। ਅਸਮਿਲਤਾਵਾਂ ਇਕੋ-ਮੁਹੀਂ ਨਹੀਂ ਛੁਟ ਜਾਂਦੀਆਂ—ਭਾਸ਼ਾ ਕੋਰ ਤੋਂ ਬਾਹਰ ਦੀਆਂ API (ਜਿਵੇਂ DOM ਦੇ ਹਿੱਸੇ) ਅਜੇ ਵੀ ਵੱਖਰਾ ਰਹਿੰਦੇ—ਪਰ ਨੀਂਵ ਸਥਿਰ ਹੋ ਗਈ। ਸਮੇਂ ਦੇ ਨਾਲ ਬਿਹਤਰ ਟੈਸਟ ਸੂਟ ਅਤੇ ਸਾਂਝੀਆਂ ਉਮੀਦਾਂ ਨੇ "ਮੇਰੇ ਬ੍ਰਾਉਜ਼ਰ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਕਹਿਣਾ ਘੱਟ ਕਬੂਲਯੋਗ ਬਣਾਇਆ।
ਜਿਵੇਂ ECMAScript ਵਧਿਆ, ਬੈਕਵਰਡ ਕੰਪੈਟਬਿਲਿਟੀ ਇੱਕ ਅਟਲ ਵਾਅਦਾ ਬਣ ਗਿਆ: ਪੁਰਾਣੀਆਂ ਸਾਈਟਾਂ ਨੂੰ ਕੰਮ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ। ਇਸੀ ਲਈ ਵਿਰਾਸਤੀ ਪੈਟਰਨ—var, ਅਜਿਹੇ ਸਮਾਨਤਾ ਨਿਯਮ, ਅਤੇ ਮਾਡਲ-ਪੂਰਵ ਵਰਕਅਰਾਊਂਡ—ਇਕੋighborhood ਰਹਿ ਗਏ। ਵੈੱਬ ਇੱਕ ਕਠੋਰ ਰੀਸੈਟ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇਸ ਲਈ JavaScript ਨਵੇਂ ਫੀਚਰ ਜੋੜ ਕੇ ਵਧਿਆ, ਪੁਰਾਣੀਆਂ ਚੀਜ਼ਾਂ ਹਟਾ ਕੇ ਨਹੀਂ।
Ajax ਤੋਂ ਪਹਿਲਾਂ, ਜ਼ਿਆਦਾਤਰ ਵੈੱਬਸਾਈਟਾਂ ਫਾਰਮ ਵਾਂਗ ਵਰਤਦੀਆਂ: ਤੁਸੀਂ ਲਿੰਕ 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਜਾਂ ਫਾਰਮ ਸਬਮਿਟ ਕਰਦੇ, ਬ੍ਰਾਊਜ਼ਰ ਪੂਰਾ ਪੰਨਾ ਰੀਲੋਡ ਕਰਦਾ, ਅਤੇ ਤੁਸੀਂ ਸਰਵਰ ਦੇ ਨਵੇਂ HTML ਦੀ ਉਡੀਕ ਕਰਦੇ।
Ajax (ਅਸਿੰਕ੍ਰੋਨਸ JavaScript ਅਤੇ XML) ਨੇ ਇਸ ਪੈਟਰਨ ਨੂੰ ਬਦਲ ਦਿੱਤਾ। JavaScript ਨਾਲ, ਇੱਕ ਪੰਨਾ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਸਰਵਰ ਤੋਂ ਡੇਟਾ ਮੰਗ ਸਕਦਾ ਸੀ ਅਤੇ ਕੇਵਲ ਉਸ ਹਿੱਸੇ ਨੂੰ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਸੀ—ਕੋਈ ਪੂਰਾ ਰੀਲੋਡ ਨਹੀਂ।
Ajax ਨੇ ਵੈੱਬ ਨੂੰ "ਪੰਨਾਂ ਦੀ ਸਿਖਲਾਈ" ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਣ ਤੋਂ ਬਚਾ ਕੇ ਇਕ ਇੰਟਰਐਕਟਿਵ ਪ੍ਰੋਗਰਾਮ ਵਾਂਗ ਬਣਾਇਆ। ਖੋਜ ਬਾਕਸ ਟਾਈਪ ਕਰਨ 'ਤੇ ਸੁਝਾਅ ਦਿਖਾ ਸਕਦਾ ਸੀ। ਸ਼ੌਪਿੰਗ ਕਾਰਟ ਟੋਟਲ ਤੁਰੰਤ ਅਪਡੇਟ ਹੋ ਸਕਦਾ ਸੀ। ਟਿੱਪਣੀਆਂ ਪੋਸਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਫੌਰਨ ਦਿਖਾਈ ਦੇ ਸਕਦੀਆਂ ਸਨ ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਪੰਨੇ ਦੇ ਸਿਖਰ 'ਤੇ ਲੈ ਜਾਣ ਦੇ।
ਇਹ ਸਿਰਫ਼ ਵਧੀਆ ਇੰਟਰਫੇਸ ਨਹੀਂ ਸੀ—ਇਸ ਨੇ ਰਗੜ ਘਟਾਈ। ਲੋਕ ਹਰ ਛੋਟੀ ਕਾਰਵਾਈ ਲਈ "ਕਲਿੱਕ → ਉਡੀਕ → ਰੀਲੋਡ" ਸਹਿਣ ਨਹੀਂ ਕਰਦੇ।
Gmail ਵਰਗਿਆਂ ਉਤਪਾਦਾਂ ਨੇ ਦਰਸਾਇਆ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਐਪ-ਨੁਮਾ ਇੰਟਰਐਕਸ਼ਨਾਂ ਨੂੰ ਸੰਭਾਲ ਸਕਦਾ ਹੈ: ਤੇਜ਼ ਇਨਬੌਕਸ ਅਪਡੇਟ, ਫੌਰਨ ਲੇਬਲਿੰਗ, ਸੁਚਾਰੂ ਨੈਵੀਗੇਸ਼ਨ, ਅਤੇ ਘੱਟ ਰੁਕਾਵਟਾਂ। ਜਦੋਂ ਵਰਤੋਂਕਾਰਾਂ ਨੇ ਇਹ ਤਜ਼ਰਬਾ ਦੇਖਿਆ, ਉਹ ਹੋਰ ਸਾਈਟਾਂ ਲਈ ਵੀ ਇਹੀ ਮਿਆਰ ਮੰਗਣ ਲੱਗੇ।
Ajax ਟੀਮਾਂ ਨੂੰ "ਡੇਟਾ" ਨੂੰ "ਪੰਨੇ" ਤੋਂ ਵੱਖ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ। ਪੂਰੇ HTML ਪੰਨੇ ਭੇਜਣ ਦੀ ਥਾਂ, ਸਰਵਰ ਵਧੇਰੇ ਤਰ JSON ਵਿੱਚ ਸਾਂਝਾ ਡੇਟਾ ਰਿਟਰਨ ਕਰਨ ਲੱਗੇ। ਬ੍ਰਾਊਜ਼ਰ—JavaScript ਨਾਲ—ਅਸਲ ਵਿੱਚ ਇਕ ਗਾਹਕ ਬਣ ਗਿਆ ਜੋ ਰੇਂਡਰਿੰਗ, ਇੰਟਰਐਕਸ਼ਨਾਂ ਅਤੇ ਸਟੇਟ ਦੇ ਜ਼ਿੰਮੇਵਾਰ ਸੀ।
ਨੁਕਸ ਇਹ ਸੀ ਕਿ ਜਟਿਲਤਾ ਵਧੀ। ਹੋਰ ਐਪ ਲਾਜਿਕ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਜਾਂਚ, UI ਸਟੇਟ, ਕੈਸ਼ਿੰਗ, ਐਰਰ ਹੈਂਡਲਿੰਗ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਸੰਭਾਲ ਵਿੱਚ ਚਲੇ ਗਏ। ਇਸ ਨੇ ਭਾਰੀ ਫਰੰਟਐਂਡ ਟੂਲਿੰਗ ਅਤੇ ਆਖਿਰਕਾਰ ਫੁੱਲ ਸਿੰਗਲ-ਪੇਜ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਬਿਜਲੀ ਜਗਾਈ ਜਿੱਥੇ ਸਰਵਰ ਮੁੱਖ ਤੌਰ 'ਤੇ API ਪ੍ਰਦਾਨ ਕਰਦਾ ਅਤੇ ਫਰੰਟਐਂਡ ਅਸਲ ਐਪ ਵਾਂਗ ਕੰਮ ਕਰਦਾ।
ਸ਼ੁਰੂਆਤੀ JavaScript ਮੁਸ਼ਕਲ ਇਸਕਾਰਨ ਨਹੀਂ ਸੀ ਕਿ ਭਾਸ਼ਾ ਅਸੰਭਵ ਸੀ—ਮੁਸ਼ਕਲ ਇਸ ਲਈ ਸੀ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਵਾਤਾਵਰਣ ਗੰਦਾ ਸੀ। DOM ਸਕ੍ਰਿਪਟਿੰਗ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਇਵੈਂਟ ਮਾਡਲ, ਅਸਥਿਰ ਐਲਿਮੈਂਟ API ਅਤੇ ਲੇਆਉਟ ਖ਼ਾਸੀਆਂ ਸ਼ਾਮਿਲ ਸਨ ਜੋ ਉਪਭੋਗਤਾ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਮੁਤਾਬਕ ਬਦਲ ਜਾਂਦੀਆਂ। ਸਧਾਰਨ ਕੰਮ ਜਿਵੇਂ "ਇਸ ਐਲਿਮੈਂਟ ਨੂੰ ਲੱਭੋ ਅਤੇ ਬਟਨ ਕਲਿੱਕ 'ਤੇ ਛੁਪਾ ਦਿਓ" ਵੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਸ਼ਰਤਾਂ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ-ਨਿਰਭਰ ਹੈਕਸ ਬਣ ਸਕਦੇ ਸਨ।
ਡਿਵੈਲਪਰ ਬਹੁਤ ਸਮਾਂ ਮੁਕਾਬਲਾ ਕਰਨ ਵਿੱਚ ਗੁਜ਼ਾਰਦੇ ਸਨ ਬਜਾਏ ਨਵੇਂ ਫੀਚਰ ਬਣਾਉਣ ਦੇ। ਐਲਿਮੈਂਟ ਚੁਣਨਾ ਬ੍ਰਾਊਜ਼ਰ-ਅਨੁਸਾਰ ਫਰਕ ਕਰਦਾ ਸੀ, ਇਵੈਂਟ ਜੋੜਨਾ ਅਸਥਿਰ ਸੀ, ਅਤੇ ਸਟਾਈਲ ਮੈਨਿਪੁਲੇਸ਼ਨ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਵਰਤਦਾ। ਨਤੀਜਾ ਇਹ ਸੀ ਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਭਾਰੀ ਕਲਾਈਐਂਟ-ਸਾਈਡ ਕੋਡ ਤੋਂ ਬਚਦੀਆਂ ਜਾਂ richer ਅਨੁਭਵ ਲਈ Flash ਵਰਗੀਆਂ ਪਲੱਗਇਨਜ਼ ਦੀਆਂ ਰਾਹੀਂ ਜਾ ਰਹੀਆਂ ਸਨ।
jQuery ਦੀ ਵੱਡੀ ਚਾਲ ਇਹ ਸੀ ਕਿ ਇਸਨੇ ਇੱਕ ਸਰਲ, ਪੜ੍ਹਨਯੋਗ API ਦਿੱਤੀ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ-ਵੱਖਰੇ ਫਰਕਾਂ ਨੂੰ ਪਿੱਛੇ ਲੁਕਾ ਲਿਆ। ਇੱਕ ਸਿੰਗਲ ਸਿਲੈਕਟਰ ਸਿੰਟੈਕਸ ਲਗਭਗ ਹਰ ਥਾਂ ਕੰਮ ਕਰਦਾ, ਇਵੈਂਟ ਹੈਂਡਲਿੰਗ ਪੈਟਰਨਕ ਵਿੱਚ ਆ ਗਿਆ, ਅਤੇ ਆਮ UI ਪ੍ਰਭਾਵ ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਲ 'ਤੇ ਮਿਲ ਗਏ। ਦੱਸਣ ਦੀ ਥਾਂ, ਲੋਕ "jQuery ਤਰੀਕੇ" ਨੂੰ ਸਿੱਖਦੇ ਸਨ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਨਤੀਜੇ ਸ਼ਿਪ ਕਰਦੇ ਸਨ।
ਇਹ ਆਸਾਨੀ ਸਾਂਝੇ ਸੱਭਿਆਚਾਰਕ ਅਰਥ ਰੱਖਦੀ ਸੀ। JavaScript ਉਹ ਪਹਿਲੀ ਭਾਸ਼ਾ ਬਣ ਗਈ ਜੋ ਬਹੁਤ ਸਾਰੇ ਵੈੱਬ ਡਿਵੈਲਪਰਾਂ ਨੇ ਸਿੱਖੀ ਕਿਉਂਕਿ ਇਹ ਦਰਸ਼ਨੀ, ਇੰਟਰਐਕਟਿਵ ਤਰੱਕੀ ਦਾ ਰਾਹ ਸੀ। ਟਿਊਟੋਰਿਯਲ, ਸ ਨਿਪੇਟਸ, ਅਤੇ ਪਲੱਗਇਨਜ਼ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲੇ; ਤੁਸੀਂ ਕੁਝ ਲਾਈਨਾਂ ਕਾਪੀ ਕਰਕੇ ਕੁਝ ਆਧੁਨਿਕ ਸਮਾਨ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਸੀ।
ਜਿਵੇਂ ਜਿਵੇਂ ਬ੍ਰਾਊਜ਼ਰ ਸੁਧਰੇ ਅਤੇ ਪਲੱਗਇਨਜ਼ ਘੱਟ ਮਨਜ਼ੂਰ ਹੋਏ (ਸੁਰੱਖਿਆ ਮੁੱਦੇ, ਮੋਬਾਈਲ ਸਹਾਇਤਾ ਦੀ ਘਾਟ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਚਿੰਤਾਵਾਂ), ਟੀਮਾਂ ਵੱਧ ਕਰਕੇ ਨੇਟਿਵ ਵੈੱਬ ਟੈਕਨੋਲੋਜੀ ਨੂੰ ਚੁਣਨ ਲੱਗੀਆਂ। jQuery ਨੇ ਉਸ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਨੂੰ ਪਾਰ ਕਰਨ ਵਿੱਚ ਮੱਦਦ ਕੀਤੀ: ਇਸਨੇ DOM ਪ੍ਰੋਗਰਾਮਿੰਗ ਦੀ ਬਾਧਾ ਘਟਾਈ, ਅਤੇ ਜਦੋਂ ਪਲੇਟਫਾਰਮ ਬਾਲਗ ਹੋ ਗਿਆ, ਇੱਕ ਪੀੜ੍ਹੀ ਪਹਿਲਾਂ ਹੀ JavaScript ਉੱਤੇ ਕਾਫ਼ੀ ਪਕੜ ਬਣ ਚੁੱਕੀ ਸੀ ਜਿਹੜੀ ਅਗਲੀ ਲਹਿਰ ਬਣਾਉਣ ਲਈ ਯੋਗ ਸੀ।
ਕਈ ਸਾਲਾਂ ਤੱਕ, JavaScript ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਸੀਮਾ ਗਤੀ ਸੀ। ਸ਼ੁਰੂਆਤੀ ਪੰਨੇ ਇਸਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦੇ ਸਨ ਕਿਉਂਕਿ ਸਕ੍ਰਿਪਟ ਛੋਟੇ ਸਨ: ਫਾਰਮ ਵੈਧਤਾ, ਮੈਨੂ ਟੌਗਲ, ਥੋੜ੍ਹੀ ਇੰਟਰਐकਟਿਵਿਟੀ। ਜਦੋਂ ਡਿਵੈਲਪਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਪੂਰੇ ਐਪ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਲੱਗੇ, ਤਾਂ ਪ੍ਰਦਰਸ਼ਨ ਹੀ ਸੀਮਾ ਬਣ ਗਿਆ।
V8 Google ਦਾ JavaScript ਇੰਜਨ ਹੈ, ਜੋ Chrome ਲਈ ਬਣਾਇਆ ਗਿਆ। ਇੱਕ "ਇੰਜਨ" ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਤੁਹਾਡੇ JavaScript ਨੂੰ ਪੜ੍ਹਦਾ ਅਤੇ ਚਲਾਉਂਦਾ ਹੈ। V8 ਦਾ ਉਤਕ੍ਰਾਂਤਿਕ ਕਦਮ ਇਹ ਸੀ ਕਿ ਇਸਨੇ JavaScript ਨੂੰ ਇੱਕ ਹੌਲੀ-ਹੌਲੀ ਵਿਆਖਿਆਤ ਭਾਸ਼ਾ ਵਾਂਗ ਨਾ ਦੇਖਿਆ, ਸਗੋਂ ਕੋਡ ਨੂੰ ਰਨਟਾਈਮ 'ਤੇ ਜ਼ੋਰਦਾਰ ਢੰਗ ਨਾਲ ਆਪਟੀਮਾਈਜ਼ ਕਰਨ ਯੋਗ ਸਮਝਿਆ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ: V8 ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ JavaScript ਨੂੰ ਮਸ਼ੀਨ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਲੱਗਾ, ਫਿਰ ਜਿਵੇਂ ਜਿਵੇਂ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਚੱਲਦਾ, ਹਾਟ ਕੋਡ ਪਾਥਾਂ ਨੂੰ ਦੁਬਾਰਾ ਆਪਟੀਮਾਈਜ਼ ਕਰਦਾ। ਇਸ ਨਾਲ ਲੇਟੈਂਸੀ ਘਟ ਗਈ, ਐਨੀਮੇਸ਼ਨ ਮ੍ਰਿਦੁ ਹੋਏ, ਅਤੇ ਯੂਜ਼ਰ ਕਲਿੱਕ ਅਤੇ ਸਕ੍ਰੀਨ ਪ੍ਰਤੀਕ੍ਰਿਆ ਦੇ ਦਰਮਿਆਨ ਦਾ ਸਮਾਂ ਘੱਟ ਹੋ ਗਿਆ।
ਜਦੋਂ JavaScript ਤੇਜ਼ ਹੋ ਗਿਆ, ਟੀਮਾਂ ਹੋਰ ਲਾਜਿਕ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਰੱਖ ਸਕਣਗੀਆਂ ਬਿਨਾਂ ਅਨੁਭਵ ਨੂੰ ਖਰਾਬ ਕੀਤੇ। ਇਸ ਨਾਲ ਉਸਨੂੰ ਬਣਾਉਣ ਯੋਗ ਚੀਜ਼ਾਂ ਵਧ ਗਈਆਂ:
ਪੈਰਫੋਰਮੈਂਸ ਸਿਰਫ਼ ਮੌਜੂਦਾ ਸਾਈਟਾਂ ਨੂੰ ਵਧੀਆ ਨਹੀਂ ਕੀਤਾ—ਇਸਨੇ ਵੈੱਬ ਤੇ ਹੋ ਸਕਣ ਵਾਲੇ ਸਾਫਟਵੇਅਰ ਦੀ ਸ਼੍ਰੇਣੀ ਨੂੰ ਵੀ ਵਧਾ ਦਿੱਤਾ।
ਇੱਕ ਮੁੱਖ ਗਤੀਵਿਧੀ ਸ਼ੁਰੂ ਹੋ ਗਈ:
ਤੇਜ਼ ਇੰਜਨ → ਡਿਵੈਲਪਰ ਹੋਰ JavaScript ਲਿਖਦੇ → ਯੂਜ਼ਰ JS-ਭਾਰ ਵਾਲੀਆਂ ਐਪਾਂ 'ਚ ਵਧੀਕ ਸਮਾਂ ਬਿਤਾਉਂਦੇ → ਬ੍ਰਾਊਜ਼ਰ ਹੋਰ ਇੰਜਨਾਂ 'ਤੇ ਨਿਵੇਸ਼ ਕਰਦੇ।
ਜਿਵੇਂ ਕੰਪਨੀਆਂ ਬਾਜ਼ਾਰ ਹਿੱਸੇ ਲਈ ਮੁਕਾਬਲਾ ਕਰਦੀਆਂ, ਗਤੀ ਇੱਕ ਮੁਖ ਵਿਸ਼ੇਸ਼ਤਾ ਬਣ ਗਈ। ਅਸਲੀ-ਦੁਨੀਆ ਦੇ ਵੈੱਬ ਐਪ ਬੈਂਚਮਾਰਕ ਵਾਂਗ ਕੰਮ ਕਰਦੇ, ਅਤੇ ਹਰ ਸੁਧਾਰ ਨੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਹੋਰ ਪੇਸ਼ਤ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ।
V8 ਅਲੱਗ ਨਹੀਂ ਸੀ। Mozilla ਦਾ SpiderMonkey (Firefox) ਅਤੇ Apple ਦਾ JavaScriptCore (Safari) ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਸੁਧਰਿਆ। ਢ਼ੁੰਢਣਯੋਗ ਗੱਲ ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਇੰਜਨ "ਜਿੱਤਿਆ"—ਬਲਕਿ ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਮੁਕਾਬਲੇ ਕਾਰਨ JavaScript ਲਈ ਤੇਜ਼ੀ ਇੱਕ ਬੇਸਲਾਈਨ ਉਮੀਦ ਬਣ ਗਈ।
ਜਦੋਂ JavaScript ਇੰਨਾ ਤੇਜ਼ ਚੱਲਣ ਲੱਗੀ ਕਿ ਮੰਗਲਥੀ ਤੌਰ 'ਤੇ ਮੰਗੀ ਗਈ ਇੰਟਰਐਕਟਿਵਿਟੀ ਬਿਨਾਂ ਰੁਕੇ ਸੰਭਵ ਹੋ ਗਈ, ਤਾਂ ਇਹ "ਸਿਰਫ਼ ਬ੍ਰਾਊਜ਼ਰ ਸਕ੍ਰਿਪਟ ਭਾਸ਼ਾ" ਰਹਿ ਕੇ ਇੱਕ ਪਲੇਟਫਾਰਮ ਬਣ ਗਈ ਜਿਸ 'ਤੇ ਟੀਮਾਂ ਨਿਵੇਸ਼ ਕਰਨ ਲਾਇਕ ਮੰਨ ਸਕਦੀਆਂ ਸਨ।
Node.js ਇੱਕ ਰਨਟਾਈਮ ਹੈ ਜੋ JavaScript ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਬਾਹਰ ਚਲਾਉਂਦਾ ਹੈ। ਬਟਨ, ਫਾਰਮ ਅਤੇ ਪੰਨਾ-ਇੰਟਰਐਕਸ਼ਨਾਂ ਲਈ JavaScript ਲਿਖਣ ਦੀ ਥਾਂ, ਵਿਕਾਸਕਾਰ ਹੁਣੋ ਹੀ ਇੱਕੋ ਭਾਸ਼ਾ ਨਾਲ ਸਰਵਰ, ਕਮਾਂਡ-ਲਾਈਨ ਟੂਲ ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਬਣਾ ਸਕਦੇ ਸਨ।
Node.js ਇੱਕ ਇਵੈਂਟ ਲੂਪ ਦੇ ਆਧਾਰ 'ਤੇ ਬਣਿਆ ਹੈ: ਇਹ ਬਹੁਤ ਸਾਰੀਆਂ ਉਡੀਕ-ਹਾਲਤਾਂ—ਜਿਵੇਂ ਨੈਟਵਰਕ ਰਿਕਵੇਸਟ, ਡੇਟਾਬੇਸ ਕਵੈਰੀ, ਅਤੇ ਫਾਇਲ ਰੀਡ—ਨੂੰ ਇੱਕ-ਇਕ ਥਰੇਡ 'ਚ ਹੀ ਸੰਭਾਲ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਹਰ ਕਨੈਕਸ਼ਨ ਲਈ ਨਵੀਂ ਥਰੇਡ ਬਣਾਉਣ ਦੇ।
ਕਈ ਵੈੱਬਲੋਡਾਂ ਲਈ, ਸਰਵਰ ਗਣਨਾ ਤੋਂ ਵੱਧ ਉਡੀਕ 'ਤੇ ਸਮਾਂ ਖਰਚਦੇ ਹਨ। ਇਵੈਂਟ ਲੂਪ ਮਾਡਲ ਨਾਲ ਬਹੁਤ ਸਾਰੇ concurrent ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਧਾਰਨ ਕੋਡ ਨਾਲ ਸੰਭਾਲਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਉਨ੍ਹਾਂ ਐਪਾਂ ਲਈ ਜੋ "ਲਾਈਵ" ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਜਿੱਥੇ ਅਪਡੇਟ ਤੇਜ਼ੀ ਨਾਲ ਪੈਦੇ ਹੁੰਦੇ ਹਨ।
Node.js ਨੇ ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਥਾਵਾਂ 'ਤੇ ਪਹੁੰਚ ਬਣਾਈ ਜਿੱਥੇ ਪ੍ਰਤੀਕ੍ਰਿਆ ਮਹੱਤਵਪੂਰਨ ਸੀ:
ਭਾਵੇਂ ਟੀਮਾਂ ਹੁਣ ਵੀ ਕੁਝ ਮੁੱਖ ਸਿਸਟਮ ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਚਲਾਉਂਦੀਆਂ ਹੋਣ, Node.js ਅਕਸਰ "ਗਲੂ" ਸਰਵਿਸ ਬਣ ਜਾਂਦਾ: ਰਿਕਵੇਸਟ ਹੈਂਡਲ ਕਰਨਾ, ਹੋਰ ਸਿਸਟਮਾਂ ਨੂੰ ਆਰਥ-ਠਿਕਾਣਾ ਕਰਨਾ, ਜਾਂ ਅੰਦਰੂਨੀ ਯੂਟਿਲਿਟੀ ਨੂੰ ਚਲਾਉਣਾ।
ਇੱਕ ਵੱਡਾ ਬਦਲਾਅ ਤਕਨੀਕੀ ਨਾਲੋਂ ਸੱਭਿਆਚਾਰਕ ਸੀ। ਜਦੋਂ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਦੋਹਾਂ JavaScript ਵਰਤਦੇ ਹਨ, ਟੀਮਾਂ ਵੈਧਤਾ ਨਿਯਮ, ਡੇਟਾ ਮਾਡਲ, ਅਤੇ ਕਈ ਵਾਰ ਬਿਜ਼ਨਸ ਲਾਜਿਕ ਸਾਂਝਾ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਡਿਵੈਲਪਰ ਘੱਟ context-switch ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਛੋਟੀ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਮੂਵ ਕਰਦੀ ਹੈ ਅਤੇ ਵੱਡੀ ਟੀਮਾਂ ਲਈ ਕੋਡ ਬਿਲੀਯਨ ਢੰਗ ਨਾਲ ਨਿਯਮਤ ਹੁੰਦਾ ਹੈ।
npm (Node Package Manager) JavaScript ਕੋਡ ਲਈ "ਐਪ ਸਟੋਰ" ਵਾਂਗ ਹੈ। ਸਭ ਕੁਝ ਸਕ੍ਰੈਚ ਤੋਂ ਲਿਖਣ ਦੀ ਥਾਂ—ਤਾਰੀਖ-ਹੈਂਡਲਿੰਗ, ਰਾਊਟਿੰਗ, ਟੈਸਟਿੰਗ, UI ਵਿਗੇਟ—ਟੀਮ ਇੱਕ ਪੈਕੇਜ ਇੰਸਟਾਲ ਕਰਕੇ ਆਗੇ ਵੱਢ ਸਕਦੀ ਹੈ। ਇਹ ਵਰਕਫਲੋ ("install, import, ship") ਵਿਕਾਸ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ ਅਤੇ JavaScript ਨੂੰ ਭਾਸ਼ਾ ਤੋਂ ਵੱਧ ਇਕ ਸਾਂਝੀ ਟੂਲਬਾਕਸ ਬਣਾਇਆ।
ਜਦੋਂ Node.js ਨੇ JavaScript ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਬਾਹਰ ਉਪਯੋਗੀ ਬਣਾਇਆ, npm ਨੇ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਮਾਡਿਊਲ ਪ੍ਰਕਾਸ਼ਿਤ ਅਤੇ ਰੀਯੂਜ਼ ਕਰਨ ਦਾ ਇੱਕ ਮਿਆਰੀ ਤਰੀਕਾ ਦਿੱਤਾ। ਇੱਕ ਛੋਟੀ ਲਾਇਬ੍ਰੇਰੀ ਜੋ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਲਈ ਬਣੀ ਸੀ, ਅਚਾਨਕ ਹਜ਼ਾਰਾਂ ਹੋਰ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਲਾਭਕਾਰੀ ਹੋ ਸਕਦੀ ਸੀ। ਨਤੀਜਾ ਚੜ੍ਹਤ ਪ੍ਰਗਤੀ ਸੀ: ਹਰ ਨਵਾਂ ਪੈਕੇਜ ਅਗਲੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦਾ।
ਓਪਨ-ਸੋਰਸ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੇ ਪ੍ਰਯੋਗ ਦੀ ਲਾਗਤ ਘਟਾਈ। ਇੱਕ ਸਟਾਰਟਅੱਪ ਕਮ ਟੀਮ ਨਾਲ ਇੱਕ ਯੋਗ ਉਤਪਾਦ ਤਿਆਰ ਕਰ ਸਕਦਾ ਸੀ ਕਿਉਂਕਿ ਕਮਿьюਨਿਟੀ-ਪਾਲਿਤ ਪੈਕੇਜਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋ ਕੇ ਲਾਗ-ਇਨ, ਸੁਰਖਿਆ ਸਹਾਇਕ, ਬਿਲਡ ਟੂਲ ਆਦਿ ਜਮ੍ਹਾ ਕਰ ਸਕਦਾ ਸੀ।
ਜ਼ਿਆਦਾਤਰ npm ਪੈਕੇਜ semantic versioning (semver) ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ, ਜੋ 2.4.1 ਵਰਗਾ ਤਿੰਨ-ਭਾਗ ਵਰਜ਼ਨ ਹੈ:
2) ਬਦਲਾਵ ਕੰਪੈਟਬਿਲਿਟੀ ਤੋੜ ਸਕਦੇ ਹਨ।4) ਸਮਰਥਨਯੋਗ ਤਰੀਕੇ ਨਾਲ ਫੀਚਰ ਜੋੜਦਾ ਹੈ।1) ਬੱਗ ਠੀਕ ਕਰਦਾ ਹੈ।Lockfiles (ਜਿਵੇਂ package-lock.json) ਸਥਿਤੀਆਂ ਨੂੰ ਦਰਜ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਟੀਮ 'ਤੇ ਹਰ ਕੋਈ ਅਤੇ CI ਇੱਕੋ ਨਿਰਭਰਤਾ ਸੈੱਟ ਪ੍ਰਾਪਤ ਕਰੇ। ਇਸ ਨਾਲ "ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ" ਵਾਲੀ ਸਮੱਸਿਆ ਰੁਕਦੀ ਹੈ ਜੋ ਛੋਟੀ ਵਰਜ਼ਨ ਅੰਤਰਾਂ ਨਾਲ ਆ ਸਕਦੀ ਹੈ।
ਆਸਾਨ ਇੰਸਟਾਲ ਦੇ ਨੁਕਸ ਇਹ ਹਨ ਕਿ ਬਹੁਤ ਆਸਾਨੀ ਨਾਲ ਬੇਸ਼ੁਮਾਰ ਨਿਰਭਰਤਾਵਾਂ ਜਮ੍ਹਾ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਪ੍ਰੋਜੈਕਟ ਸੈਂਕੜਿਆਂ ਅਪਾਰੋਕਸ਼ ਨਿਰਭਰਤਾਵਾਂ ਇਕੱਠੀਆਂ ਕਰ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਅਪਡੇਟ ਕੰਮ ਅਤੇ ਸਪਲਾਈ-ਚੇਨ ਰਿਸਕ ਵਧਦਾ ਹੈ। ਕੁਝ ਪੈਕੇਜ ਅਣ-ਰਖਿਆ ਹੋ ਸਕਦੇ ਹਨ, ਟੀਮਾਂ ਨੂੰ ਪੁਰਾਣੇ ਵਰਜ਼ਨਾਂ 'ਤੇ ਫਿੱਟ ਹੋਣ ਜਾਂ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਬਦਲਣ ਜਾਂ ਆਪਣਾ ਹੀ ਸੰਭਾਲਣਾ ਪੈ ਸਕਦਾ ਹੈ। ਇਕੋਸਿਸਟਮ ਨੇ ਤੇਜ਼ੀ ਦਿੱਤੀ—ਪਰ ਇਸ ਨੇDependency hygiene ਨੂੰ ਅਸਲ ਹਿੱਸਾ ਵੀ ਬਣਾ ਦਿੱਤਾ।
ਸ਼ੁਰੂਆਤੀ ਵੈੱਬਸਾਈਟਾਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਸਰਵਰ 'ਤੇ ਟੈmplੇਟ ਗਠਤ ਕਰਦੀਆਂ ਸਨ। ਫਿਰ Single-Page Applications (SPAs) ਨੇ ਮਾਡਲ ਉਲਟ ਦਿੱਤਾ: ਬ੍ਰਾਉਜ਼ਰ "ਐਪ ਰਨਟਾਈਮ" ਬਣ ਗਿਆ, ਡੇਟਾ ਲਿਆਉਂਦਾ ਅਤੇ UI ਰੇਂਡਰ ਕਰਦਾ ਬਿਨਾਂ ਪੂਰੇ ਪੰਨੇ ਨੂੰ ਰੀਲੋਡ ਕੀਤੇ।
ਇਹ ਬਦਲਾਅ ਸਿਰਫ਼ ਕੋਡ ਨੂੰ ਨਹੀਂ ਬਦليا—ਜਿਮੇਵਾਰੀ ਨੂੰ ਵੀ ਬਦਲ ਦਿੱਤਾ। ਫਰੰਟਐਂਡ ਕੰਮ "ਇਸ ਪੰਨੇ ਨੂੰ ਠੀਕ ਦਿਖਾਓ" ਤੋਂ ਰਾਉਟਿੰਗ, ਸਟੇਟ, ਕੈਸ਼ਿੰਗ, ਐਕਸੇਸੀਬਿਲিটি ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਬਜਟ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਤੱਕ ਵਧਿਆ। ਡਿਜ਼ਾਇਨਰ, ਬੈਕਐਂਡ ਇੰਜੀਨੀਅਰ ਅਤੇ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਹੁਣ ਕੰਪੋਨੈਂਟ ਅਤੇ ਯੂਜ਼ਰ ਫਲੋਅ 'ਤੇ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨ ਲੱਗੀਆਂ।
ਜਿਵੇਂ SPA ਵੱਡੀਆਂ ਹੋਈਆਂ, ਐਡ-ਹੌਕ JavaScript ਨੂੰ ਸੰਭਾਲਣਾ ਮੁਸ਼ਕਲ ਹੋ ਗਿਆ। React, Angular, ਅਤੇ Vue ਨੇ UI ਜਟਿਲਤਾ ਨੂੰ ਆਯੋਜਿਤ ਕਰਨ ਲਈ ਪੈਟਰਨ ਦਿੱਤੇ:
ਘੱਟ-ਜ਼ਿਆਦਾ, ਫਰੇਮਵਰਕਾਂ ਨੇ ਸੰਸਥਾਵਾਂ 'ਚ ਸਾਂਝੀ ਰੀਤੀ-ਰਿਵਾਜ ਲਈ ਮੌਕਾ ਦਿੱਤਾ। ਨਵੇਂ ਇੰਜੀਨੀਅਰ ਜਦੋਂ ਜੁੜਦੇ, ਉਹ ਇੱਕੋ ਜਿਹੀ ਮਾਨਸਿਕ ਮਾਡਲ ਨੂੰ ਪਛਾਣ ਸਕਦੇ।
SPA ਕਦੇ-ਕਦੇ ਪਹਿਲੀ-ਲੋਡ ਤੇਜ਼ੀ ਅਤੇ SEO ਨਾਲ ਸੰਘਰਸ਼ ਕਰਦੇ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਕਾਫ਼ੀ JavaScript ਡਾਉਨਲੋਡ ਤੇ ਚਲਾਉਣੀ ਪੈਂਦੀ ਸੀ ਪਹਿਲੀ ਸਮੱਗਰੀ ਵੇਖਾਉਣ ਲਈ।
Server-Side Rendering (SSR) ਅਤੇ "ਯੂਨੀਵਰਸਲ" ਐਪ ਨੇ ਇਸ ਦਰਾਰ ਨੂੰ ਪੂਰਾ ਕੀਤਾ: ਪਹਿਲਾ ਨਜ਼ਾਰਾ ਸਰਵਰ 'ਤੇ ਰੈਂਡਰ ਕਰੋ ਤਾਂ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਦਿਖੇ ਅਤੇ ਵੇਰਵੇਵੰਦ ਬਣੇ, ਫਿਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ hydrate ਕਰਕੇ ਇੰਟਰਐਕਟਿਵ ਬਣਾਓ। ਇਹ ਤਰੀਕਾ Next.js (React) ਅਤੇ Nuxt (Vue) ਵਰਗੇ ਫਰੇਮਵਰਕਾਂ ਨਾਲ ਆਮ ਹੋ गया, ਖਾਸ ਕਰਕੇ ਸਮੱਗਰੀ-ਭਰਪੂਰ ਪੰਨਿਆਂ ਅਤੇ ਈ-ਕਾਮਰਸ ਲਈ।
ਜਦੋਂ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਦੋਹਾਂ JavaScript-ਮਿੱਤਰ ਹੋ ਗਏ, ਟੀਮਾਂ ਨੇ ਸਟੈਕ 'ਚ ਲਾਜਿਕ ਸਾਂਝਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ:
ਨਤੀਜਾ: ਨਕਲ ਕੀਤੀਆਂ ਨਿਯਮ ਘੱਟ ਹੋਈਆਂ, ਫੀਚਰ ਡਿਲਿਵਰੀ ਤੇਜ਼ ਹੋਈ, ਅਤੇ "ਇੱਕ ਉਤਪਾਦ ਕੋਡਬੇਸ" ਸੋਚ ਵਧੀ।
ਜਿਵੇਂ JavaScript "ਬ੍ਰਾਊਜ਼ਰ ਸਕ੍ਰਿਪਟ" ਤੋਂ ਦੌਰ-ਬਦਲਣ ਵਾਲੀ ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਐਪ ਵੱਲ ਵਧੀ, ਟੀਮਾਂ ਅਕਸਰ "JavaScript" ਨਾਲ ਉਹਨਾਂ ਸੰਦਾਂ ਦਾ ਪਰਿਵਾਰ ਮੰਨਣ ਲੱਗੀਆਂ: ਆਧੁਨਿਕ ECMAScript ਫੀਚਰ, ਬਿਲਡ ਪਾਈਪਲਾਈਨ, ਅਤੇ ਅਕਸਰ TypeScript।
TypeScript ਹਾਲੇ ਵੀ ਜਰੂਰੀ ਤੌਰ 'ਤੇ JavaScript ਹੈ—ਇਸਨੇ ਸਿਰਫ਼ ਟਾਈਪ ਸਿਸਟਮ ਅਤੇ ਇੱਕ ਕੰਪਾਇਲ ਸਟੇਪ ਜੋੜ ਦਿੱਤਾ। ਇਹ ਹੌਲੀ-ਹੌਲੀ ਅਪਣਾਉਣ ਯੋਗ ਹੈ: ਤੁਸੀਂ ਕੁਝ ਮੁਸ਼ਕਲ ਫਾਈਲਾਂ ਤੋਂ ਟਾਈਪਿੰਗ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ, ਬਾਕੀ .js ਰੱਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਇੱਕ bundled ਐਪ ਸ਼ਿਪ ਕਰਦੇ ਹੋ।
ਇਸ ਲਈ ਬਹੁਤ ਟੀਮਾਂ ਕਹਿ ਸਕਦੀਆਂ ਹਨ ਕਿ ਉਹ "JavaScript ਲਿਖਦੇ ਹਨ" ਭਾਵੇਂ ਕੋਡਬੇਸ ਜ਼ਿਆਦਾਤਰ .ts ਹੋਵੇ: ਰਨਟਾਈਮ JavaScript ਹੈ, ਇਕੋ ਇਕੋ ਇਕੋਸਿਸਟਮ JavaScript ਹੈ (npm ਪੈਕੇਜ, ਬ੍ਰਾਊਜ਼ਰ API, Node.js), ਅਤੇ TypeScript ਦਾ ਆਉਟਪੁੱਟ JavaScript ਹੈ।
ਜਦੋਂ ਕੋਡਬੇਸ ਵੱਡਾ ਹੁੰਦਾ, ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਹਿੱਸਾ ਨਵੇਂ ਫੀਚਰ ਲਿਖਣਾ ਨਹੀਂ—ਪੁਰਾਣੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਸੁਟਣਾ ਹੈ। ਟਾਈਪਸ ਹਲਕੀਆਂ ਠਹਿਰਾਂ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ:
ਮੁੱਖ ਫ਼ਾਇਦਾ ਭਰੋਸਾ ਹੈ: ਟੀਮਾਂ ਘੱਟ ਰਿਗਰੈਸ਼ਨ ਨਾਲ ਰੀਫੈਕਟਰ ਅਤੇ ਸ਼ਿਪ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਆਧੁਨਿਕ JavaScript ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਰਹੀ ਹੈ, ਪਰ ਹਰ ਬ੍ਰਾਊਜ਼ਰ ਜਾਂ ਵਾਤਾਵਰਣ فوری ਤੌਰ 'ਤੇ ਹਰ ਫੀਚਰ ਨੂੰ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ। Transpilation ਸਿਰਫ਼ ਇਹ ਹੈ:
ਇਸ ਨਾਲ ਟੀਮਾਂ ਨਵੇਂ ਸਿੰਟੈਕਸ ਦਾ ਉਪਯੋਗ ਕਰ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਹਰ ਡਿਵਾਈਸ ਦੇ ਅਣੁਕੂਲ ਹੋਣ ਦੀ ਉਡੀਕ ਕੀਤੇ।
ਕਾਫ਼ੀ ਕੁਝ ਆਧੁਨਿਕ ECMAScript ਫੀਚਰ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ JavaScript ਨੂੰ ਪੱਕਾ ਅਤੇ ਪਠਨਯੋਗ ਬਣਾਇਆ:
import/export) ਸਾਫ਼, ਰੀਯੂਜ਼ੇਬਲ ਕੋਡ ਲਈTypeScript ਅਤੇ ਆਧੁਨਿਕ ECMAScript ਇਕੱਠੇ ਮਿਲ ਕੇ JavaScript ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਸਕੇਲ ਕਰਨਯੋਗ ਬਣਾਉਂਦੇ ਹਨ: ਰੱਖਣਾ ਆਸਾਨ, ਨਵੇਂ ਆਉਣ ਵਾਲੇ ਲਈ onboard ਕਰਨਾ ਆਸਾਨ, ਅਤੇ ਬਦਲਾਅ ਕਰਨ ਵਿੱਚ ਘੱਟ ਜੋਖਿਮ।
JavaScript सिरਫ਼ ਇਸ ਲਈ ਕੰਪਨੀ-ਵਿਆਪੀ ਨਹੀਂ ਹੋਇਆ ਕਿ ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਸਰਵਰ 'ਤੇ ਚੱਲ ਸਕਦਾ—ਇਹ ਇਸ ਲਈ ਵੀ ਹੋਇਆ ਕਿ ਇਹ ਉਹ ਭਾਸ਼ਾ ਬਣੀ ਜਿਸ ਨਾਲ ਟੀਮਾਂ ਆਪਣਾ ਕੰਮ ਚਲਾਉਂਦੀਆਂ ਹਨ: ਬਣਾਉਣਾ, ਟੈਸਟ ਕਰਨਾ, ਰਿਲੀਜ਼ ਕਰਨਾ, ਅਤੇ ਰੋਜ਼ਾਨਾ ਕਾਰਜਾਂ ਨੂੰ ਆਟੋਮੇਟ ਕਰਨਾ। ਜਦੋਂ ਇਹ ਹੋਇਆ, JavaScript ਸਿਰਫ਼ ਐਪ ਭਾਸ਼ਾ ਨਹੀਂ ਰਹੀ ਅਤੇ ਇੱਕ ਅੰਦਰੂਨੀ ਓਪਰੇਸ਼ਨਲ ਲੇਅਰ ਬਣ ਗਈ।
ਜਿਵੇਂ ਫਰੰਟਐਂਡ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੋਇਆ, ਟੀਮਾਂ ਨੂੰ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਬਿਲਡ ਅਤੇ ਭਰੋਸੇਯੋਗ ਚੈੱਕਾਂ ਦੀ ਲੋੜ ਪਈ। JavaScript-ਆਧਾਰਿਤ ਟੂਲ ਇਹੀ ਮਾਹੌਲ ਦਿੰਦੇ ਕਿਉਂਕਿ ਉਹ ਇਕੋ ਰਿਪੋ ਵਿੱਚ ਰਹਿੰਦੇ ਅਤੇ ਇਕੋ ਪੈਕੇਜ ਇਕੋਸਿਸਟਮ ਵਰਤਦੇ।
ਆਮ ਸੇਟਅੱਪ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦਾ ਹੈ:
ਕਿਉਂਕਿ ਇਹ ਟੂਲ ਕਿਸੇ ਵੀ ਡਿਵੈਲਪਰ ਮਸ਼ੀਨ ਅਤੇ CI 'ਤੇ ਚੱਲ ਸਕਦੇ ਹਨ, ਉਹ "ਮੇਰੇ ਲੈਪਟਾਪ 'ਤੇ ਚੱਲਦਾ" ਸਮੱਸਿਆ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਹ "JavaScript ਹਰ ਜਗ੍ਹਾ" ਟੂਲਚੇਨ ਉਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਆਧੁਨਿਕ vibe-coding ਵਰਕਫਲੋਜ਼ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੀ: ਜਦ UI, ਬਿਲਡ, ਅਤੇ ਡੀਪਲੋਯਮੈਂਟ ਰੀਤੀਆਂ ਸਟੈਂਡਰਡ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਤੁਸੀਂ ਅਸਲ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਜਨਰੇਟ ਅਤੇ ਇੰਟਰਏਟ ਕਰ ਸਕਦੇ ਹੋ। ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਉਸ ਹਕੀਕਤ 'ਚ ਝੁਕਦੇ ਹਨ—ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਵਿੱਚ ਐਪ ਦਾ ਵੇਰਵਾ ਦੇ ਕੇ ਪ੍ਰੋਡਕਸ਼ਨ-ਗ੍ਰੇਡ ਪ੍ਰੋਜੈਕਟ (ਆਮ ਤੌਰ 'ਤੇ ਫਰੰਟਐਂਡ 'ਤੇ React) ਦੇਣਾ, ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ, ਡੀਪਲੋਯਮੈਂਟ/ਹੋਸਟਿੰਗ, ਕਸਟਮ ਡੋਮੇਨ, ਅਤੇ ਸਨੈਪਸ਼ਾਟ/ਰੋਲਬੈਕ ਦੀਆਂ ਵਿਵਸਥਾਵਾਂ ਨਾਲ।
ਵੱਧਦੀਆਂ ਕੰਪਨੀਆਂ ਅਕਸਰ ਮੋਨੋਰੈਪੋ ਵੱਲ ਵਧਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਕਈ ਐਪ ਇੱਕੋ ਨਿਰਭਰਤਾ, ਕੰਫਿਗ ਅਤੇ ਰੀਤੀਆਂ ਸਾਂਝੀਆਂ ਕਰ ਸਕਣ। ਇਸ ਨਾਲ ਸਾਂਝੇ ਕੰਪੋਨੈਂਟ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਅੰਦਰੂਨੀ SDK ਅਤੇ ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ ਨੂੰ ਰੱਖਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ—ਕੋਡ ਕਾਪੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਰਹਿੰਦੀ।
ਜਦੋਂ ਕਿਸੇ ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ ਬਟਨ ਨੂੰ accessibility ਫਿਕਸ ਮਿਲਦੀ ਹੈ, ਹਰ ਪ੍ਰੋਡਕਟ ਇੱਕ ਇੱਕਵਾਰ ਵਰਜ਼ਨ ਬੰਪ ਜਾਂ ਸਾਂਝਾ ਪੈਕੇਜ ਰਾਹੀਂ ਇਹ ਸੁਧਾਰ ਪਾ ਸਕਦਾ ਹੈ। JavaScript (ਅਤੇ ਵੱਧ ਤਰ TypeScript) ਇਸ ਸਾਂਝ ਨੂੰ ਵਿਵਹਾਰਿਕ ਬਣਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇੱਕੋ ਕੰਪੋਨੈਂਟ ਪ੍ਰੋਟੋਟਾਈਪ, ਪ੍ਰੋਡਕਸ਼ਨ UI ਅਤੇ ਡੋਕਯੂਮੈਂਟੇਸ਼ਨ ਦੋਹਾਂ ਚਲਾਉ ਸਕਦਾ ਹੈ।
ਜਦੋਂ linting, ਟੈਸਟ ਅਤੇ ਬਿਲਡ ਸਟੈਂਡਰਡ ਹੋ ਜਾਂਦੇ ਹਨ, ਉਹ CI/CD ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਕੁਆਲਿਟੀ ਗੇਟ ਬਣ ਜਾਂਦੇ: ਜੇ ਚੈੱਕ ਫੇਲ ਹੁੰਦੇ ਹਨ ਤਾਂ ਮਰਜ ਰੋਕ ਦਿੱਤਾ ਜਾਂਦਾ, ਰਿਲੀਜ਼ ਆਟੋਮੇਟ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਟੀਮ-ਟੂ-ਟੀਮ ਹੈਂਡਆਫ਼ਸ ਸਾਫ ਹੋ ਜਾਂਦੇ ਹਨ। ਨਤੀਜਾ ਹੈ ਘੱਟ ਨਸਲ-ਗਿਆਨ, ਘੱਟ ਇਕ-ਵਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਅਤੇ ਇੱਕ ਵਿਚਾਰ ਤੋਂ ਸ਼ਿਪ ਤੱਕ ਤੇਜ਼ ਰਾਹ।
JavaScript ਹੁਣ ਮੁਤਾਬਕ ਥਾਵਾਂ 'ਤੇ ਚੱਲਦਾ—ਕੁਬਰਨੇਟਿਸ 'ਚ ਕੰਟੇਨਰਾਂ ਵਿੱਚ, ਸਰਵਰਲੈਸ ਫੰਕਸ਼ਨਾਂ ਵਜੋਂ, ਅਤੇ ਉਦਯੋਗਕ ਤੌਰ 'ਤੇ(edge runtimes) 'ਤੇ। ਇਹ ਲਚਕੀਲਾਪਨ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ ਕਿ ਟੀਮਾਂ ਇਸ 'ਤੇ ਕਿਉਂ ਮਿਆਰੀਕਰਨ ਕਰਦੀਆਂ ਹਨ: ਇੱਕ ਭਾਸ਼ਾ, ਕਈ ਡੀਪਲੋਈਸ਼ਨ ਵਿਕਲਪ।
JavaScript I/O-ਭਾਰ ਕੰਮਾਂ ਲਈ ਬਹੁਤ ਚੰਗੀ ਹੈ (APIs, ਵੈੱਬ ਸਰਵਰ, ਇвੈਂਟ ਹੈਂਡਲਿੰਗ), ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ "ਭਾਰੀ ਕੰਪਿਊਟ" ਖੇਤਰ ਵਿੱਚ ਧੱਕਦੇ ਹੋ ਤਾਂ ਇਹ ਕੁਝ ਮੁਸ਼ਕਲਾਂ ਦਿਖਾ ਸਕਦਾ ਹੈ:
npm ਇਕ ਮਜ਼ਬੂਤੀ ਹੈ—ਅਤੇ ਇੱਕ ਸਪਲਾਈ-ਚੇਨ ਰਿਸਕ ਵੀ। ਪਰਪੱਕ ਟੀਮਾਂ ਡਿਪੈਂਡੇਨਸੀਜ਼ ਨੂੰ ਤੀਸਰੇ-ਪੱਖ ਵੇਂਡਰ ਵਾਂਗ ਹੀ ਜੀਵਨਤ ਦੇਖਦੀਆਂ ਹਨ: ਵਰਜ਼ਨ ਪਿਨ ਕਰੋ, audits ਆਟੋਮੇਟ ਕਰੋ, ਨਿਰਭਰਤਾ ਗਿਣਤੀ ਘਟਾਉ, ਅਤੇ ਨਵੀਆਂ ਪੈਕੇਜਾਂ ਲਈ ਰਿਵਿਊ ਗੇਟ ਲਗਾਓ। "ਤੇਜ਼ੀ ਨਾਲ ਜੋੜੋ" ਨੂੰ "ਸੁਰੱਖਿਅਤ ਚਲਾਉਣਾ" ਨਾਲ ਤਾਲਮੇਲ ਵਿੱਚ ਰੱਖੋ।
ਸਟਾਰਟਅੱਪਾਂ ਲਈ, JavaScript time-to-market ਘਟਾਉਂਦਾ ਹੈ: ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ 'ਤੇ ਵੰਡੇ ਹੁੰਦੇ ਕੌਸ਼ਲ, ਆਸਾਨ ਹਾਇਰਿੰਗ, ਅਤੇ ਸਰਵਰਲੈਸ ਤੋਂ ਕੰਟੇਨਰ ਤੱਕ ਸਿਧਾ ਡੀਪਲੋਇਮੈਂਟ। ਐਨਟਰਪ੍ਰਾਈਜ਼ ਲਈ, ਇਹ ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਪੇਸ਼ ਕਰਦਾ ਹੈ—ਪਰ ਗਵਰਨੈਂਸ ਦੀ ਸਪਸ਼ਟ ਲੋੜ ਵੀ ਹੈ (ਡਿਪੈਂਡੇਨਸੀ ਹਾਈਜੀਨ, ਬਿਲਡ ਪਾਈਪਲਾਈਨ, ਰਨਟਾਈਮ ਨੀਤੀਆਂ)।
ਅਮਲੀ ਪੈਟਰਨ ਜੋ ਵੱਧ ਰਿਹਾ ਹੈ: JavaScript/TypeScript ਨੂੰ ਉਤਪਾਦ ਲਾਜਿਕ ਅਤੇ ਯੂਜ਼ਰ ਅਨੁਭਵ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖਣਾ, ਜਦਕਿ ਪ੍ਰਦਰਸ਼ਨ ਜਾਂ ਗਵਰਨੈਂਸ-ਸੰਵੇਦਨਸ਼ੀਲ ਭਾਗਾਂ ਨੂੰ Go ਜਾਂ Rust ਵਰਗੀਆਂ ਭਾਸ਼ਾਵਾਂ 'ਚ ਸੇਵਾਵਾਂ ਵਜੋਂ ਰੱਖਣਾ। ਇਸ ਲਈ ਹਾਈਬ੍ਰਿਡ ਸਟੈਕ ਆਮ ਹੋ ਰਹੇ ਹਨ—ਉਦਾਹਰਨ ਲਈ, React ਫਰੰਟਐਂਡ ਨਾਲ Go ਅਤੇ PostgreSQL ਬੈਕਐਂਡ ਜੋ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸਾਦਾ ਓਪਰੇਸ਼ਨ ਦਿੰਦੇ ਹਨ।
WebAssembly ਵਧ-ਚੜ੍ਹ ਕੇ ਉਹ ਚੀਜ਼ਾਂ ਕਰਨਯੋਗ ਬਣਾਵੇਗਾ ਜੋ ਪਹਿਲਾਂ ਸਿਰਫ਼ ਨੇਟਿਵ ਕੋਡ ਨਾਲ ਸੰਭਵ ਸਨ, JavaScript ਦੇ ਨਾਲ ਨਾਲ server runtime ਵਿੱਚ ਵੀ। ਸੰਭਾਵੀ ਭਵਿੱਖ ਇਹ ਨਹੀਂ ਕਿ "JS ਸਭ ਕੁਝ ਬਦਲ ਦੇਵੇ"—ਬਲਕਿ JS ਗਲੂ ਬਣਿਆ ਰਹੇਗਾ: ਉਹ ਸੇਵਾਵਾਂ ਨੂੰ ਤਾਲਮੇਲ ਕਰੇਗਾ ਜਿੱਥੇ TypeScript/JS, Rust/Go/Python ਮਿਲ ਕੇ ਉਚਿਤ ਥਾਂ ਤੇ ਵਰਤੇ ਜਾਣ।
ਵਰਕਫਲੋ ਪੱਧਰ 'ਤੇ, ਅਗਲਾ ਕਦਮ ਅਕਸਰ ਨਵੇਂ ਸਿੰਟੈਕਸ ਫੀਚਰ ਤੋਂ ਘੱਟ ਅਤੇ ਛੋਟੀ ਫੀਡਬੈਕ ਲੂਪ ਬਾਰੇ ਹੁੰਦਾ ਹੈ: ਪਲਾਨਿੰਗ, ਜਨਰੇਸ਼ਨ, ਰਿਵਿਊ ਅਤੇ ਡੀਪਲੋਇੰਗ ਤੇਜ਼ੀ ਨਾਲ ਬਿਨਾਂ ਨਿਯੰਤਰਣ ਗੁਆਏ। ਇਹੀ ਉਹ ਨਿਸ਼ ਹੈ ਜਿੱਥੇ ਟੂਲਾਂ ਜਿਵੇਂ Koder.ai JavaScript-ਡੋਮਿਨੈਂਟ ਦੁਨੀਆ ਵਿੱਚ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਫਿੱਟ ਹੁੰਦੇ ਹਨ—ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਰਾਹੀਂ ਵਿਚਾਰ ਤੋਂ ਕਾਰਜਯੋਗ ਵੈੱਬ/ਸਰਵਰ/ਮੋਬਾਈਲ ਐਪ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ, ਫਿਰ ਜਦੋਂ ਸਕੇਲ ਅਤੇ ਸਖਤੀ ਲੋੜੀਂਦੀ ਹੋਵੇ, ਕੋਡ ਐਕਸਪੋਰਟ ਦਾ ਵਿਕਲਪ ਰੱਖਦੇ ਹੋਏ।
JavaScript ਉਹ ਭਾਸ਼ਾ ਹੈ ਜੋ ਤੁਸੀਂ ਲਿਖਦੇ ਹੋ ਅਤੇ ਜਿਸਨੂੰ ਇੰਜਨ ਚਲਾਉਂਦੇ ਹਨ। ECMAScript ਉਹ ਮਿਆਰ ਹੈ ਜੋ ਕੋਰ ਭਾਸ਼ਾ (ਸਿੰਟੈਕਸ, ਪ੍ਰਕਾਰ, ਆਬਜੈਕਟ, ਫੰਕਸ਼ਨ ਆਦਿ) ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ।
ਵਿਆਵਹਾਰਕ ਤੌਰ 'ਤੇ: ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ Node.js ECMAScript ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਹੋਰ API ਵੀ ਹੁੰਦੇ ਹਨ (ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ DOM, Node.js ਵਿੱਚ ਫਾਇਲ/నੈਟਵਰਕ API)।
ਕਿੱਲਾ ਇਹ ਹੈ ਕਿ ਵੈੱਬ ਨੂੰ ਪਿਛਲੇ ਪੰਨਿਆਂ ਦੇ ਕੰਮ ਕਰਦਿਆਂ ਰਹਿਣ ਦੀ ਲੋੜ ਹੈ। ਜੇ ਕਿਸੇ ਬ੍ਰਾਊਜ਼ਰ ਅਪਡੇਟ ਨਾਲ ਪੁਰਾਣੀਆਂ ਸਾਈਟਾਂ ਟੁੱਟ ਜਾਂਦੀਆਂ, ਤਾਂ ਵਰਤੋਂਕਾਰ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਨੀਂਦਾ ਕਰਦੇ।
ਇਸ ਲਈ ਨਵੇਂ ਫੀਚਰ ਆਮਤੌਰ ਤੇ ਜੋੜੇ ਜਾਂਦੇ ਹਨ (ਨਵਾਂ ਸਿੰਟੈਕਸ ਅਤੇ API) ਤੇ ਪੁਰਾਣੇ ਬਰਤਾਓ (ਜਿਵੇਂ var ਅਤੇ ਕੁਝ ਅਜੀਬ coercion ਨਿਯਮ) ਅਜੇ ਵੀ ਰਹਿੰਦੇ ਹਨ, ਭਲੇ ਹੀ ਮਾਡਰਨ ਕੋਡ ਉਹਨਾਂ ਤੋਂ ਬਚਦਾ ਹੋਵੇ।
Ajax ਇਕ ਪੰਨਾ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਸਰਵਰ ਤੋਂ ਡੇਟਾ ਮੰਗ ਸਕਦਾ ਹੈ ਅਤੇ सिरਫ਼ ਉਸ ਹਿੱਸੇ ਨੂੰ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ—ਪੂਰੇ ਪੰਨੇ ਨੂੰ ਰੀਲੋਡ ਕੀਤੇ ਬਿਨਾਂ।
ਵਿਆਵਹਾਰਕ ਪ੍ਰਭਾਵ:
jQuery ਇੱਕ ਸਟੇਬਲ, ਪੜ੍ਹਨਯੋਗ API ਦਿੰਦਾ ਸੀ ਜੋ DOM ਚੋਣ, ਇਵੈਂਟ ਅਤੇ ਇਫੈਕਟਾਂ ਵਿੱਚ ਬ੍ਰਾਊਜ਼ਰ-ਵਿਭਿੰਨਤਾ ਨੂੰ ਛੁਪਾ ਦਿੰਦਾ ਸੀ।
ਆਮ ਰਾਹ:
V8 (Chrome ਦਾ ਇੰਜਨ) ਨੇ JavaScript ਨੂੰ ਬਹੁਤ ਤੇਜ਼ ਬਣਾਇਆ—JIT ਕੰਪਾਇਲੇਸ਼ਨ ਅਤੇ ਹੌਟ ਕੋਡ ਪਾਥਾਂ ਦੀ ਰੀ-ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਦੇ ਜ਼ਰੀਏ।
ਟਿਮ-ਅਪ ਲਈ ਪ੍ਰਯੋਗਿਕ ਨਤੀਜਾ ਇਹ ਸੀ ਕਿ ਵੱਡੇ, ਧਨਾਢਯ UI ਹੁਣ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਬਿਨਾਂ ਪੇਜ਼ ਫ੍ਰੀਜ਼ ਹੋਏ ਚੱਲ ਸਕਦੇ ਸਨ—ਇਸ ਨਾਲ ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਗੰਭੀਰ ਐਪ ਰਨਟਾਈਮ ਬਣ ਗਿਆ।
Node.js JavaScript ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਬਾਹਰ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਇਵੈਂਟ ਲੂਪ ਵਰਤਦਾ ਹੈ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ I/O ਚੀਜ਼ਾਂ (ਨੈਟਵਰਕ, ਡਿਸਕ, ਡੇਟਾਬੇਸ) ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕਰਦਾ ਹੈ।
ਇਹ ਇਸ ਵੇਲੇ ਮਜ਼ਬੂਤ ਹੈ ਜਦੋਂ ਸੇਵਾ ਜ਼ਿਆਦਤਰ ਸਮਾਂ I/O 'ਤੇ ਉਡੀਕਦੀ ਹੈ:
npm ਨੇ JavaScript ਮਾਡਿਊਲਾਂ ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ ਆਸਾਨ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ ਵਿਕਾਸ ਤੇਜ਼ ਹੋਇਆ ਅਤੇ ਵਰਕਫਲੋ ਸਟੈਂਡਰਡ ਹੋਏ।
ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਣ ਲਈ:
package-lock.json ਜਾਂ ਸਮਾਨ) ਕਮੇਟ ਕਰੋ ਤਾਂ ਕਿ ਸਾਰੇ ਮਸ਼ੀਨਾਂ ਅਤੇ CI 'ਤੇ ਇੱਕੋ ਵਰਜ਼ਨ ਆਉਣSPA ਵਿੱਚ ਰਾਉਟਿੰਗ, ਰੇਂਡਰਿੰਗ ਅਤੇ UI ਰਾਜ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਹੋਂਦੇ ਹਨ ਅਤੇ ਡੇਟਾ API ਦੁਆਰਾ ਲਿਆਉਂਦੇ ਹਨ।
SSR (ਅਥਵਾ ਯੂਨੀਵਰਸਲ) ਸਰਵਰ ਤੇ ਪਹਿਲਾ ਨਜ਼ਾਰਾ ਰੈਂਡਰ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਇਨੀਸ਼ੀਅਲ ਲੋਡ ਤੇਜ਼ ਹੋਵੇ ਅਤੇ crawlability ਵਧੇ, ਫਿਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚhydrate ਕਰਕੇ ਇੰਟਰਐਕਟਿਵ ਬਣ ਜਾਂਦਾ ਹੈ।
ਆਮ ਨਿਯਮ:
TypeScript ਇੱਕ ਟਾਈਪ ਸਿਸਟਮ ਅਤੇ ਕੰਪਾਇਲ-ਸਟੇਪ ਜੋੜਦਾ ਹੈ ਪਰ ਰਨਟਾਈਮ ਤੇ JavaScript ਹੀ ਨਿਕਲਦਾ ਹੈ।
ਲੋਹ-ਫਾਇਦੇ:
ਇਸਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਫਾਈਲ-ਬਾਈ-ਫਾਈਲ ਅਪਣਾ ਸਕਦੇ ਹੋ—ਪੂਰਾ ਰੀਰਾਈਟ ਲਾਜ਼ਮੀ ਨਹੀਂ।
ਪੈਦਾ-ਉਤਪਾਦਨ ਵਿੱਚ JavaScript I/O-ਭਾਰ ਵਾਲੇ ਕੰਮਾਂ ਲਈ ਸ਼ਾਨਦਾਰ ਹੈ, ਪਰ ਲੰਮੇ ਸਮੇਂ ਲਈ CPU-ਭਾਰ ਵਾਲੇ ਕੰਮਾਂ ਵਿੱਚ ਇਹ ਹਮੇਸ਼ਾਂ ਸਭ ਤੋਂ ਵਧੀਆ ਨਹੀਂ ਰਹਿੰਦਾ—GC-ਰੁਕਾਵਟਾਂ, ਯਾਦ-ਉਪਭੋਗ ਅਤੇ ਲੰਮੇ-ਰੀਜ਼ ਕੈਂਪਿਊਟ ਕੰਮ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ।
ਅਮਲਯੋਗ ਰਾਹ: