Brendan Eich ਅਤੇ JavaScript: ਕਿਵੇਂ ਇੱਕ ਅਕਸਮਾਤ ਸਟੈਕ ਬਣ ਗਿਆ

ਕਿਉਂ JavaScript ਦੀ ਸ਼ੁਰੂਆਤੀ ਕਹਾਣੀ ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ

JavaScript ਕਿਸੇ ਵੱਡੇ ਯੋਜਨਾ ਨਾਲ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸ਼ੁਰੂ ਹੋਇਆ ਕਿ ਇਹ ਪੂਰੇ ਕੰਪਨੀਆਂ ਨੂੰ ਚਲਾਏ। ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਖਾਸ ਬ੍ਰਾਊਜ਼ਰ ਸਮੱਸਿਆ ਦਾ ਤੇਜ਼ ਹੱਲ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ—ਅਤੇ ਇਹ "ਅਕਸਮਾਤ" ਸ਼ੁਰੂਆਤ ਹੀ ਉਸਦੀ ਕਹਾਣੀ ਨੂੰ ਵਾਪਸ ਵੇਖਣ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।

ਇੱਕ ਛੋਟੀ ਸ਼ੁਰੂਆਤ ਪਰ ਵੱਡੇ ਨਤੀਜੇ

1995 ਵਿੱਚ, ਵੈੱਬ ਜ਼ਿਆਦਾਤਰ ਸਟੈਟਿਕ ਪੰਨਿਆਂ 'ਤੇ ਸੀ। Netscape ਚਾਹੁੰਦੀ ਸੀ ਕਿ ਕਿਸੇ ਹਲਕੇ-ਫੁਲਕੇ ਤਰੀਕੇ ਨਾਲ ਪੰਨਿਆਂ ਨੂੰ ਇੰਟਰਐਕਟਿਵ ਬਣਾਇਆ ਜਾਵੇ ਬਿਨਾਂ ਹਰ ਯੂਜ਼ਰ ਨੂੰ ਵੱਖਰੀ ਸਾਫਟਵੇਅਰ ਇੰਸਟਾਲ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤੇ। ਜੋ ਕੁਝ ਹੋਇਆ ਉਹ ਇੱਕ ਤੇਜ਼ ਤਰੀਕੇ ਨਾਲ ਬਣੀ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾ ਸੀ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਅੰਦਰ ਸ਼ਾਮਲ ਕੀਤੀ ਗਈ ਅਤੇ ਤੁਰੰਤ ਮਿਲੀਅਨਾਂ ਲੋਕਾਂ ਤੱਕ ਫੈਲ ਗਈ।

ਉਹ ਇੱਕ ਇਕੱਲੀ ਵੰਡ ਵਾਲਾ ਫੈਸਲਾ—"ਤੁਸੀਂ ਜਦੋਂ ਵੀ ਵੈੱਬ ਖੋਲ੍ਹਦੇ ਹੋ, ਇਹ ਉੱਥੇ ਹਜ਼ਰ ਹੋਵੇਗੀ"—ਇੱਕ ਛੋਟੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਗਲੋਬਲ ਡਿਫਾਲਟ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ।

"ਅਕਸਮਾਤ" ਦਾ ਮਤਲਬ "ਅਹਿਮ ਨਹੀਂ" ਨਹੀਂ ਹੁੰਦਾ

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

JavaScript ਦੀਆਂ ਸ਼ੁਰੂਆਤੀ ਪਾਬੰਦੀਆਂ ਨੇ ਇਸਦੀ ਸ਼ਖਸੀਅਤ ਰੂਪ ਵਿੱਚ ਨਿਰਧਾਰਿਤ ਕੀਤਾ: ਇਹ ਐੰਬੈੱਡ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ, ਨਵੇਂ ਸਿੱਖਣ ਵਾਲਿਆਂ ਲਈ ਬਖਸ਼ਣਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲਣਾ ਚਾਹੀਦਾ ਸੀ। ਇਹ ਗੁਣ ਨਾਨ-ਐਕਸਪਰਟ ਅਤੇ ਪ੍ਰੋਫੈਸ਼ਨਲ ਦੋਹਾਂ ਲਈ ਇਸਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦੇ ਹਨ—ਇਕ ਅਜਿਹਾ ਸੰਯੋਗ ਜਿਸ ਨੇ ਇਸਨੂੰ ਵੈੱਬ ਦੇ ਹਰ ਤਬਾਦਲੇ ਵਿੱਚ ਬਚਾਇਆ।

ਇੱਕ ਯਾਤਰਾ ਦਾ ਪ੍ਰੀਵਿਊ

ਇਹ ਪੋਸਟ ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਵਿਸ਼ੇਸ਼ਤਾ ਤੋਂ ਪੂਰੇ ਸਟੈਕ ਤੱਕ ਦੇ ਰਸਤੇ ਦਾ ਪਿਛੋਕੜ ਦਿਖਾਉਂਦੀ ਹੈ:

• ਬ੍ਰਾਊਜ਼ਰ: JavaScript ਵੈੱਬ ਪੰਨਿਆਂ 'ਤੇ ਇੰਟਰਐਕਟਿਵਟੀ ਜੋੜਨ ਦਾ ਡਿਫਾਲਟ ਤਰੀਕਾ ਬਣ ਗਿਆ।
• ਫਰੰਟਐਂਡ ਐਪਲੀਕੇਸ਼ਨ: ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰ ਅਤੇ ਫ੍ਰੇਮਵਰਕ ਨੇ ਇਸਨੂੰ "ਚਿਟਕੀਆਂ" ਤੋਂ ਪੂਰਨ ਐਪਸ ਮਿਲਿਆ।
• ਸਰਵਰ: Node.js ਨੇ ਸਾਬਤ ਕੀਤਾ ਕਿ JavaScript ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਬਾਹਰ ਵੀ ਚੱਲ ਸਕਦੀ ਹੈ।
• ਟੂਲਿੰਗ ਅਤੇ ਇਕੋਸਿਸਟਮ: npm ਅਤੇ ਆਧੁਨਿਕ ਬਿਲਡ ਟੂਲਾਂ ਨੇ ਕੋਡ ਸਾਂਝਾ ਕਰਨ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ।

ਇਹ ਕਿਸ ਲਈ ਹੈ

ਤੁਹਾਨੂੰ ਡਿਵੈਲਪਰ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਫੋਲੋ ਕਰ ਸਕੋ। ਜੇ ਤੁਸੀਂ ਕਦੇ ਸੋਚਿਆ ਕਿ ਇੰਨੀ ਸਾਰੀਆਂ ਪ੍ਰੋਡਕਟਾਂ, ਸਟਾਰਟਅਪਾਂ, ਅਤੇ ਨੌਕਰੀਆਂ ਕਿਸੇ ਤਰ੍ਹਾਂ JavaScript ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕਿਉਂ ਘੁੰਮਦੀਆਂ ਹਨ, ਤਾਂ ਇਹ ਦੋਸਤਾਨਾ ਬੈਕਸਟੋਰੀ ਹੈ—ਕਾਫੀ ਵੇਰਵਾ ਦੇ ਨਾਲ, ਬਿਨਾਂ ਤਕਨੀਕੀ ਪਿਛੋਕੜ ਮਨ ਕੇ।

Brendan Eich ਅਤੇ Netscape ਨੂੰ ਹੱਲ ਕਰਨਾ ਪਿਆ ਸਮੱਸਿਆ

1990 ਦੇ ਮੱਧ ਵਿੱਚ, ਵੈੱਬ ਅਕਾਦਮਿਕ ਰੁਚੀ ਤੋਂ ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਵਾਲੀ ਚੀਜ਼ ਵੱਲ ਵੱਧ ਰਿਹਾ ਸੀ। Netscape ਉਹਨਾਂ ਕੰਪਨੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ ਜੋ ਇਹ ਕਦਮ ਠੋਸ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਸੀ—Netscape Navigator ਨਾਲ, ਇੱਕ ਐਸਾ ਬ੍ਰਾਊਜ਼ਰ ਜੋ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਯੂਜ਼ਰਾਂ ਲਈ ਨਹੀਂ ਬਲਕਿ ਆਮ ਲੋਕਾਂ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਜਾ ਰਿਹਾ ਸੀ।

Brendan Eich ਨੇ Netscape ਵਿੱਚ ਉਸੇ ਸਮੇਂ ਜੁੜਿਆ ਜਦੋਂ ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਪੰਨਾ ਵੇਖਣ ਵਾਲੇ ਤੋਂ ਇੱਕ ਸਾਫਟਵੇਅਰ ਪਲੇਟਫਾਰਮ ਵੱਲ ਬਦਲ ਰਿਹਾ ਸੀ। ਕੰਪਨੀ ਦਾ ਲਕੜਾ ਸਿਰਫ਼ ਦਸਤਾਵੇਜ਼ ਰੇਂਡਰ ਕਰਨਾ ਨਹੀਂ ਸੀ—ਮਕਸਦ ਸੀ ਵੈਬਸਾਈਟਾਂ ਨੂੰ ਇੰਟਰਐਕਟਿਵ ਬਣਾਉਣਾ: ਫਾਰਮ ਸਬਮਿਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵੇਲਿਡੇਟ ਕਰਨਾ, ਕਲਿੱਕ ਦਾ ਤੁਰੰਤ ਪ੍ਰਤੀਕਿਰਿਆ, ਅਤੇ ਪੰਨੇ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਬਿਨਾਂ ਮੁੜ-ਲੋਡ ਕੀਤੇ ਅਪਡੇਟ ਕਰਨਾ (ਜਦੋਂ ਕਿ ਸ਼ੁਰੂਆਤੀ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਆਧੁਨਿਕ ਮਿਆਰ ਦੇ ਮੁਕਾਬਲੇ ਸਧਾਰਨ ਸੀ)।

ਕਿਉਂ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਅਚਾਨਕ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾ ਦੀ ਲੋੜ ਪਈ

HTML ਸਮੱਗਰੀ ਨੂੰ ਵਰਣਨ ਕਰ ਸਕਦਾ ਸੀ, ਅਤੇ CSS (ਅਜੇ ਪਹਿਲੀ ਪੜ੍ਹਾਈ ਵਿੱਚ) ਪ੍ਰਜ਼ੇਨਟੇਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਸੀ, ਪਰ ਦੋਹਾਂ "ਹਵਾਲੇ" ਨਹੀਂ ਦੇ ਸਕਦੇ। Netscape ਨੂੰ ਇੱਕ ਤਰੀਕੇ ਦੀ ਲੋੜ ਸੀ ਕਿ ਆਮ ਵੈੱਬ ਰਚਨਾਕਾਰ ਸੀਧਾ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਛੋਟੇ-ਛੋਟੇ ਲਾਜਿਕ ਦੇ ਟੁਕੜੇ ਜੋੜ ਸਕਣ।

ਉਸ ਮੰਗ ਨਾਲ ਤੇਜ਼-ਤੇਜ਼ ਸੀਮਾਵਾਂ ਜੁੜੀਆਂ:

• ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣਾ ਆਸਾਨ ਹੋਣਾ ਚਾਹੀਦਾ—ਸਿਸਟਮ ਭਾਸ਼ਾ ਤੋਂ ਜ਼ਿਆਦਾ ਇੱਕ "ਗਲੂ" ਭਾਸ਼ਾ ਵਾਂਗ।
• ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਸੁਰੱਖਿਆ ਨਾਲ ਚੱਲ ਸਕਣਾ ਚਾਹੀਦਾ ਤਾਂ ਜੋ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾ ਸਕੇ।
• ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿੱਪ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਮੁਕਾਬਲਾ ਤੇਜ਼ ਸੀ ਅਤੇ ਫੀਚਰ ਮਹੱਤਵਰ ਰੱਖਦੇ ਸਨ।

Netscape ਵਿੱਚ Eich ਦੀ ਭੂਮਿਕਾ

Eich ਨੂੰ ਇਹ ਨਹੀਂ ਕਿਹਾ ਗਿਆ ਸੀ ਕਿ "ਉਹ ਭਾਸ਼ਾ ਬਣਾਓ ਜੋ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ 'ਚ ਹਕੂਮਤ ਕਰੇਗੀ"। ਉਹ ਇੱਕ ਟੀਮ ਦਾ ਹਿੱਸਾ ਸੀ ਜਿਸ 'ਤੇ ਪ੍ਰੈਸ਼ਰ ਸੀ ਕਿ ਇੱਕ ਵਰਤੋਂਯੋਗ ਪ੍ਰੋਡਕਟ ਮਸਲਾ ਹੱਲ ਕੀਤਾ ਜਾਵੇ: Navigator ਨੂੰ ਇੱਕ ਸਧਾਰਣ ਸਕ੍ਰਿਪਟਿੰਗ ਸਮਰੱਥਾ ਦਿਓ ਜੋ ਵੈੱਬ ਪੰਨਿਆਂ ਵਿੱਚ ਐੰਬੈੱਡ ਹੋ ਸਕੇ ਅਤੇ ਯੂਜ਼ਰ ਦੀ ਮਸ਼ੀਨ 'ਤੇ ਚਲ ਸਕੇ।

ਉਸ ਤੰਗ, ਪ੍ਰੋਡਕਟ-ਚਲિત ਲੋੜ—ਇੰਟਰਐਕਟਿਵਟੀ, ਡਿਲਿਵਰੀ ਦੀ ਰਫ਼ਤਾਰ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਰਾਹੀਂ ਬਹੁਤ ਵਡੇ ਪੱਧਰ 'ਤੇ ਵੰਡ—ਉਹ ਸਥਿਤੀਆਂ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ JavaScript ਮਮਕਿਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਅਟੱਲ ਬਣਾਇਆ।

ਇੱਕ ਤੇਜ਼ ਬਿਲਡ: JavaScript ਕਿਵੇਂ ਰੂਪ ਲਿਆ

JavaScript ਦੀ "ਤੇਜ਼ੀ ਨਾਲ ਬਣੀ" ਸ਼ੁਰੂਆਤ ਦੀ ਕਹਾਣੀ ਹੈ, ਅਤੇ ਇਹ ਅਕਸਰ ਸੱਚ ਹੈ—ਪਰ ਇਹ ਕਈ ਵਾਰੀ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ alsof ਇੱਕ ਮਿਥ ਜਿਵੇਂ। ਹਕੀਕਤ ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਯੋਗਿਕ ਹੈ: Netscape ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਲਈ ਇੱਕ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾ ਦੀ ਲੋੜ ਸੀ, ਅਤੇ ਉਹਨੂੰ ਜ਼ਰੂਰਤ ਸੀ ਜਲਦੀ। Brendan Eich ਨੇ ਪਹਿਲਾ ਵਰਜਨ ਛੋਟੀ ਜਹੀ ਖਿੜਕੀ ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ, ਅਤੇ ਜਿਵੇਂ-ਜਿਵੇਂ ਬ੍ਰਾਊਜ਼ਰ ਸ਼ਿਪ ਹੋਇਆ ਅਤੇ ਵਿਕਸਿਤ ਹੋਇਆ, ਇਹ ਸੰਵਾਰੇ ਗਏ।

ਤੇਜ਼ੀ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ (ਅਤੇ ਇਸਦਾ ਕੀ ਅਰਥ ਸੀ)

ਸ਼ੁਰੂਆਤੀ ਲਕੜਾ ਸਰਬਸੰਪੂਰਨ ਭਾਸ਼ਾ ਬਣਾਉਣ ਦਾ ਨਹੀਂ ਸੀ। ਉਦੇਸ਼ ਸੀ ਕੁਝ ਐਸਾ ਜਿਹੜਾ ਲੋਕ ਵਾਸਤੇ ਵੈੱਬ ਪੰਨਿਆਂ ਦੇ اندر ਵਰਤ ਸਕਣ: ਫਾਰਮ ਚੈੱਕਸ, ਬਟਨ ਕਲਿੱਕ, ਸਧਾਰਨ ਐਨੀਮੇਸ਼ਨ, ਅਤੇ ਮੁੱਢਲੇ ਪੰਨਾ ਇੰਟਰਐਕਸ਼ਨਾਂ ਲਈ ਛੋਟੇ ਸਕ੍ਰਿਪਟ।

ਇਸਨੇ ਕੰਮ ਕਰਨ ਲਈ ਭਾਸ਼ਾ ਨੂੰ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ:

• ਪਹੁੰਚਯੋਗ: ਪਰਿਚਿਤ ਲੱਗਣ ਵਾਲੀ ਸਿੰਟੈਕਸ ਤਾਂ ਜੋ ਨਵੇਂ ਲੋਕ ਨਕਲ ਕਰਕੇ, ਥੋੜ੍ਹਾ ਸੋਧ ਕੇ, ਅਤੇ ਕਰਕੇ ਸਿੱਖ ਸਕਣ।
• ਹਲਕੀ-ਫੁਲਕੀ: ਲੰਮਾ ਲੋਡਿੰਗ ਅਤੇ ਉਹਨਾਂ ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਜਲਦੀ ਚੱਲਣ ਯੋਗ ਜਿਨ੍ਹਾਂ ਦੇ ਸਰੋਤ ਸੀਮਿਤ ਸਨ।
• ਲਚਕੀਲੀ: ਪੰਨੇ ਨਾਲ ਇੰਟਰੇਕਟ ਕਰਨ ਯੋਗ ਬਿਨਾਂ ਭਾਰੀ "ਇੰਜੀਨੀਅਰਿੰਗ" ਰਸਮੀਅਤ ਲਗਾਉਣ ਦੇ।

ਸ਼ੁਰੂਆਤੀ ਤਬਦੀਲੀਆਂ: ਸਮਾਂ, ਸਮਰੱਥਾ, ਸ਼ਿਪਿੰਗ

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

ਇਹ ਮਿਲਾਪ—ਟਾਈਟ ਸ਼ੈਡਿਊਲ ਅਤੇ ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਬ੍ਰਾਊਜ਼ਰ ਸੀਮਾਵਾਂ—JavaScript ਦੀ "ਤੇਜ਼ ਨਤੀਜਾ ਲਿਆਉ" ਸ਼ਖਸੀਅਤ ਨੂੰ ਰੂਪ ਦੇਣ ਵਿੱਚ ਮਦਦਗਾਰ ਰਹੀ: ਡਾਇਨੈਮਿਕ ਬਿਹੈਵਿਯਰ, ਢਿਲੀ ਟਾਈਪਿੰਗ, ਅਤੇ ਪ੍ਰਯੋਗਿਕਤਾ ਵੱਲ ਰੁਝਾਨ।

JavaScript vs. Java: ਨਾਂ ਵਿੱਚ ਸਮਾਨਤਾ, ਕੰਮ ਵਿੱਚ ਫਰਕ

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

ਸਿੱਧੇ ਸ਼ਬਦਾਂ ਵਿੱਚ:

• Java ਵਧੇਰੇ ਭਾਰਭਰੂ, ਕੰਪਾਇਲ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਭਾਸ਼ਾ ਦੇ ਰੂਪ ਵਿੱਚ ਦਰਸਾਈ ਗਈ ਸੀ ਜੋ ਵੱਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਸੀ।
• JavaScript ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਅੰਦਰ ਸਕ੍ਰਿਪਟਿੰਗ ਲਈ ਨਿਸ਼ਾਨਦਿਹ ਸੀ—ਛੋਟੇ ਕੋਡ ਪੀਸ ਜੋ ਵੈੱਬ ਪੰਨਿਆਂ ਨੂੰ ਇੰਟਰਐਕਟਿਵ ਬਣਾਉਂਦੇ।

ਇਸ ਮਕਸਦ ਦਾ ਫਰਕ ਕਿਸੇ ਵੀ ਸਤਹ-ਸਾਮਿਲ ਸਮਾਨਤਾ ਤੋਂ ਕਈ ਗੁਣਾ ਜ਼ਿਆਦਾ ਅਹਿਮ ਸੀ।

ਬ੍ਰਾਊਜ਼ਰ ਫਾਇਦਾ: ਬਿਲਟ-ਇਨ ਵੰਡ

JavaScript ਨੂੰ ਸਭ ਤੋਂ ਵੱਡੀ ਅਗਵਾਈ ਨਾ ਤਾਂ ਕੰਮਪਲੈਕਸ ਸਿੰਟੈਕਸ ਜਾਂ ਪਰਫੈਕਟ ਡਿਜ਼ਾਇਨ ਬਲਕਿ ਇਸ ਦੀ ਥਾਂ ਮਿਲੀ: ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਅੰਦਰ ਵੱਸਦੀ ਸੀ।

"ਬ੍ਰਾਊਜ਼ਰ ਰਨਟਾਈਮ" ਦਾ ਮਤਲਬ (ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ)

ਇੱਕ ਰਨਟਾਈਮ ਸਿਰਫ ਉਹ ਮਾਹੌਲ ਹੈ ਜੋ ਕੋਡ ਨੂੰ ਚਲਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਰਨਟਾਈਮ Chrome, Firefox, Safari ਅਤੇ ਹੋਰਾਂ ਦੇ ਉਹ ਹਿੱਸੇ ਨੂੰ ਕਹਿੰਦੇ ਹਨ ਜੋ JavaScript ਨੂੰ ਤੁਰੰਤ ਹੀ ਪੇਜ਼ ਲੋਡ ਹੁੰਦਿਆਂ ਚਲਾ ਸਕਦੇ ਹਨ।

ਇਸਦਾ ਮਤਲਬ ਸੀ ਕਿ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਯੂਜ਼ਰਾਂ ਤੋਂ ਕੁਝ ਵੱਖਰਾ ਇੰਸਟਾਲ ਕਰਨ ਦੀ ਬੇਨਤੀ ਨਹੀਂ ਕਰਨੀ ਪਈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਬ੍ਰਾਊਜ਼ਰ ਸੀ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ JavaScript ਸੀ।

DOM: ਪੰਨਾ ਬਿਨਾਂ ਰੀਲੋਡ ਕੀਤੇ ਬਦਲਣਾ

ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਵੈੱਬ ਪੰਨੇ ਨੂੰ ਇੱਕ ਢਾਂਚਾਬੱਧ ਚੀਜ਼ ਦੇ ਰੂਪ ਵਿੱਚ ਦਰਸਾਉਂਦੇ ਹਨ ਜਿਸਨੂੰ DOM (Document Object Model) ਕਹਿੰਦੇ ਹਨ। ਇਸਨੂੰ ਇੱਕ ਜ਼ਿੰਦਾ, ਸੋਧ ਯੋਗ ਨਕਸ਼ੇ ਵਾਂਗ ਸੋਚੋ: ਹੈਡਿੰਗ, ਬਟਨ, ਇਮੀਜ ਅਤੇ ਟੈਕਸਟ ਸਾਰੇ ਟਰੀ ਦੇ ਨੋਡ ਹਨ।

JavaScript ਇਹ ਕਰ ਸਕਦੀ ਹੈ:

• ਪੰਨੇ 'ਤੇ ਜੋ ਹੈ ਉਹ ਪੜ੍ਹਣਾ (ਉਦਾਹਰਣ ਲਈ ਫਾਰਮ ਫੀਲਡ ਦੀ ਵੈਲਿਊ)
• ਇਸਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਬਦਲਣਾ (ਉਦਾਹਰਣ ਲਈ ਟੈਕਸਟ ਤਬਦੀਲ ਕਰਨਾ, ਕਿਸੇ ਹਿੱਸੇ ਨੂੰ ਛੁਪਾਉਣਾ, ਨਵਾਂ ਆਈਟਮ ਜੋੜਨਾ)

ਅਹਿਮ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਸਾਰੇ ਕੰਮ ਪੂਰੇ ਪੰਨੇ ਨੂੰ ਰੀਫ੍ਰੇਸ਼ ਕੀਤੇ ਬਿਨਾਂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਇਹ ਇੱਕਲੌਤਾ ਸਮਰੱਥਾ ਵੈੱਬਸਾਈਟਾਂ ਨੂੰ ਸਟੈਟਿਕ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਇੰਟਰਐਕਟਿਵ ਇੰਟਰਫੇਸ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ।

ਸ਼ੁਰੂਆਤੀ ਵਰਤੇ ਗਏ ਕੇਸ ਜਿਨ੍ਹਾਂ ਨੇ ਧਿਆਨ ਖਿੱਚਿਆ

ਪਹਿਲੀਆਂ "ਵਾਹ" ਮੁਹੱਤਾਂ ਅਮਲਿਕ ਅਤੇ ਛੋਟੀਆਂ ਸਨ:

• ਫਾਰਮ ਵੇਲਿਡੇਸ਼ਨ: ਡੇਟਾ ਸਰਵਰ ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਖ਼ਾਲੀ ਫੀਲਡ ਜਾਂ ਗਲਤ ਇਮੇਲ ਫੜ ਲੈਣਾ
• ਸਧਾਰਨ ਇੰਟਰੈਕਸ਼ਨ: ਡ੍ਰੌਪਡਾਊਨ, ਟੈਬ, ਵੇਰਵਾ ਦਿਖਾਉ/ਲੁਕਾਉ, ਟੂਲਟਿਪ
• ਆਪ-ਲਾਈਟ ਐਨੀਮੇਸ਼ਨ: ਇਮੇਜ ਰੋਲਓਵਰ, ਮੂਵ ਕਰਦੇ ਐਲਿਮੈਂਟ, ਪ੍ਰੋਗਰੈਸ ਇੰਡੀਕੇਟਰ

ਇਹ ਵੱਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨ ਨਹੀਂ ਸਨ—ਪਰ ਇਹ ਘਰਾਭਰ ਘੱਟੀਅਨ ਘਟਨਾਵਾਂ ਘਟਾਈਆਂ ਅਤੇ ਪੰਨਿਆਂ ਨੂੰ ਜ਼ਿਆਦਾ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾਇਆ।

ਬਿਲਟ-ਇਨ ਵੰਡ ਨੇ ਸਭ ਕੁਝ ਕਿਉਂ ਬਦਲ ਦਿੱਤਾ

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

"ਹਰ ਜਥੇ ਉੱਥੇ ਪਹਿਲਾਂ ਹੀ ਇੰਸਟਾਲ" ਹੋਣਾ ਇੱਕ ਵਿਲੱਖਣ ਫਾਇਦਾ ਹੈ—ਅਤੇ JavaScript ਨੂੰ ਇਹ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਪ੍ਰਾਪਤ ਹੋਇਆ।

JavaScript ਤੋਂ ECMAScript: ਭਾਸ਼ਾ ਦੀ ਮਿਆਰਬੱਦੀ

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

ਜਦੋਂ ਇੱਕੋ ਪੰਨਾ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਵਰਤਦਾ ਸੀ

ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ, ਅਕਸਰ ਇੱਕ ਸਕ੍ਰਿਪਟ ਇੱਕ ब੍ਰਾਊਜ਼ਰ 'ਚ ਕੰਮ ਕਰਦੀ ਸੀ ਅਤੇ ਦੂਜੇ 'ਚ ਟੁੱਟ ਜਾਂ ਅਜੀਬ ਤਰੀਕੇ ਨਾਲ ਵਰਤਦੀ। ਯੂਜ਼ਰ ਇਹ ਤਜਰਬਾ ਅਕਸਰ ਇਸ ਤਰ੍ਹਾਂ ਵੇਖਦੇ:

• ਘਰ 'ਚ ਕੰਮ ਕਰਨ ਵਾਲਾ ਬਟਨ ਦਫਤਰ 'ਚ ਕੰਮ ਨਹੀਂ ਕਰਦਾ
• ਫਾਰਮ ਵੇਲਿਡੇਸ਼ਨ ਅਟਕ ਜਾਂ ਗਲਤ ਹੋ ਜਾਂਦੀ
• ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ 'ਚ ਪੰਨਾ ਠੀਕ ਦਿਖਦਾ ਹੈ ਪਰ ਦੂਜੇ 'ਚ ਸਕ੍ਰਿਪਟ ਦੇ ਕਾਰਨ ਗਲਟ ਹੋ ਜਾਂਦਾ

ਡਿਵੈਲਪਰਾਂ ਲਈ ਇਹ ਮਤਲਬ ਸੀ ਬ੍ਰਾਊਜ਼ਰ-ਵਿਸ਼ੇਸ਼ ਕੋਡ ਲਿਖਣਾ, ਲਗਾਤਾਰ ਪੈਚਜ਼ ਜਾਰੀ ਕਰਨਾ, ਅਤੇ ਇੰਨੇ ਹੀ ਆਮ ਬ੍ਰਾਊਜ਼ਰਾਂ ਲਈ ਇੱਕੋ ਫੀਚਰ ਨੂੰ ਕਈ ਵਾਰੀ ਟੈਸਟ ਕਰਨਾ।

ECMAScript: ਮਿਆਰ ਦਾ "ਅਸਲੀ" ਨਾਮ

ਇਸ ਉਥਲ-ਪੁਥਲ ਨੂੰ ਘਟਾਉਣ ਲਈ, JavaScript ਨੂੰ Ecma International ਰਾਹੀਂ ਮਿਆਰਬੱਦ ਕੀਤਾ ਗਿਆ। ਮਿਆਰਤ ਭਾਸ਼ਾ ਵਿਸ਼ੇਸ਼ਣ ਦਾ ਨਾਮ ECMAScript ਰੱਖਿਆ ਗਿਆ (ਅਕਸਰ ES ਕਿਹਾ ਜਾਂਦਾ ਹੈ)। "JavaScript" ਲੋਕਾਂ ਲਈ ਬ੍ਰਾਂਡ ਹੀ ਰਿਹਾ, ਪਰ ECMAScript ਉਹ ਸਾਂਝਾ ਨਿਯਮ-ਕਿਤਾਬ ਬਣ ਗਿਆ ਜਿਸਨੂੰ ਬ੍ਰਾਉਜ਼ਰ ਬਣਾਉਣ ਵਾਲੇ ਲਾਗੂ ਕਰ ਸਕਦੇ ਸਨ।

ਉਹ ਨਿਯਮ-ਕਿਤਾਬ ਅਹਿਮ ਸੀ ਕਿਉਂਕਿ ਇਸਨੇ ਇੱਕ ਬੇਸਲਾਈਨ ਬਣਾਈ: ਜਦੋਂ ਕੋਈ ਫੀਚਰ ECMAScript ਮਿਆਰ ਦਾ ਹਿੱਸਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਵਿਕਾਸਕਾਰ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਉਹ ਹਰ ਇੱਕ ਕੰਪਲਾਇੰਟ ਇੰਜਨ 'ਤੇ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਵਰਤੇਗਾ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਵੈਂਡਰ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਟੂਲਿੰਗ 'ਤੇ ਮੁਕਾਬਲਾ ਕਰ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਅਸਮਝੇ ਸਿੰਟੈਕਸ 'ਤੇ।

ਇਸ ਨਾਲ ਲੰਬੇ ਸਮੇਂ ਦੀ ਵਿਰਧੀ ਕਿਉਂ ਹੋਈ

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

ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, JavaScript ਨੇ "ਪੰਨਿਆਂ 'ਤੇ ਛਿੜਕੀਆਂ" ਤੋਂ ਭਾਸ਼ਾ ਬਣ ਕੇ ਪੈਦਾ ਹੋਇਆ ਜਿਸ 'ਤੇ ਟੀਮਾਂ ਆਪਣੀਆਂ ਉਤਪਾਦਾਂ—ਅਤੇ ਕਰੀਅਰ—ਦੋਸ਼ ਨਹੀਂ ਰੱਖ ਸਕਦੀਆਂ।

ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਛਾਲਾਂ ਜੋ ਪੰਨਿਆਂ ਨੂੰ ਐਪ ਬਣਾਂਦੀਆਂ

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

ਤੇਜ਼ ਇੰਜਨਾਂ ਨੇ ਛਤ ਬਦਲੀ

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

ਉਹ ਤੇਜ਼ੀ ਕੇਵਲ ਮੌਜੂਦਾ ਪੰਨਿਆਂ ਨੂੰ ਤੇਜ਼ ਨਹੀਂ ਕਰਦੀ; ਇਹ ਉਹ ਫੀਚਰਾਂ ਦੀ ਸੰਖਿਆ ਅਤੇ ਜਟਿਲਤਾ ਵਧਾਉਂਦੀ ਜੋ ਟੀਮਾਂ ਆਸਾਨੀ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਐਨੀਮੇਸ਼ਨ ਸਲਿਕ ਹੋ ਗਈਆਂ, ਵੱਡੀਆਂ ਸੂਚੀਆਂ ਪਲਟਣ scherpe ਹੋ ਗਈਆਂ, ਅਤੇ ਹੋਰ ਲਾਜਿਕ ਲੋਕਲ ਤੌਰ 'ਤੇ ਚੱਲ ਸਕਣ ਲੱਗੀ—ਸੰਪਰਕ ਕਰਕੇ ਬਾਰ-ਬਾਰ ਸਰਵਰ ਨੂੰ ਨਾ ਪੁੱਛਣ ਦੀ ਲੋੜ ਘੱਟ ਹੋਈ।

Ajax ਨੇ ਉਮੀਦਾਂ ਵਧਾਈਆਂ

ਉਸੇ ਸਮੇਂ, "Ajax" ਨੇ ਇੱਕ ਨਵਾਂ ਪੈਟਰਨ ਲੋਕਪ੍ਰিয় ਕੀਤਾ: ਇੱਕ ਵਾਰੀ ਪੰਨਾ ਲੋਡ ਕਰੋ, ਫਿਰ ਪਿਛਲਾ-ਥੱਲੇ ਡਾਟਾ ਲੈ ਕੇ ਇੰਟਰਫੇਸ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਅਪਡੇਟ ਕਰੋ ਬਿਨਾਂ ਸਾਰੇ ਪੰਨੇ ਨੂੰ ਰੀਲੋਡ ਕੀਤੇ। ਯੂਜ਼ਰ ਤੁਰੰਤ ਉਮੀਦ ਕਰਨ ਲੱਗੇ ਕਿ ਵੈੱਬਸਾਈਟਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਵਾਂਗ ਨਹੀਂ ਬਲਕਿ ਸਾਫਟਵੇਅਰ ਵਾਂਗ ਵਰਤਣਗੀਆਂ।

ਇਹ ਉਹ ਸਮਾਂ ਸੀ ਜਦ "ਕਲਿੱਕ → ਉਡੀਕ → ਨਵਾਂ ਪੰਨਾ" ਪੁਰਾਣਾ ਮਹਿਸੂਸ ਹੋਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ।

ਨਵਾਂ ਪ੍ਰਦਰਸ਼ਨ, ਨਵੇਂ ਕਿਸਮ ਦੇ ਉਤਪਾਦ

ਜਿਵੇਂ ਜਿਵੇਂ JavaScript ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਤੇਜ਼ ਹੋਈ, ਆਮ ਵੈੱਬ ਤਜਰਬੇ ਇੱਕ ਸੀਮਾ ਪਾਰ ਕਰਨ ਲੱਗੇ:

• ਮੈਪਸ ਹੌਲੇ-ਹੌਲੇ ਪੈਨ ਅਤੇ ਜ਼ੂਮ ਕਰ ਸਕਦੇ ਸਨ ਜਦੋਂ ਕਿ ਟਾਈਲ ਅਤੇ ਮਾਰਕਰ ਪਿਛੋਕੱਲੇ ਨੂੰ ਲੋਡ ਕਰ ਰਹੇ ਹੋਣ।
• ਈਮੇਲ ਇਨਬੌਕਸ ਲਿਸਟ ਨੂੰ ਤੁਰੰਤ ਅਪਡੇਟ ਕਰ ਸਕਦੀ, ਡਰਾਫਟਾਂ ਨੂੰ ਆਟੋ-ਸੇਵ ਕਰ ਸਕਦੀ, ਅਤੇ ਇੰਟਰਫੇਸ ਨੂੰ ਰਿਸਪੌਂਸਿਵ ਰੱਖ ਸਕਦੀ।
• ਡੈਸ਼ਬੋਰਡ ਚਾਰਟਸ ਨੂੰ ਦੁਬਾਰਾ ਡਰੋਅ, ਟੇਬਲਾਂ ਨੂੰ ਸਾਰਟ, ਅਤੇ ਫਿਲਟਰ ਲਗਾ ਸਕਦੇ ਜਦੋਂ ਤੁਸੀਂ ਇੰਟਰਐਕਟ ਕਰੋ—ਹਰ ਵਾਰੀ ਤੁਹਾਨੂੰ ਨਵੀਂ URL 'ਤੇ ਨਹੀਂ ਭੇਜਦੇ।

ਜਦ ਬ੍ਰਾਊਜ਼ਰ ਇਹ ਇੰਟਰਐਕਟਿਵ ਵਰਕਲੋਡ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲ ਸਕਣ ਲੱਗਿਆ, ਵੈੱਬ 'ਤੇ ਪੂਰੇ ਐਪ ਬਣਾਉਣਾ ਇੱਕ ਨਵਾਂਚੀਜ਼ ਰਹਿਣਾ ਬੰਦ ਹੋ ਗਿਆ ਅਤੇ ਇੱਕ ਡਿਫ਼ਾਲਟ ਤਰੀਕਾ ਬਣ ਗਿਆ।

ਫ੍ਰੇਮਵਰਕ ਅਤੇ ਆਧੁਨਿਕ ਫਰੰਟਐਂਡ ਦਾ ਉਠਾਨ

ਜਿਵੇਂ-ਜਿਵੇਂ ਵੈੱਬਸਾਈਟਾਂ "ਕੁਝ ਪੰਨੇ ਅਤੇ ਇੱਕ ਫਾਰਮ" ਤੋਂ ਇੰਟਰਐਕਟਿਵ ਉਤਪਾਦ ਬਣਨ ਲੱਗੀਆਂ, ਹਰ ਚੀਜ਼ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ DOM ਕੋਡ ਨਾਲ ਲਿੱਖਣਾ ਫਰਨੀਚਰ ਅਸੈmbler ਕਰਨ ਵਰਗਾ ਲੱਗਣ ਲੱਗਾ। JavaScript ਕੰਮ ਕਰ ਸਕਦੀ ਸੀ, ਪਰ ਟੀਮਾਂ ਨੂੰ UI ਦੀ ਜਟਿਲਤਾ ਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਸੰਗਠਿਤ ਕਰਨ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਢਾਂਚੇ ਦੀ ਜ਼ਰੂਰਤ ਸੀ।

ਵੱਡਾ ਬਦਲਾਅ: UI ਨੂੰ ਕੰਪੋਨੈਂਟਾਂ ਵਜੋਂ ਦੇਖਣਾ

ਆਧੁਨਿਕ ਫਰੰਟਐਂਡ ਫ੍ਰੇਮਵਰਕਸ ਇੱਕ ਸਧਾਰਣ ਮਾਨਸਿਕ ਮਾਡਲ ਪ੍ਰਸਿੱਧ ਕੀਤਾ: ਇੰਟਰਫੇਸ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਕੰਪੋਨੈਂਟਾਂ ਵਿੱਚ ਬਣਾਓ। DOM 'ਤੇ ਘੁਲਾਏ ਹੋਏ ਇਵੈਂਟ ਹੈਂਡਲਰ ਅਤੇ ਅਪਡੇਟਾਂ ਹੋਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਉਹ UI ਦੇ ਹਿੱਸੇ ਵੱਖਰੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹੋ ਜੋ ਆਪਣੀ ਰਚਨਾ ਅਤੇ ਵਿਹਾਰ ਨੂੰ ਮੈਨੇਜ ਕਰਦੇ ਹਨ, ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਵਾਂਗ ਜੋੜਦੇ ਹੋ।

ਇਹ "UI ਨੂੰ ਕੰਪੋਨੈਂਟ ਵਜੋਂ ਲਿਖੋ" ਦੀ ਸੋਚ ਨੇ ਆਸਾਨ ਬਣਾਇਆ:

• ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਇੱਕੋ UI ਨਮੂਨੇ ਨੂੰ ਦੁਹਰਾਉਣਾ
• ਸਟੇਟ (ਜੋ ਯੂਜ਼ਰ ਵੇਖਦਾ ਹੈ) ਨੂੰ ਲਾਜਿਕ ਨਾਲ ਜੋੜ ਕੇ ਰੱਖਣਾ
• ਟੀਮ ਵਿੱਚ ਕੰਮ ਵੰਡਣਾ ਬਿਨਾਂ ਇੱਕ-ਦੂਜੇ ਦੇ ਕੰਮ 'ਤੇ ਚੱਲਣ

ਉਦਾਹਰਣ ਬਿਨਾਂ ਕਿਸੇ ਵਰਕ-ਨੂੰ ਚੁਣਨ ਦੇ

ਵੱਖ-ਵੱਖ ਫ੍ਰੇਮਵਰਕ ਵੱਖਰੇ ਰਾਹ ਲਏ ਪਰ ਸਾਰੇ ਫਰੰਟਐਂਡ ਨੂੰ ਐਪ-ਸ਼ੈਲੀ ਆਰਕੀਟੈਕਚਰ ਵੱਲ ਧਕਿਆ। ਆਮ ਉਦਾਹਰਣਾਂ ਵਿੱਚ React, Angular, Vue, ਅਤੇ Svelte ਸ਼ਾਮਲ ਹਨ। ਹਰ ਇੱਕ ਦੀਆਂ ਆਪਣੀਆਂ ਰਵਾਇਤਾਂ ਹਨ ਕੰਪੋਨੈਂਟ, ਡੇਟਾ ਫ਼ਲੋ, ਰਾਊਟਿੰਗ, ਅਤੇ ਟੂਲਿੰਗ ਲਈ।

ਫ੍ਰੇਮਵਰਕ ਸਿੱਖਣ, ਨੌਕਰੀ ਭਰਨ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤੋਂ ਨੂੰ ਤੇਜ਼ ਕਿਉਂ ਕਰਦੇ

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

ਇਹ ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਇਸ ਕਰਕੇ ਵੀ ਹੈ ਕਿ ਆਧੁਨਿਕ "vibe-coding" ਟੂਲ ਆਮ ਤੌਰ 'ਤੇ ਲੋਕਪ੍ਰਿਯ ਫ੍ਰੇਮਵਰਕਸ ਨਾਲ ਨਾਲ ਹੋਂਦ ਵਿਚ ਹਨ। ਉਦਾਹਰਣ ਵਜੋਂ, Koder.ai React ਫਰੰਟਐਂਡਾਂ ਨੂੰ ਇੱਕ ਚੈਟ-ਆਧਾਰਿਤ ਵਰਕਫਲੋ ਤੋਂ ਉਤਪਾਦਨ-ਉਦੇਸ਼ੀ ਤਰੀਕੇ ਨਾਲ ਜਨਰੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਟੀਮਾਂ ਇੱਕ ਵਿਚਾਰ ਤੋਂ ਕੰਮ ਕਰਦੀ UI ਤੱਕ ਤੇਜ਼ੀ ਨਾਲ ਜਾ ਸਕਣ ਜਦਕਿ ਮੁਲ-ਸੋর্স ਕੋਡ ਨੂੰ ਨਿਰਿਆਤ ਅਤੇ ਮਾਲਕਾਨਾ ਰੱਖਣ ਦਾ ਵਿਕਲਪ ਵੀ ਬਣਿਆ ਰਹੇ।

ਤਬਦੀਲੀ: ਚਰਨ ਅਤੇ ਜਟਿਲਤਾ

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

Node.js: JavaScript ਬੈਕਐਂਡ 'ਤੇ ਵੀ ਚੱਲਣ ਲੱਗਾ

Node.js JavaScript ਹੈ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਬਾਹਰ ਚਲਦੀ ਹੈ।

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

ਇਹ ਕਿਉਂ ਆਕਰਸ਼ਕ ਸੀ

ਵੱਡੀ ਖਿੱਚ ਜਾਦੂਈ ਰਫ਼ਤਾਰ ਨਹੀਂ ਸੀ; ਇਹ ਇੱਕਸਰਤਾ ਸੀ। ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ 'ਤੇ JavaScript ਵਰਤਣ ਦਾ ਮਤਲਬ ਸਾਂਝੇ ਸੰਕਲਪ, ਸਾਂਝੇ ਵੈਲੀਡੇਸ਼ਨ ਨਿਯਮ, ਸਾਂਝੇ ਡਾਟਾ ਸ਼ੇਪ, ਅਤੇ (ਅਕਸਰ) ਸਾਂਝੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ। ਵਧਦੀ ਕੰਪਨੀਆਂ ਲਈ, ਇਹ ਹੇਂਡਆਫ਼ ਘਟਾਉਂਦਾ ਅਤੇ ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਟਾਸਕਾਂ ਵਿਚਕਾਰ ਆਸਾਨੀ ਨਾਲ mouv ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ।

Node.js ਨੇ ਕੀ ਪ੍ਰਭਾਵੀ ਬਣਾਇਆ

Node.js JavaScript ਨੂੰ ਆਮ ਬੈਕਐਂਡ ਵਰਕਲੋਡ ਸੰਭਾਲਣ ਦੇ ਯੋਗ ਬਣਾਇਆ, ਜਿਵੇਂ:

• APIs (REST ਜਾਂ GraphQL) ਬਣਾਉਣਾ ਜੋ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਐਪਸ ਨੂੰ ਸਰਵ ਕਰਦੇ ਹਨ
• ਰੀਅਲ-ਟਾਈਮ ਫੀਚਰ ਜਿਵੇਂ ਚੈਟ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਲਾਈਵ ਡੈਸ਼ਬੋਰਡ, ਅਤੇ ਸਹਿਯੋਗ
• "ਡਿਵੈਲਪਰ ਟੂਲਿੰਗ" ਜਿਵੇਂ ਬਿਲਡ ਸਕ੍ਰਿਪਟ, ਲਿੰਟਰ, ਬੰਡਲਰ, ਅਤੇ CLIਜ਼—ਜਿਹੜੇ ਆਧੁਨਿਕ ਫਰੰਟਐਂਡ ਵਰਕਫਲੋਜ਼ ਚਲਾਉਂਦੇ ਹਨ

Node ਦੇ ਸ਼ੁਰੂਆਤੀ ਸਫਲਤਾ ਦਾ ਇੱਕ ਹਿੱਸਾ ਇਹ ਵੀ ਸੀ ਕਿ ਇਹ ਇਵੈਂਟ-ਡ੍ਰਿਵਨ ਕੰਮ ਲਈ ਚੰਗਾ ਸੀ: ਬਹੁਤ ਸਾਰੇ ਸਮਕਾਲੀ ਕਨੈਕਸ਼ਨ, ਨੈੱਟਵਰਕ ਉੱਤੇ ਵੱਧ ਉਡੀਕ, ਅਤੇ ਛੋਟੇ-ਛੋਟੇ ਅਪਡੇਟ ਬਹੁਤ ਸਾਰੇ।

Node ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦਾ—ਅਤੇ ਕਿੱਥੇ ਨਹੀਂ

Node ਉਹ ਵੇਲੇ ਮਜ਼ਬੂਤ ਚੋਣ ਹੈ ਜਦ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਤੇਜ਼ ਇਤਰੇਸ਼ਨ, ਰੀਅਲ-ਟਾਈਮ ਇੰਟਰੈਕਸ਼ਨ, ਜਾਂ ਟੀਮਾਂ ਵਿੱਚ ਇੱਕ ਇਕਾਈ JavaScript ਸਟੈਕ ਦੀ ਲੋੜ ਹੋਵੇ। ਇਹ ਘੱਟ ਸੁਖਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਭਾਰੀ CPU-ਬਾਂਧ ਪ੍ਰੋਸੈਸਿੰਗ ਕਰ ਰਹੇ ਹੋ (ਜੈਵੇਂ ਵੱਡਾ ਵੀਡੀਓ ਐਨਕੋਡਿੰਗ ਕੰਮ) ਜਦ ਤਕ ਤੁਸੀਂ ਉਹ ਕੰਮ ਮਾਹਿਰ ਸੇਵਾਵਾਂ ਜਾਂ ਵੱਖਰੇ ਵਰਕਰ ਪ੍ਰੋਸੈਸਾਂ ਨੂੰ ਆਫਲੋਅਡ ਨਾ ਕਰੋ।

Node.js ਨੇ ਹਰ ਬੈਕਐਂਡ ਭਾਸ਼ਾ ਨੂੰ ਬਦਲਿਆ ਨਹੀਂ—ਪਰ ਇਸਨੇ JavaScript ਨੂੰ ਸਰਵਰ 'ਤੇ ਇੱਕ ਯੋਗਦਾਨੀ ਵਿਕਲਪ ਬਣਾਇਆ।

npm ਅਤੇ ਇਕੋਸਿਸਟਮ ਫਲਾਈਵ੍ਹੀਲ

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

ਇਹ ਇੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਕਿਉਂ ਵਧਿਆ

npm ਨੇ ਕੋਡ ਸਾਂਝਾ ਕਰਨ ਨੂੰ ਘੱਟ ਰੋਕਟੋਕ ਬਣਾ ਦਿੱਤਾ। ਪਬਲਿਸ਼ਿੰਗ ਸਿਧਾ ਸਾਦਾ ਸੀ, ਪੈਕੇਜ ਛੋਟੇ ਹੋ ਸਕਦੇ ਸਨ, ਅਤੇ JavaScript ਡਿਵੈਲਪਰ ਬਹੁਤ ਵਾਰੀ ਛੋਟੇ ਮਾਡਿਊਲਾਂ ਨੂੰ ਜੋੜ ਕੇ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦੇ ਹਨ।

ਇਸਨੇ ਇੱਕ ਫਲਾਈਵ੍ਹੀਲ ਬਣਾਇਆ: ਵੱਧ ਡਿਵੈਲਪਰ = ਵੱਧ ਪੈਕੇਜ; ਵੱਧ ਪੈਕੇਜ JavaScript ਨੂੰ ਹੋਰ ਆਕਰਸ਼ਕ ਬਣਾਉਂਦੇ; ਜੋ ਹੋਰ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਆਕਰਸ਼ਿਤ ਕਰਦਾ।

ਪ੍ਰਯੋਗਿਕ ਫਾਇਦੇ: ਦੁਬਾਰਾ ਵਰਤੋਂ ਅਤੇ ਤੇਜ਼ੀ

ਟੀਮਾਂ ਲਈ ਫਾਇਦੇ ਤੁਰੰਤ ਨੇ:

• ਪ੍ਰਮਾਣਿਤ ਹੱਲ ਦੁਬਾਰਾ ਵਰਤੋ ਬਜਾਏ ਹਰ ਪ੍ਰੋਜੈਕਟ ਲਈ ਮੁਲ-ਕੋਡ ਲਿਖਣ ਦੇ।
• ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਇਪ ਬਣਾਓ: ਬਿਲਡਿੰਗ ਬਲਾਕ ਜੋੜ ਕੇ ਤੇਜ਼ੀ ਨਾਲ ਇਤਰਾਜ਼ ਕਰੋ।
• ਅੰਦਰੂਨੀ ਸਟੈਂਡਰਡ ਬਣਾਓ: ਸਾਂਝੇ ਯੂਟਿਲਿਟੀਜ਼ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਪਬਲਿਸ਼ ਕਰੋ ਅਤੇ ਵੱਖ-ਵੱਖ ਐਪਸ ਵਿੱਚ ਵਰਤੋਂ।

ਗੈਰ-ਤਕਨੀਕੀ ਹਿੱਸੇਦਾਰ ਵੀ ਅਸਰ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ: ਕਈ ਵਾਰ ਫੀਚਰ ਜਲਦੀ ਸ਼ਿਪ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਆਮ ਪਲੰਬਿੰਗ ਪਹਿਲਾਂ ਹੀ ਉਪਲਬਧ ਹੁੰਦੀ ਹੈ (ਰਾਊਟਿੰਗ, ਵੇਲਿਡੇਸ਼ਨ, ਬੰਡਲਿੰਗ, ਟੈਸਟਿੰਗ)।

ਖਤਰਿਆਂ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਦੇ ਟਰੇਡ-ਆਫ

ਉਹੀ ਆਸਾਨੀ ਖਤਰੇ ਵਿੱਚ ਵੀ ਬਦਲ ਸਕਦੀ ਹੈ:

• ਡੀਪੈਂਡੈਂਸੀ ਓਵਰਲੋਡ: ਇੱਕ ਸਧਾਰਨ ਫੀਚਰ ਸੈਂਕੜਿਆਂ ਟ੍ਰਾਂਸੀਟਿਵ ਪੈਕੇਜ ਖਿੱਚ ਸਕਦਾ ਹੈ।
• ਸੁਰੱਖਿਆ: ਇੱਕ ਕਮਜ਼ੋਰ ਜਾਂ ਹੈਕੀ ਕੀਤੀ ਪੈਕੇਜ ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ।
• ਰੱਖ-ਰਖਾਅ ਡ੍ਰਿਫਟ: ਲੋਕਪ੍ਰਿਯ ਪੈਕੇਜ ਬਿਨਾਂ ਰੱਖਰਖਾਅ ਦੇ ਰਹਿ ਸਕਦੇ, ਜਿਸ ਨਾਲ ਜਲਦੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ।

ਉੱਤਮ ਟੀਮ npm ਨੂੰ ਇੱਕ ਸਪਲਾਈ ਚੇਨ ਵਾਂਗ ਗ੍ਰਹਿਣ ਕਰਦੀਆਂ ਹਨ: ਵਰਜਨ ਲਾਕ ਕਰੋ, ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਆਡਿਟ ਕਰੋ, ਚੰਗੇ-ਸਹਿਯੋਗ ਪੈਕੇਜਾਂ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦੇਓ, ਅਤੇ ਡਿਪੈਂਡੈਂਸੀ ਗਿਣਤੀ ਨੂੰ ਜਾਣ-ਭੁੱਝ ਕੇ ਰੱਖੋ—ਆਪੋ-ਆਪ ਨਹੀਂ।

ਫੁੱਲ-ਸਟੈਕ JavaScript: ਟੀਮਾਂ ਵਿਚਕਾਰ ਇੱਕੋ ਭਾਸ਼ਾ

"ਫੁੱਲ-ਸਟੈਕ JavaScript" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬ੍ਰਾਊਜ਼ਰ, ਸਰਵਰ, ਅਤੇ ਸਮਰਥਕ ਟੂਲਿੰਗ — ਤਕਰੀਬਨ JavaScript (ਅਤੇ ਅksar TypeScript) — ਇਹੀ ਭਾਸ਼ਾ ਵਰਤੀ ਜਾਂਦੀ ਹੈ—ਇਸ ਤਰ੍ਹਾਂ ਉਹੀ ਲਹਿਜ਼ਾ ਯੂਜ਼ਰ ਜੋ ਵੇਖਦੇ ਹਨ ਅਤੇ ਜੋ ਬੈਕਐਂਡ ਚਲਦਾ ਹੈ ਦਾ ਸਾਮੀਤ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਠੋਸ ਉਦਾਹਰਣ

ਇੱਕ ਸਾਦਾ ਚੈਕਆਉਟ ਫਲੋ ਚੁਣੋ:

• ਫਰੰਟਐਂਡ (ਬ੍ਰਾਊਜ਼ਰ): React ਫਾਰਮ ਸ਼ਿਪਿੰਗ ਵੇਰਵੇ ਅਤੇ ਭੁਗਤਾਨ ਦੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਦਾ ਹੈ।
• ਬੈਕਐਂਡ (ਸਰਵਰ): Node.js API ਆਰਡਰ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦਾ, ਟੋਟਲ ਗਿਣਦਾ, ਅਤੇ ਭੁਗਤਾਨ ਪ੍ਰੋਵਾਈਡਰ ਨਾਲ ਗੱਲ ਕਰਦਾ।
• ਸਾਂਝਾ ਪੈਕੇਜ: ਇੱਕ ਛੋਟਾ ਅੰਦਰੂਨੀ ਲਾਇਬ੍ਰੇਰੀ (ਨਿੱਜੀ npm ਰਾਹੀਂ ਪਬਲਿਸ਼ ਕੀਤੀ) ਜਿਸ ਵਿੱਚ ਆਰਡਰ ਸਕੀਮਾ, ਇਨਪੁੱਟ ਵੈਲਿਡੇਸ਼ਨ ਨਿਯਮ, ਅਤੇ ਪ੍ਰਾਇਸਿੰਗ ਯੂਟਿਲਿਟੀਜ਼ ਹਨ।

ਨਤੀਜਾ: ਕਾਰੋਬਾਰ ਦੇ "ਨਿਯਮ" ਦੋ ਵੱਖਰੀ ਦੁਨੀਆਂ ਵਿੱਚ ਨਹੀਂ ਰਹਿੰਦੇ।

ਸਾਂਝਾ ਕੋਡ: ਘੱਟ ਮਿਲਾਪ

ਜਦ ਟੀਮਾਂ ਕਲੀਏਂਟ ਅਤੇ ਸਰਵਰ ਵਿਚਕਾਰ ਕੋਡ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ, ਤਾੰ ਤੁਸੀਂ ਕਲਾਸਿਕ "ਮੇਰੇ ਪਾਸੇ ਚੱਲ ਰਿਹਾ ਸੀ" ਸਮੱਸਿਆਵਾਂ ਘਟਾਉਂਦੇ ਹੋ:

• ਵੇਲਿਡੇਸ਼ਨ: ਇੱਕੋ ਨਿਯਮ (ਜ਼ਰੂਰੀ ਫੀਲਡ, ਫਾਰਮੈਟ, ਕੇਸਾਂ) ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਤੁਰੰਤ ਫੀਡਬੈਕ ਲਈ ਅਤੇ ਸਰਵਰ 'ਤੇ ਸੁਰੱਖਿਆ ਲਈ ਦੋਹਰਾਏ ਜਾਂਦੇ ਹਨ।
• ਟਾਈਪਸ ਅਤੇ ਕਾਂਟਰੈਕਟ: TypeScript ਨਾਲ, Order ਜਾਂ User ਦਾ ਆਕਾਰ ਐਂਡ-ਟੂ-ਐਂਡ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਵੀਕ ਤੋਡੇ-ਬਿਨਾ ਵਿਕਾਸ ਦੌਰਾਨ ਗਲਤੀਆਂ ਫੜ ਲਿਆ ਜਾਂਦੀਆਂ ਹਨ।
• ਯੂਟਿਲਿਟੀਜ਼: ਡੇਟ ਫਾਰਮੈਟਿੰਗ, ਮੁਦਰਾ ਗੋਲਾਈਂਗ, ਫੀਚਰ ਫਲੈਗ, ਅਤੇ ਅਨੁਮਤੀ ਚੈੱਕ ਇਕ ਵਾਰੀ ਲਿਖ ਕੇ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਟੀਮਾਂ ਫਰਕ ਕਿਵੇਂ ਮਹਿਸੂਸ ਕਰਦੀਆਂ

ਫੁੱਲ-ਸਟੈਕ JavaScript ਦ੍ਰਿਸ਼ਟੀ ਟੀਮਾਂ ਦੀ ਭਰਤੀ ਪੂਲ ਨੂੰ ਵਧਾ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਕਈ ਡਿਵੈਲਪਰ ਪਹਿਲਾਂ ਹੀ ਵੈੱਬ ਤੋਂ JavaScript ਜਾਣਦੇ ਹਨ। ਇਹ ਹੇਡਆਫ਼ ਘਟਾਉਂਦਾ: ਇੱਕ ਫਰੰਟਐਂਡ ਡਿਵੈਲਪਰ ਬਿਨਾਂ ਭਾਸ਼ਾ ਬਦਲੇ API ਵਿੱਚ ਇੱਕ ਮੁੱਦਾ ਟਰੇਸ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਮਾਲਕੀਅਤ ਸਾਂਝੇ-ਓਨਰਸ਼ਿਪ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ।

ਇਹ ਵੀ ਯਾਦ ਰਹੇ ਕਿ "ਫੁੱਲ-ਸਟੈਕ" ਲਾਜ਼ਮੀ ਨਹੀਂ ਕਿ "ਹਰ ਥਾਂ JavaScript" ਹੋਵੇ। ਕਈ ਟੀਮਾਂ ਇੱਕ JavaScript/TypeScript ਫਰੰਟਐਂਡ ਨੂੰ ਪ੍ਰਦਰਸ਼ਨ, ਸਾਦਗੀ, ਜਾਂ ਭਰਤੀ ਦੇ ਕਾਰਨ ਕਿਸੇ ਹੋਰ ਬੈਕਐਂਡ ਭਾਸ਼ਾ ਨਾਲ ਜੋੜਦੀਆਂ ਹਨ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਇਹ ਹਕੀਕਤ ਦਰਸਾਉਂਦੇ ਹਨ—ਉਹ React-ਭਰਤੀ ਫਰੰਟਐਂਡ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਦੇ ਹਨ ਪਰ Go + PostgreSQL ਬੈਕਐਂਡ ਜਨਰੇਟ ਕਰਦੇ ਹਨ—ਇਸ ਤਰ੍ਹਾਂ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਸਮੱਗਰੀ ਸਟੈਕ ਮਿਲਦਾ ਹੈ, ਪਰ ਹਰ ਲੇਅਰ 'ਤੇ ਇੱਕੋ ਭਾਸ਼ਾ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।

ਸੱਚਾਈ ਵਾਲੇ ਟਰੇਡ-ਆਫ

ਸਭਤੋਂ ਵੱਡੀ ਲਾਗਤ ਹੈ ਟੂਲਿੰਗ ਜਟਿਲਤਾ। ਆਧੁਨਿਕ JavaScript ਐਪਸ ਅਕਸਰ ਬਿਲਡ ਪਾਈਪਲਾਈਨ, ਬੰਡਲਰ, ਟ੍ਰਾਂਸਪਾਈਲਰ, ਇਨਵਾਇਰਨਮੈਂਟ ਮੈਨੇਜਮੈਂਟ, ਅਤੇ ਡਿਪੈਂਡੈਂਸੀ ਅਪਡੇਟ ਮੰਗਦੇ ਹਨ। ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਸੀਂ ਉਸ ਮਸ਼ੀਨਰੀ ਨੂੰ ਰੱਖ-ਰਖਾਅ ਕਰਨ ਵਿੱਚ ਵੀ ਸਮਾਂ ਖਰਚੋਗੇ ਜੋ "ਹਰ ਥਾਂ ਇੱਕੋ ਭਾਸ਼ਾ" ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।

TypeScript: ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ JavaScript ਨੂੰ ਸਰਲ ਬਣਾਉਣਾ

TypeScript ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ: ਆਪਸ਼ਨਲ ਟਾਈਪਾਂ ਨਾਲ JavaScript। ਤੁਸੀਂ ਅਜੇ ਵੀ ਜਾਣੂ JavaScript ਲਿਖਦੇ ਹੋ, ਪਰ ਤੁਸੀਂ ਉਹਨਾਂ ਅਤਿਰਿਕਤ ਨੋਟਸਸ਼ਨਸ ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਵੈਲਿਊਜ਼ ਕਿਵੇਂ ਦਿੱਸਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ—ਨੰਬਰ, ਸਟਰਿੰਗ, ਖਾਸ ਢਾਂਚੇ ਵਾਲੇ ਆਬਜੈਕਟ ਆਦਿ।

ਉਹ ਨੋਟਸਸ਼ਨਸ ਬ੍ਰਾਊਜ਼ਰ ਜਾਂ ਸਰਵਰ 'ਤੇ ਨਹੀਂ ਚਲਦੇ। ਬਦਲੇ ਵਿੱਚ, TypeScript ਵਿਕਾਸ ਦੌਰਾਨ ਚੈਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਸਾਫ JavaScript ਵਿੱਚ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਵੱਡੀਆਂ ਟੀਮਾਂ ਨੇ ਇਹ ਕਿਉਂ ਅਪਣਾਇਆ

ਜਿਵੇਂ-ਜਿਵੇਂ ਪ੍ਰੋਜੈਕਟ ਵੱਡੇ ਹੁੰਦੇ ਹਨ, ਛੋਟੀਆਂ "ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲ ਰਿਹਾ ਸੀ" ਗਲਤੀਆਂ ਮਹਿੰਗੀਆਂ ਬੱਗ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। TypeScript ਇਨ੍ਹਾਂ ਨੂੰ ਘੱਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ: ਗਲਤ ਬਰਾਮਦ ਕੀਤੇ ਗੁਣ-ਨਾਂ, ਗਲਤ ਟਾਈਪ ਦਾ ਆਰਗੁਮੈਂਟ ਦੇਣਾ, ਜਾਂ ਕਿਸੇ ਕੇਸ ਨੂੰ ਹੇਠਾਂ ਕਰਨਾ ਭੁੱਲ ਜਾਣਾ।

ਇਹ ਰੋਜ਼ਾਨਾ ਉਪਜੋਗਨੀਤਾ ਨੂੰ ਵੀ ਵਧਾਉਂਦਾ ਹੈ—ਐਡੀਟਰ ਸਹਾਇਤਾ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ: ਆਟੋ-ਕੰਪਲੀਸ਼ਨ, ਇੰਲਾਈਨ ਡੌਕ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਰਿਫੈਕਟਰਿੰਗ—ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡੇ ਕੋਡ ਦੀ ਨੀਤ ਸਮਝਦਾ ਹੈ ਨਾ ਕਿ ਸਿਰਫ਼ ਸਿੰਟੈਕਸ।

ਇਹ ਆਧੁਨਿਕ ਟੂਲਿੰਗ ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਬੈਠਦਾ (ਰੰਟਾਈਮ ਮੂਲ-ਸਿਧਾਂਤ ਬਦਲੇ ਬਿਨਾਂ)

TypeScript ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਬਿਲਡ ਸਟੈਪ ਵਿੱਚ ਫਿੱਟ ਹੋ ਜਾਂਦਾ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੁੰਦਾ: ਬੰਡਲਰ, ਟੈਸਟ ਰਨਰ, ਲਿੰਟਰ, ਅਤੇ CI। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡਾ ਰੰਟਾਈਮ ਫਿਰ ਵੀ JavaScript ਹੁੰਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ, Node.js, ਅਤੇ ਸਰਵਰਲੇਸ ਪਲੇਟਫਾਰਮ TypeScript ਨਹੀਂ ਚਲਾਉਂਦੇ—ਉਹ JavaScript ਆਉਟਪੁੱਟ ਚਲਾਉਂਦੇ ਹਨ।

ਇਸੀ ਕਾਰਨ TypeScript ਵਿਕਾਸ ਅਨੁਭਵ ਲਈ ਇੱਕ ਅੱਪਗਰੇਡ ਵਰਗਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਬਜਾਏ ਕਿਸੇ ਵੱਖਰੇ ਪਲੇਟਫਾਰਮ ਦੇ।

ਜਦੋਂ ਸਧਾਰਾ JavaScript ਕਾਫੀ ਹੁੰਦਾ

ਜੇ ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ ਸਕ੍ਰਿਪਟ, ਇੱਕ ਛੋਟੀ-ਅਵਧੀ ਪ੍ਰੋਟੋਟਾਈਪ, ਜਾਂ ਘੱਟ ਲਾਜਿਕ ਵਾਲੀ ਇੱਕ ਛੋਟੀ ਸਾਈਟ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਸਧਾਰਾ JavaScript ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਤੇਜ਼ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਸਾਦਾ ਹੋ ਸਕਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਜਦ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ ਕਿ ਕੋਡਬੇਸ ਲੰਮੇ ਸਮੇਂ ਲਈ ਰਹੇਗਾ, ਕਈ ਯੋਗਦਾਨਕਾਰ ਹੋਣਗੇ, ਜਾਂ ਕਈ ਡਾਟਾ ਤਬਦੀਲੀਆਂ ਹੋਣ ਜਿੱਥੇ ਗਲਤੀਆਂ ਰਿਵਿਊ ਦੇ ਦੌਰਾਨ ਪਕੜਨੀਆਂ ਔਖੀਆਂ ਹੋਣ, ਤਾਂ TypeScript ਆਮ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ।

JavaScript ਦੀ ਸਫ਼ਲਤਾ ਤੋਂ ਸਿੱਖਣ ਯੋਗ ਗੱਲਾਂ

JavaScript "ਜਿੱਤ ਗਿਆ" ਇੱਕ ਸਧਾਰਣ ਕਾਰਨ ਕਰਕੇ: ਇਹ ਪੂਰਾ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਹਰ ਜਗ੍ਹਾ ਸੀ।

ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਅੰਦਰ ਸ਼ਿਪ ਹੋਇਆ, ਇਸ ਲਈ ਵੰਡ ਆਪ-ਕਾਰ ਸੰਭਵ ਸੀ। ਇਹ ECMAScript ਵਜੋਂ ਮਿਆਰਬੱਧ ਕੀਤਾ ਗਿਆ, ਜਿਸਦਾ ਮਤਲਬ ਸੀ ਭਾਸ਼ਾ ਕਿਸੇ ਇਕ ਵੈਂਡਰ ਦੀ ਮਰਜ਼ੀ 'ਤੇ ਨਹੀਂ ਸੀ। ਇੰਜਨਾਂ ਨੇ ਦਰਜਨ ਬੇਹਤਰੀ ਕੀਤੀ, ਸਕ੍ਰਿਪਟਿੰਗ ਨੂੰ ਗੰਭੀਰ ਐਪਸ ਲਈ ਤੇਜ਼ ਬਣਾਇਆ। ਫਿਰ ਇਕੋਸਿਸਟਮ ਦਾ ਸੰਯੋਜਕ ਪ੍ਰਭਾਵ ਚੱਲਿਆ: npm ਪੈਕੇਜ, ਸਾਂਝਾ ਟੂਲਿੰਗ, ਅਤੇ ਛੋਟੇ, ਦੁਬਾਰਾ ਵਰਤਣ ਯੋਗ ਮੋਡੀਊਲਾਂ ਦੀ ਪ੍ਰਕਿਰਤੀ ਨੇ JavaScript ਨਾਲ ਬਣਾਉਣਾ ਆਸਾਨ ਬਣਾ ਦਿੱਤਾ।

"ਅਕਸਮਾਤ" ਮਿਥ, ਸਪਸ਼ਟੀਕਰਨ

ਹਾਂ, JavaScript ਇੱਕ ਤੇਜ਼ ਬਣਾਈ ਗਈ ਚੀਜ਼ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਈ। ਪਰ ਇਸਦੀ ਵਧਤਲਾ ਕਿਸਮ ਕਿਸੇ ਬਿਹਤੀ ਚੀਜ਼ 'ਤੇ ਨਸੀਬ ਨਹੀਂ ਸੀ।

ਜਿਵੇਂ-ਜਿਵੇਂ ਵੈੱਬ ਉਸ 'ਤੇ ਨਿਰਭਰ ਹੋਇਆ, ਬ੍ਰਾਊਜ਼ਰ ਇਸਨੂੰ ਚਲਾਉਣ ਵਿੱਚ ਬਿਹਤਰ ਹੋਣ ਦੀ ਮੁਕਾਬਲੇ ਕਰਦੇ ਰਹੇ। ਜਿਵੇਂ-ਜਿਵੇਂ ਕੰਪਨੀਆਂ ਨੇ ਇਸਤੇ ਨੌਕਰੀਆਂ ਭਰਣੀਆਂ ਸ਼ੁਰੂ ਕੀਤੀਆਂ, ਟ੍ਰੇਨਿੰਗ, ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ, ਅਤੇ ਕਮਿਊਨਿਟੀ ਸਹਾਇਤਾ ਉਭਰੀ। Node.js ਦੇ ਆਉਣ ਨਾਲ, ਟੀਮਾਂ ਹੁਣ ਸਕਿlls ਅਤੇ ਕੋਡ ਨੂੰ ਦੋਹਾਂ ਪਾਸਿਆਂ 'ਤੇ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੀਆਂ ਹਨ। ਹਰ ਕਦਮ ਨੇ ਅਗਲੇ ਨੂੰ ਮਜ਼ਬੂਤ ਕੀਤਾ, ਜਿਸ ਨਾਲ JavaScript ਇੱਕ ਵਿਵਹਾਰਕ ਡਿਫਾਲਟ ਬਣ ਗਿਆ ਭਾਵੇਂ ਹੋਰ ਭਾਸ਼ਾ ਕਾਗਜ਼ 'ਤੇ ਸੁੱਕੀ ਤੇ ਸਾਫ਼ ਲੱਗਦੀ ਹੋਵੇ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਸ਼ਕਰਸ਼: ਜਦ JavaScript ਚੁਣੀਏ

ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਲਈ JavaScript ਦੀ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੰਟਰਨੈੱਟ ਦੀਆਂ ਚਰਚਿਆਂ ਤੋਂ ਘੱਟ ਅਤੇ ਹੇਠਾਂ ਲਿਖੇ ਸਵਾਲਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ:

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

ਜੇ ਤੁਹਾਡਾ ਤੁਰੰਤ ਲਕੜਾ ਪ੍ਰੋਟੋਟਾਈਪ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣਾ ਹੈ (ਖਾਸਕਰ React-ਅਧਾਰਤ ਵੈੱਬ ਐਪ ਲਈ), ਤਾਂ Koder.ai ਵਰਗੇ ਟੂਲ ਤੁਹਾਡੀ ਆਵਸ਼ਕਤਾ ਤੋਂ ਰਹਿਤਾ ਲਈ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ—ਚੈਟ ਰਾਹੀਂ ਲੋੜਾਂ ਤੋਂ ਕੰਮ ਕਰਦੇ ਐਪ ਤੱਕ, ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ, ਡੈਪਲੌਇਮੈਂਟ/ਹੋਸਟਿੰਗ, ਕਸਟਮ ਡੋਮੇਨ ਵਿਕਲਪ, ਅਤੇ ਰੋਲਬੈਕ ਲਈ ਸਨੇਪਸ਼ਾਟ।

ਫਿਰ ਕੀ, ਹੋਰ ਇੰਜੀਨੀਅਰਿੰਗ ਬੈਕਸਟੋਰੀਆਂ ਲਈ, ਵੇਖੋ /blog। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਡੈਵ ਉਤਪਾਦ ਲਈ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਇੱਕ ਸਾਫ਼ ਖਰਚਾ-ਬ੍ਰੇਕਡਾਊਨ ਚਾਹੁੰਦੇ ਹੋ, /pricing ਇੱਕ ਚੰਗਾ ਅਗਲਾ ਕਦਮ ਹੈ।