JavaScript ਅਤੇ TypeScript ਦੀ ਤੁਲਨਾ ਸਪਸ਼ਟ ਉਦਾਹਰਨਾਂ ਨਾਲ: ਟਾਈਪਿੰਗ, ਟੂਲਿੰਗ, ਗਤੀ, ਰਖ-ਚਾਲ ਅਤੇ ਕਦੋਂ ਕਿਹੜਾ موزوں ਹੈ। ਪ੍ਰਯੋਗਕਾਰੀ ਮਾਈਗਰੇਸ਼ਨ ਸੁਝਾਅ ਵੀ ਸ਼ਾਮਲ ਹਨ।

JavaScript ਉਹ ਭਾਸ਼ਾ ਹੈ ਜੋ ਹਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਚਲਦੀ ਹੈ ਅਤੇ ਸਰਵਰਾਂ (Node.js ਨਾਲ) 'ਤੇ ਵੀ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਦੇ ਵੈਬਸਾਈਟ ਦਾ ਮੇਨੂ, ਫਾਰਮ ਵੈਲੀਡੇਸ਼ਨ ਜਾਂ ਇਕ single-page ਐਪ ਵਰਤੀ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਪਿਛੋਕੜ ਵਿੱਚ JavaScript ਕੰਮ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ.
TypeScript JavaScript 'ਤੇ ਇਕ ਵਾਧੂ "ਲੇਅਰ" ਹੈ: ਟਾਈਪਸ. ਤੁਸੀਂ TypeScript ਲਿਖਦੇ ਹੋ, ਪਰ ਇਹ ਸਧਾਰਣ JavaScript ਵਿੱਚ ਕੰਪਾਇਲ (ਬਦਲ) ਹੁੰਦੀ ਹੈ ਜਿਸਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ Node.js ਚਲਾ ਸਕਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ TypeScript JavaScript ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੀ — ਇਹ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੈ.
"ਟਾਈਪ" ਇੱਕ ਲੇਬਲ ਹੈ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਸ ਕਿਸਮ ਦੀ ਵੈਲਿਊ ਹੈ — ਜਿਵੇਂ ਨੰਬਰ, ਟੈਕਸਟ, ਜਾਂ ਕਿਸੇ ਠੇਠ ਫੀਲਡਾਂ ਵਾਲਾ ਆਬਜੈਕਟ। JavaScript ਇਹ ਚਲਦੇ ਸਮੇਂ ਸਮਝਦਾ ਹੈ। TypeScript ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਧਾਰਣਾਵਾਂ ਕੋਡ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਚੈੱਕ ਕੀਤੀਆਂ ਜਾਣ ਤਾਂ ਕਿ ਗਲਤੀਆਂ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਲੱਗ ਜਾਣ।
ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ:
function totalPrice(price: number, qty: number) {
return price * qty;
}
totalPrice(10, 2); // ok
totalPrice("10", 2); // TypeScript warns: "10" is a string, not a number
JavaScript ਵਿੱਚ ਦੂਜਾ ਕਾਲ ਚੁਪਚਾਪ ਲੰਘ ਸਕਦਾ ਹੈ ਜਦ ਤਕ ਇਹ ਕਿਸੇ ਗੁੰਝਲਦਾਰ ਬੱਗ ਦੇ ਰੂਪ ਵਿੱਚ ਸਾਹਮਣੇ ਨਾ ਆਵੇ। TypeScript ਵਿੱਚ, ਤੁਹਾਡੇ ਐਡੀਟਰ ਜਾਂ ਬਿਲਡ ਦੌਰਾਨ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਚੇਤਾਵਨੀ ਮਿਲ ਜਾਏਗੀ।
ਇਹ ਕਿਸੇ ਭਾਸ਼ਾ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ "ਵਧੀਆ" ਦੱਸਣ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਫੈਸਲਾ ਸਹਾਇਕ ਹੈ: ਕਿੱਥੇ JavaScript ਸਧਾਰਨ ਚੋਣ ਹੈ, ਕਿੱਥੇ TypeScript ਲਾਭਦਾਇਕ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਕਿਸ ਤਰ੍ਹਾਂ ਦੇ ਟਰੇਡ-ਆਫ ਲਈ ਸਹਿਮਤ ਹੋ ਰਹੇ ਹੋ।
TypeScript ਕੋਈ ਵਿਲੱਖਣ "ਬਦਲੀ" ਭਾਸ਼ਾ ਨਹੀਂ ਹੈ—ਇਹ ਇੱਕ superset ਹੈ ਜੋ ਵਿਕਲਪੀ ਟਾਇਪਿੰਗ ਅਤੇ ਕੁਝ ਡਿਵੈਲਪਰ-ਦਰਜਿਆਂ ਫੀਚਰਾਂ ਨੂੰ ਆਮ JS ਉੱਤੇ ਜੋੜਦਾ ਹੈ। ਮੁੱਖ ਵਿਚਾਰ: ਤੁਸੀਂ TypeScript ਲਿਖਦੇ ਹੋ, ਪਰ ਤੁਸੀਂ JavaScript ਸ਼ਿਪ ਕਰਦੇ ਹੋ।
TypeScript Microsoft ਵਲੋਂ ਬਣਾਇਆ ਗਿਆ ਸੀ ਅਤੇ ਪਹਿਲੀ ਵਾਰੀ 2012 ਵਿੱਚ ਰਿਲੀਜ਼ ਹੋਇਆ, ਜਦੋਂ ਵੱਡੇ JavaScript ਕੋਡਬੇਸ ਵੈਬ ਐਪਸ ਵਿੱਚ ਆਮ ਹੋ ਰਹੇ ਸਨ। ਟੀਮਾਂ ਨੇ ਚਾਹਿਆ ਕਿ ਹੋਰ ਵਧੀਆ ਟੂਲਿੰਗ (autocomplete, safe refactoring) ਅਤੇ ਘੱਟ runtime ਹੈਰਾਨੀਆਂ ਹੋਣ, ਬਿਨਾਂ JavaScript ਇੱਕੋਸਿਸਟਮ ਨੂੰ ਛੱਡੇ।
ਚਾਹੇ ਤੁਸੀਂ ਜਿੰਨਾ ਵੀ TypeScript ਵਰਤੋ, ਰਨਟਾਈਮ ਮਹੱਤਵਪੂਰਨ ਹੈ:
ਇਸ ਲਈ TypeScript ਨੂੰ ਰਨ ਕਰਨ ਲਈ JavaScript ਵਿੱਚ ਬਦਲਣਾ ਪੈਂਦਾ ਹੈ।
TypeScript ਤੁਹਾਡੇ ਬਿਲਡ ਪ੍ਰੋਸੈਸ ਦੌਰਾਨ ਇੱਕ ਟ੍ਰਾਂਸਪਾਇਲ (ਕੰਪਾਇਲ) ਕਦਮ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ। ਇਹ ਕਦਮ ਤੁਹਾਡੇ ਟੂਲਚੇਨ ਵਿੱਚ ਚਲਦਾ—ਆਮ ਤੌਰ 'ਤੇ ਵਿਕਾਸ ਦੌਰਾਨ ਤੁਹਾਡੇ ਮਸ਼ੀਨ 'ਤੇ ਅਤੇ ਡਿਪਲੋਏਮੈਂਟ ਦੌਰਾਨ CI/CD 'ਤੇ।
ਆਮ ਸੈੱਟਅੱਪ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
tsc (TypeScript ਕੰਪਾਇਲਰ)ਆਉਟਪੁਟ ਸਧਾਰਨ .js ਫਾਇਲਾਂ (ਅਤੇ ਵਿਕਲਪੀ ਸੋਰਸ-ਮੈਪ) ਹੁੰਦੀ ਹੈ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਜਾਂ Node.js ਚਲਾ ਸਕਦੇ ਹਨ।
ਕਿਉਂਕਿ TypeScript JavaScript 'ਤੇ ਬਣਦਾ ਹੈ, ਇਹ ਉਹੀ ਫਰੇਮਵਰਕਸ ਅਤੇ ਪਲੇਟਫਾਰਮ ਨਾਲ ਕੰਮ ਕਰਦਾ: React, Vue, Angular, Express, Next.js ਆਦਿ। ਜ਼ਿਆਦਾਤਰ ਲੋਕਪ੍ਰਿਯ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵੀ TypeScript ਟਾਈਪ ਡਿਫ਼ਿਨੀਸ਼ਨ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ, ਚਾਹੇ ਉਹ ਬਿਲਟ-ਇਨ ਹੋਣ ਜਾਂ ਕਮੀੂਨਿਟੀ ਰਾਹੀਂ।
ਕਈ ਟੀਮਾਂ ਲਈ ਪ੍ਰੈਕਟਿਕਲ ਹਕੀਕਤ: ਤੁਹਾਨੂੰ ਸਭ-ਜਗ੍ਹਾ ਇੱਕੋ ਸਮੇਂ ਸਵਿੱਚ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਆਮ ਹੈ ਕਿ ਇੱਕ ਪ੍ਰਾਜੈਕਟ ਵਿੱਚ ਦੋਹਾਂ .js ਅਤੇ .ts ਫਾਇਲਾਂ ਹੋਣ, ਜਦੋਂ-ਜਦੋਂ ਤੁਸੀਂ ਮੋਡੀਊਲਾਂ ਨੂੰ ਛੂੰਹਦੇ ਹੋ ਉਹਨਾਂ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ ਰੂਪਾਂਤਰਿਤ ਕਰਦੇ ਹੋ, ਤੇ ਐਪ JavaScript ਵਜੋਂ ਹੀ ਬਿਲਡ ਅਤੇ ਰਨ ਹੁੰਦੀ ਰਹਿੰਦੀ ਹੈ।
ਟਾਈਪ ਸੇਫ਼ਟੀ TypeScript ਦੀ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ: ਇਹ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਤੁਹਾਡੇ ਡੇਟਾ ਦਾ ਆਕਾਰ ਕੀ ਹੈ, ਅਤੇ ਇਹ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਚੈੱਕ ਕਰਦੀ ਹੈ। ਇਸ ਨਾਲ ਤੁਸੀਂ ਕੁਝ ਗਲਤੀਆਂ ਜਲਦੀ ਪਹੁੰਚਦੇ ਹੋ—ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲਾਗਤ ਘੱਟ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਆਮ JavaScript "ਠੀਕ ਲੱਗਦਾ" ਬੱਗ:
function total(items) {
return items.reduce((sum, x) => sum + x.price, 0);
}
total([{ price: 10 }, { price: "20" }]); // "1020" (string concatenation)
ਇਹ runtime 'ਤੇ ਚੁਪਚਾਪ ਫੇਲ ਹੁੰਦਾ ਹੈ ਤੇ ਗਲਤ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ। TypeScript ਵਿੱਚ:
type Item = { price: number };
function total(items: Item[]) {
return items.reduce((sum, x) => sum + x.price, 0);
}
total([{ price: 10 }, { price: "20" }]);
// Compile-time error: Type 'string' is not assignable to type 'number'.
ਇਹ "ਕੰਪਾਇਲ-ਟਾਈਮ ਐਰਰ" ਮਤਲਬ ਤੁਹਾਡੇ ਐਡੀਟਰ/ਬਿਲਡ ਦੌਰਾਨ ਤੁਰੰਤ ਫਲੈਗ ਹੋ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਤੁਹਾਡੇ ਜਾਂ ਕਿਸੇ ਯੂਜ਼ਰ ਦੇ ਸਾਹਮਣੇ।
TypeScript ਕਈ ਰਨਟਾਈਮ ਹੈਰਾਨੀਆਂ ਨੂੰ ਘਟਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਰਨਟਾਈਮ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਨਹੀਂ ਕਰਦਾ।
ਜ਼ਿਆਦਾਤਰ ਕੋਡ ਕੁਝ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ:
string, number, booleanstring[] (arrays), Item[]{ name: string; isActive: boolean }TypeScript ਅਕਸਰ ਆਪਣੇ ਆਪ ਟਾਈਪਸ ਅਨੁਮਾਨ ਲਗਾਉਂਦਾ ਹੈ:
const name = "Ada"; // inferred as string
const scores = [10, 20, 30]; // inferred as number[]
any ਨਾਲ ਛੱਡ ਸਕਦੇ ਹੋ, ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਰੱਖਿਆਵਾਂ ਹਟਾ ਦਿੰਦਾ ਹੈ।ਟਾਈਪ ਸੇਫ਼ਟੀ ਨੂੰ ਇਕ ਅਰਲੀ-ਵਾਰਨਿੰਗ ਸਿਸਟਮ ਵਜੋਂ ਦੇਖੋ: ਇਹ ਬਹੁਤ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਕਾਫ਼ੀ ਪਹਿਲਾਂ ਫੜ ਲੈਂਦਾ ਹੈ, ਪਰ ਅਣਚਾਹੇ ਡੇਟਾ ਲਈ ਤਾਂ ਤੁਹਾਨੂੰ ਟੈਸਟਿੰਗ ਅਤੇ ਰਨਟਾਈਮ ਚੈੱਕ ਵੀ ਰੱਖਣੇ ਪੈਣਗੇ।
TypeScript ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਲਾਭ ਕੋਈ ਨਵਾਂ ਰਨਟਾਈਮ ਫੀਚਰ ਨਹੀਂ—ਇਹ ਹੈ ਜੋ ਤੁਹਾਡਾ ਐਡੀਟਰ ਤੁਹਾਨੂੰ ਕੰਮ ਕਰਦਿਆਂ ਦੱਸ ਸਕਦਾ ਹੈ। ਕਿਉਂਕਿ ਕੰਪਾਇਲਰ ਤੁਹਾਡੇ ਡੇਟਾ ਦੇ ਆਕਾਰ ਨੂੰ ਸਮਝਦਾ ਹੈ, ਜ਼ਿਆਦਾਤਰ IDEs ਵਿਕਾਸ ਤੋਂ ਪਹਿਲਾਂ ਵਧੀਆ ਸੁਝਾਅ ਦਿੰਦੇ ਹਨ।
ਸਧਾਰਣ JavaScript ਨਾਲ, ਆਟੋਕਮਪਲੀਟ ਅਕਸਰ ਅਨੁਮਾਨਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੀ ਹੈ: ਨਾਮ-ਪੈਟਰਨ, ਸੀਮਤ ਇਨਫਰੈਂਸ, ਜਾਂ ਜੋ ਰਨਟਾਈਮ ਜਾਣਕਾਰੀ ਐਡੀਟਰ ਦੇ ਕੋਲ ਹੈ। TypeScript ਐਡੀਟਰ ਨੂੰ ਇਕ ਭਰੋਸੇਯੋਗ ਕੰਟ੍ਰੈਕਟ ਦਿੰਦਾ ਹੈ।
ਇਸਦਾ ਨਤੀਜਾ:
ਅਮਲ ਵਿੱਚ, ਇਹ "ਟੈਬਿੰਗ ਚਲਦੇ ਰਹਿਣ" ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਵੱਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਖਾਸ ਕਰਕੇ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ।
JavaScript ਵਿੱਚ ਰਿਫੈਕਟਰਿੰਗ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਅਸਾਨੀ ਨਾਲ ਤੁਸੀਂ ਕਿਸੇ stringly-typed ਰੇਫਰੈਂਸ, ਡਾਇਨਾਮਿਕ ਪ੍ਰਾਪਰਟੀ, ਜਾਂ ਪਰੋਈ ਇਕਸਪੋਰਟ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹੋ।
TypeScript ਰੀਨੇਮ ਸਿੰਬਲ ਅਤੇ ਚੇਂਜ ਸਿਗਨੇਚਰ ਵਰਗੇ ਰਿਫੈਕਟਰਿੰਗ ਟੂਲਾਂ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ ਕਿਉਂਕਿ ਐਡੀਟਰ ਜਾਣ ਸਕਦਾ ਹੈ ਕਿ ਕਿਸ ਥਾਂ ਕਿਸ ਟਾਈਪ ਜਾਂ ਫੰਕਸ਼ਨ ਦਾ ਰੈਫਰੈਂਸ ਹੈ। ਜਦੋਂ API ਬਦਲਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ ਇੱਕ ਫੰਕਸ਼ਨ ਹੁਣ User | null ਰਿਟਰਨ ਕਰਦਾ ਹੈ), TypeScript ਹਰ ਉਸ ਜਗ੍ਹਾ ਨੂੰ ਹਾਈਲਾਈਟ ਕਰਦਾ ਜੋ ਅੱਪਡੇਟ ਦੀ ਲੋੜ ਰੱਖਦੀ ਹੈ। ਇਹ ਸਿਰਫ ਸਹੂਲਤ ਹੀ ਨਹੀਂ—ਇਹ ਸੁਬਟ ਰਿਗ੍ਰੈਸ਼ਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਟਾਈਪਸ ਕੋਡ ਵਿੱਚ ਹਲਕੀ-ਫੁਲਕੀ ਡੌਕੂਮੈਂਟੇਸ਼ਨ ਵਾਂਗ ਹਨ। ਰਿਵਿью ਦੌਰਾਨ, ਅਕਸਰ ਮਕਸਦ ਸਮਝਣਾ ਸੋਖਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ:
ਰਿਵਿuers ਵਰਤੋਂ ਘੱਟ ਪਾਉਂਦੇ ਹਨ ਕਿ "ਇਹ ਆਬਜੈਕਟ ਦੀ ਸ਼ਕਲ ਕੀ ਹੈ?" ਅਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੌਜਿਕ, ਐਜ ਕੇਸ ਅਤੇ ਨਾਂਕਰਨ ਤੇ ਬਿਤਾਉਂਦੇ ਹਨ।
ਵੱਡੇ ਐਪਸ ਵਿੱਚ, TypeScript "go to definition" ਅਤੇ "find all references" ਨੂੰ ਕਾਫ਼ੀ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਕੰਪੋਨੈਂਟ ਤੋਂ ਉਸਦੇ props ਟਾਈਪ ਤੱਕ, ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਲ ਤੋਂ ਇੱਕ ਓਵਰਲੋਡ ਤੱਕ ਜਾਂ ਇੱਕ ਡੀਟੀਓ ਤੋਂ ਮੈਪਿੰਗ ਲੇਅਰ ਤੱਕ ਜਾ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਖੋਜ ਅਤੇ ਅਨੁਮਾਨ ਦੇ ਨਿਰਭਰ ਹੋਏ।
JavaScript ਓਥੇ ਚਲਦੀ ਹੈ ਜਿੱਥੇ ਹੈ: ਬ੍ਰਾਊਜ਼ਰ ਜਾਂ Node.js ਵਿੱਚ। ਤੁਸੀਂ .js ਫਾਇਲ ਲਿਖ ਸਕਦੇ ਹੋ ਅਤੇ ਤੁਰੰਤ ਚਲਾ ਸਕਦੇ ਹੋ—ਕੋਈ ਕੰਪਾਇਲੇਸ਼ਨ ਕਦਮ ਨਹੀਂ, ਕੋਈ ਵਿਸ਼ੇਸ਼ ਕਨਫਿਗ ਨਹੀਂ (ਜਿਵੇਂ ਜੋ ਤੁਹਾਡਾ ਫਰੇਮਵਰਕ ਪਹਿਲਾਂ ਹੀ ਵਰਤ ਰਿਹਾ ਹੋਵੇ)।
TypeScript ਵੱਖਰਾ ਹੈ: ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ Node .ts ਨੂੰ ਸਿੱਧਾ ਨਹੀਂ ਸਮਝਦੇ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਆਮ ਤੌਰ ਤੇ ਇੱਕ ਬਿਲਡ ਸਟੈਪ ਜੋੜਦੇ ਹੋ ਜੋ TypeScript ਨੂੰ JavaScript ਵਿੱਚ ਟ੍ਰਾਂਸਪਾਇਲ ਕਰਦਾ ਹੈ (ਅਕਸਰ ਸੋਰਸ-ਮੈਪ ਬਣਾਉਂਦੇ ਹੋ ਤਾਂ ਕਿ ਡੀਬੱਗ ਕਰਦੇ ਸਮੇਂ ਅਸਲੀ .ts ਲਾਇਨਾਂ ਨੂੰ ਦੇਖਿਆ ਜਾ ਸਕੇ)।
ਅਧਾਰਭੂਤ TypeScript ਸੈਟਅੱਪ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
typescript) ਅਤੇ ਅਕਸਰ ਕੋਈ ਰਨਰ/ਬੰਡਲਰ ਇੰਸਟਾਲ ਕਰਨਾtsconfig.json ਬਣਾਉਣਾਜੇ ਤੁਸੀਂ Vite, Next.js ਜਾਂ ਕਿਸੇ ਨੋਡ ਫਰੇਮਵਰਕ ਵਰਗੇ ਆਧੁਨਿਕ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਬਹੁਤ ਕੁਝ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰੀ-ਵਾਇਰ ਕੀਤਾ ਹੋ ਸਕਦਾ ਹੈ—ਪਰ TypeScript ਫਿਰ ਵੀ ਸਧਾਰਨ JS ਨਾਲੋਂ ਇਕ ਵਾਧੂ ਪਰਤ ਜੋੜਦਾ ਹੈ।
tsconfig.json TypeScript ਕੰਪਾਇਲਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿੰਨਾ ਕਠੋਰ ਹੋਣਾ ਹੈ ਅਤੇ ਕਿਸ ਕਿਸਮ ਦੀ JavaScript ਨਿਕਾਸ ਕਰਨੀ ਹੈ। ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਵਿਕਲਪ ਹਨ:
strict: ਮਜ਼ਬੂਤ ਚੈਕਸ ਚਾਲੂ ਕਰਦਾ ਹੈ (ਵਧੇਰੇ ਸੁਰੱਖਿਆ, ਸ਼ੁਰੂ ਵਿੱਚ ਵਧੇਰੇ ਫਿਕਸਾਂ)target: ਕਿਹੜੀ JavaScript ਵਰਜਨ ਨਿਕਾਸ ਕਰਨੀ ਹੈ (ਜਿਵੇਂ ਨਵੇਂ ਬਰਾਂਡ ਯਾ ਪੁਰਾਣੇ ਸਿੰਟੈਕਸ)module: ਮੋਡੀਊਲ ਕਿਵੇਂ ਜਨਰੇਟ/ਸਮਝੇ ਜਾਂਦੇ ਹਨ (Node ਵੋਰਸ ਬੰਡਲਰ ਲਈ ਮਹੱਤਵਪੂਰਨ)ਤੁਸੀਂ ਅਕਸਰ include/exclude (ਕਿਹੜੀਆਂ ਫਾਇਲਾਂ ਚੈੱਕ ਕੀਤੀਆਂ ਜਾਣ) ਅਤੇ outDir (ਕਿੱਥੇ ਕੰਪਾਇਲ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਜਾਣ) ਵੀ ਦੇਖੋਗੇ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਉਹੀ ਸਹਾਇਕ ਟੂਲ ਵਰਤਦੀਆਂ ਹਨ: ਇੱਕ ਬੰਡਲਰ (Vite/Webpack/esbuild), ਇੱਕ ਲਿੰਟਰ (ESLint), ਇੱਕ ਫਾਰਮੇਟਰ (Prettier), ਅਤੇ ਇੱਕ ਟੈਸਟ ਰਨਰ (Jest/Vitest)। TypeScript ਦੇ ਨਾਲ, ਇਹ ਟੂਲ ਅਕਸਰ ਟਾਈਪਸ ਨੂੰ ਸਮਝਣ ਲਈ ਕਨਫਿਗ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ CI ਆਮ ਤੌਰ 'ਤੇ tsc --noEmit ਜਿਹਾ ਇਕ ਟਾਈਪ-ਚੈੱਕ ਸਟੈਪ ਚਲਾਉਂਦਾ ਹੈ।
TypeScript ਬਿਲਡ ਸਮਾਂ ਵਧਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਵਧੇਰੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ। ਚੰਗੀ ਗੱਲ: ਇੰਕ੍ਰਿਮੈਂਟਲ ਬਿਲਡ ਇਸਨੂੰ ਕਾਫੀ ਹੱਦ ਤੱਕ ਹਲ ਕਰ ਦਿੰਦੇ ਹਨ। ਵਾਚ ਮੋਡ, ਕੈਸ਼ਡ ਬਿਲਡ ਅਤੇ "incremental" ਕੰਪਾਇਲ ਇੱਕ ਵਾਰੀ ਦੇ ਬਾਦ ਸਿਰਫ਼ ਬਦਲੇ ਹੋਏ ਹਿੱਸੇ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਹਨ। ਕੁਝ ਸੈੱਟਅੱਪ ਵਿਕਾਸ ਦੌਰਾਨ ਤੇਜ਼ ਟ੍ਰਾਂਸਪਾਇਲ ਕਰਦੇ ਹਨ ਅਤੇ ਫੁਲ ਟਾਈਪ-ਚੈੱਕਿੰਗ ਅਲੱਗ ਚਲਾਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਫੀਡਬੈਕ ਤੇਜ਼ ਰਹਿੰਦਾ ਹੈ।
ਚਾਹੇ ਤੁਸੀਂ JavaScript ਚੁਣੋ ਜਾਂ TypeScript, ਟੀਮਾਂ ਅਕਸਰ ਸਕੈਫੋਲਡਿੰਗ, ਬਿਲਡ ਟੂਲਜ਼ ਨੂੰ ਵਾਇਰ ਕਰਨ, ਅਤੇ ਫਰੰਟਐਂਡ/ਬੈਕਐਂਡ ਸੰਮੇਟਕਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖਣ ਵਿੱਚ ਸਮਾਂ ਲਗਾਉਂਦੀਆਂ ਹਨ।
Koder.ai ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਇੱਕ ਚੈਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਵੈੱਬ, ਸਰਵਰ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਰਿਪੀਟੇਟਿਵ ਸੈਟਅੱਪ 'ਤੇ ਅਟਕੇ ਬਿਨਾਂ ਫੀਚਰਾਂ ਅਤੇ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਇਟਰੇਟ ਕਰ ਸਕੋ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਫਰੰਟਐਂਡ 'ਤੇ React, ਬੈਕਐਂਡ 'ਤੇ Go ਸੇਵਾਵਾਂ PostgreSQL ਨਾਲ, ਅਤੇ ਮੋਬਾਈਲ ਲਈ Flutter ਜਨਰੇਟ ਕਰਦਾ ਹੈ; ਇਹ ਸੋর্স ਕੋਡ ਐਕਸਪੋਰਟ, ਡਿਪਲੋਯਮੈਂਟ/ਹੋਸਟਿੰਗ, ਕਸਟਮ ਡੋਮੇਨ, snapshots, ਅਤੇ rollback ਨੂੰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ JS→TS ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ (ਜਾਂ ਨਵਾਂ ਪ੍ਰਾਜੈਕਟ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੋ), ਤਾਂ ਇਹ "ਪਲਾਨਿੰਗ ਮੋਡ + ਚੈਟ-ਚਲਤ ਸਕੈਫੋਲਡਿੰਗ" ਤੁਹਾਡੇ ਲਈ ਵਿਕਲਪਾਂ ਪਰਖਣ ਅਤੇ ਸਟਰੱਕਚਰ ਸੁਧਾਰਨ ਦੀ ਲਾਗਤ ਘਟਾ ਸਕਦੀ ਹੈ।
(ਜੇ ਤੁਸੀਂ Koder.ai ਬਾਰੇ ਸਮੱਗਰੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਉੱਥੇ ਇਕ earn-credits ਪ੍ਰੋਗਰਾਮ ਅਤੇ ਰੈਫਰਲ ਵੀ ਹਨ—ਲਾਭਦਾਇਕ ਜੇ ਤੁਸੀਂ ਆਪਣੀਆਂ ਮਾਈਗਰੇਸ਼ਨ ਰੀਸਰਚਾਂ ਦੀ ਡਾਕਮੀੂਮੇਨਟ ਕਰ ਰਹੇ ਹੋ.)
ਪੂਛਣਾ ਲੁਭਾਵਣਾ ਹੈ "ਕਿਹੜਾ ਤੇਜ਼ ਹੈ?" ਪਰ ਅਸਲ ਐਪਸ ਲਈ, JavaScript ਅਤੇ TypeScript ਆਮ ਤੌਰ 'ਤੇ ਲਗਭਗ ਇੱਕੋ ਜਿਹਾ ਦੌੜਦੇ ਹਨ। TypeScript ਸਧਾਰਨ JavaScript ਵਿੱਚ ਕੰਪਾਇਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਕੰਪਾਇਲਡ ਆਉਟਪੁਟ ਬ੍ਰਾਊਜ਼ਰ ਜਾਂ Node.js ਚਲਾਉਂਦਾ ਹੈ। ਇਸ ਲਈ ਰਨਟਾਈਮ ਪ੍ਰਦਰਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਕੋਡ ਅਤੇ ਰਨਟਾਈਮ (V8, ਬ੍ਰਾਊਜ਼ਰ ਇੰਜਣ) 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਤੁਸੀਂ .ts ਜਾਂ .js ਲਿਖਿਆ ਹੈ।
ਉਤਪਾਦਕਤਾ ਅਕਸਰ ਉਸ ਵੇਲੇ ਦਿੱਸਦੀ ਹੈ—ਜਦੋਂ ਤੁਸੀਂ ਕੋਡ ਲਿਖ ਰਹੇ ਹੋ ਅਤੇ ਬਦਲ ਰਹੇ ਹੋ।
TypeScript ਡਿਵੈਲਪਮੈਂਟ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਦੌਰਾਨ ਹੀ ਗਲਤੀਆਂ ਫੜ ਲੈਂਦਾ: ਗਲਤ ਕਿਸਮ ਦਾ ਆਰਗੁਮੈਂਟ, undefined ਨੂੰ ਹਾਂਡਲ ਨਾ ਕਰਨਾ, ਆਬਜੈਕਟ ਸ਼ੇਪ ਵਿੱਚ ਗ਼ਲਤੀਆਂ ਆਦਿ। ਇਹ ਰਿਫੈਕਟਰਿੰਗ ਨੂੰ ਵੀ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦਾ: ਫੀਲਡ ਦਾ ਨਾਮ ਬਦਲੋ, ਰਿਟਰਨ ਟਾਈਪ ਚੇਂਜ ਕਰੋ, ਜਾਂ ਮੋਡੀਊਲਾਂ ਨੂੰ ਦੁਬਾਰਾ ਆਰਗੇਨਾਈਜ਼ ਕਰੋ—ਤੁਹਾਡਾ ਐਡੀਟਰ/CI ਹਰ ਥਾਂ ਬਦਲੀ ਦੀ ਨੋਟਿਸ ਕਰ ਸਕਦਾ ਹੈ।
ਟਰੇਡ-ਆਫ overhead ਹੈ। ਤੁਸੀਂ ਹੋ ਸਕਦਾ ਹੈ ਵੱਧ ਕੋਡ ਲਿਖੋ (ਟਾਈਪਸ, ਇੰਟਰਫੇਸ, ਜੈਨੇਰਿਕਸ), ਪਹਿਲਾਂ ਤੋਂ ਸੋਚਣਾ ਪਵੇ, ਅਤੇ ਕਈ ਵਾਰ ਕੰਪਾਇਲਰ ਐਰਰਾਂ ਨਾਲ ਜੂਝਣਾ ਪਵੇ ਜੋ ਛੋਟੇ ਵਿਚਾਰਾਂ ਲਈ "ਜ਼ਿਆਦਾ ਸਖਤ" ਲੱਗ ਸਕਦੇ ਹਨ। ਛੋਟੀ ਸਕ੍ਰਿਪਟਾਂ ਜਾਂ ਪ੍ਰੋਟੋਟਾਈਪ ਲਈ, ਇਹ ਵਾਧੂ ਟਾਈਪਿੰਗ ਤੁਹਾਨੂੰ ਸੁਸਤ ਕਰ ਸਕਦੀ ਹੈ।
ਮੈਂਟੇਨਬਿਲਿਟੀ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਕਿਸੇ ਲਈ —ਜ਼ਿਆਦਾਤਰ ਭਵਿਖ ਦਾ ਤੁਸੀਂ—ਕੋਡ ਨੂੰ ਸਮਝਣਾ ਅਤੇ ਬਦਲਣਾ ਕਿੰਨਾ ਆਸਾਨ ਹੈ ਬਿਨਾਂ ਤੋੜ پھੋਕ ਕਰਨ ਦੇ।
ਲੰਮੇ ਸਮੇਂ ਵਾਲੇ ਐਪ ਲਈ, TypeScript ਅਕਸਰ ਜਿੱਤਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਮਕਸਦ ਨੂੰ ਏਨਕੋਡ ਕਰਦਾ ਹੈ: ਇੱਕ ਫੰਕਸ਼ਨ ਕੀ ਮੰਗਦਾ ਹੈ, ਕੀ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੀ ਮਨਜ਼ੂਰ ਹੈ। ਇਹ ਖਾਸ ਕਰਕੇ ਕੀਮਤੀ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਫਾਇਲਾਂ ਵੱਧਦੀਆਂ ਹਨ, ਫੀਚਰ ਸਟੈਕ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਏਜ ਕੇਸ ਵਧਦੇ ਹਨ।
ਸੋਲੋ ਡੈਵਲਪਰਾਂ ਲਈ, JavaScript ਆਈਡੀਆ ਤੋਂ ਆઉਟਪੁੱਟ ਤਕ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਹੋ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਕੋਡਬੇਸ ਛੋਟਾ ਹੋਵੇ ਅਤੇ ਬਦਲਾਵ ਅਕਸਰ ਹੁੰਦੇ ਹਨ।
ਬਹੁ-ਚਲਕ ਟੀਮਾਂ (ਜਾਂ ਕਈ ਟੀਮਾਂ) ਲਈ, TypeScript ਅਕਸਰ ਆਪਣੀ ਲਾਗਤ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਸਾਫ਼ ਟਾਈਪਸ "ਟ੍ਰਾਇਬਲ ਨોલেজ" ਘਟਾਉਂਦੀਆਂ ਹਨ, ਕੋਡ ਰਿਵਿュー ਸਹੀ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਮੁੱਦੇ ਘੱਟ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਵੱਖ-ਵੱਖ ਲੋਕ ਇੱਕੋ ਮੋਡੀਊਲ ਨੂੰ ਛੂਹਦੇ ਹਨ।
TypeScript ਚੰਗਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਗਾਰਡਰੇਲ ਚਾਹੁੰਦੇ ਹੋ, ਪਰ ਸਧਾਰਣ JavaScript ਅਜੇ ਵੀ ਬਹੁਤ ਸਥਿਤੀਆਂ ਵਿੱਚ ਠੀਕ ਟੂਲ ਹੈ। ਮੁੱਖ ਸਵਾਲ ਇਹ ਨਹੀਂ ਹੈ "ਕਿਹੜਾ ਵਧੀਆ ਹੈ?"—ਇਹ ਹੈ "ਇਸ ਪ੍ਰਾਜੈਕਟ ਨੂੰ ਹੁਣ ਕੀ ਚਾਹੀਦਾ ਹੈ?"
ਜੇ ਤੁਸੀਂ ਅਜ਼ਮਾਈਸ਼ ਲਈ ਇੱਕ ਛੋਟੀ ਸਕ੍ਰਿਪਟ ਬਣਾ ਰਹੇ ਹੋ, ਫਾਈਲਾਂ ਦੇ ਨਾਮ ਬਦਲਣ ਲਈ ਜਾਂ API ਆਈਡੀਆ ਦੀ ਜਾਂਚ ਲਈ, JavaScript ਫੀਡਬੈਕ ਲੂਪ ਤਿੱਖਾ ਰੱਖਦਾ ਹੈ। ਤੁਸੀਂ Node.js ਨਾਲ ਤੁਰੰਤ ਚਲਾ ਸਕਦੇ ਹੋ, ਇੱਕ ਸਿੰਗਲ ਫਾਇਲ ਸਾਂਝੀ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਅੱਗੇ ਵੱਧ ਸਕਦੇ ਹੋ।
ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਡੈਮੋ ਐਪਸ ਲਈ যা हो ਸਕਦਾ है कि ਮੁੜ ਲਿਖ ਦਿੱਤੇ ਜਾਣ ਜਾਂ ਬੰਦ ਕਰ ਦਿੱਤੇ ਜਾਣ, ਟਾਈਪਸ ਸਕਿੱਪ ਕਰਨਾ ਸਮਝੌਤਾ ਹੋ ਸਕਦਾ ਹੈ। ਮਕਸਦ ਸਿੱਖਣਾ ਅਤੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਲੰਮੀ ਅਵਧੀ ਰਖ-ਚਾਲ।
ਜਦੋਂ ਕੋਈ ਨਵਾਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਸਿੱਖ ਰਿਹਾ ਹੋਵੇ ਜਾਂ ਨਵਾਂ ਵੈੱਬ ਸਿੱਖ ਰਿਹਾ ਹੋਵੇ, JavaScript ਸਿੱਖਣ ਤੇ ਮਾਨਸਿਕ ਭਾਰ ਘਟਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਮੁੱਖ ਅਵਧਾਰਣਾਂ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹੋ—ਵੈਰੀਏਬਲ, ਫੰਕਸ਼ਨ, async/await, DOM ਘਟਨਾ—ਬਿਨਾਂ ਟਾਈਪ ਐਨੋਟੇਸ਼ਨ, ਜੈਨੇਰਿਕਸ ਅਤੇ ਬਿਲਡ ਕੰਫਿਗ ਵੀ ਸਿੱਖਣ ਦੇ।
ਜੇ ਤੁਸੀਂ ਮੈਨਟਰਿੰਗ ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਸਿਖਾ ਰਹੇ ਹੋ, JavaScript ਇੱਕ ਸਾਫ਼ ਸ਼ੁਰੂਆਤ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ TypeScript ਇੱਕ "ਅਗਲਾ ਪੱਧਰ" ਵਜੋਂ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਕੁਝ ਲਾਇਬ੍ਰੇਰੀਆਂ ਜਾਣ-ਬੂਝ ਕੇ ਛੋਟੀ ਅਤੇ ਪਰਮਿਸਿਵ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਉਹ ਯੂਟਿਲਿਟੀਜ਼ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਈ ਮਾਹੌਲਾਂ ਵਿੱਚ ਡ੍ਰਾਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, JavaScript ਪਬਲਿਸ਼ ਅਤੇ ਉਪਭੋਗ ਲਈ ਸਧਾਰਨ ਹੋ ਸਕਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ API ਸਰਫੇਸ ਛੋਟਾ ਹੋ ਅਤੇ ਪਰੈਟਤਾ ਅਤੇ ਟੈਸਟ ਮਜ਼ਬੂਤ ਹੋ।
(ਤੁਸੀਂ ਫਿਰ ਵੀ TypeScript ਟਾਈਪਿੰਗ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਜਰੂਰੀ ਨਹੀਂ ਕਿ ਇਹ ਮੂਲ ਸੋਰਸ ਭਾਸ਼ਾ ਹੋਵੇ.)
TypeScript ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਕੰਪਾਇਲੇਸ਼ਨ ਕਦਮ ਜੋੜਦਾ ਹੈ (ਭਾਵੇਂ ਤੇਜ਼ ਹੋਵੇ)। ਸਧਾਰਨ ਇੰਬੇਡਸ—ਜਿਵੇਂ ਵਿਜਟ ਸਨੀਪਟ, ਬੁਕਮਾਰਕਲੈਟ, ਜਾਂ CMS ਵਿੱਚ ਪਾਈ ਜਾਂਦੀ ਛੋਟੀ ਸਕ੍ਰਿਪਟ—ਲਈ JavaScript ਅਕਸਰ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇੱਕ ਫਾਇਲ ਨਿੱਕਲਕੇ ਬਿਨਾਂ ਕਿਸੇ ਟੂਲਿੰਗ ਦੇ ਚਲਾ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਹਾਡੀਆਂ ਸ਼ਰਤਾਂ "ਕਾਪੀ/ਪੇਸਟ ਅਤੇ ਇਹ ਕੰਮ ਕਰੇ" ਹਨ, ਤਾਂ ਪ੍ਰੈਕਟਿਕਲ ਤੌਰ 'ਤੇ JavaScript ਜਿੱਤਦਾ ਹੈ।
JavaScript ਚੁਣੋ ਜਦੋਂ ਐਕਸਪੈਰੀਮੈਂਟਸ਼ੀ ਹਸਤੀ, ਜ਼ੀਰੋ-ਕਾਨਫਿਗ ਡਿਲਿਵਰੀ, ਜਾਂ ਵਿਆਪਕ ਅਨੁਕੂਲਤਾ ਲੰਮੀ-ਅਵਧੀ ਗਾਰੰਟੀ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ। ਜੇ ਕੋਡ ਮਹੀਨਿਆਂ ਜਾਂ ਸਾਲਾਂ ਲਈ ਰਹੇਗਾ ਅਤੇ ਟੀਮ ਵੱਲੋਂ ਵਿਕਸਿਤ ਹੋਏਗਾ, TypeScript ਅਕਸਰ ਉਹ upfront ਲਾਗਤ ਵਾਪਸ ਕਰਦਾ ਹੈ—ਪਰ ਛੋਟੇ, ਸਾਦੇ ਕੰਮਾਂ ਲਈ JavaScript ਇੱਕ ਫ਼ਿਕਸ ਵਿਕਲਪ ਰਹਿੰਦਾ ਹੈ।
TypeScript ਉਹ ਸਮੇਂ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡਾ ਕੋਡਬੇਸ ਕਾਫ਼ੀ ਮੁੜ-ਬਦਲ ਹੁੰਦਾ ਹੈ ਅਤੇ "ਯਾਦ ਰਹਿਣਾ ਕਿ ਕੀ ਕਿੱਥੇ ਜਾ ਰਿਹਾ ਹੈ" ਇਕ ਅਸਲ ਲਾਗਤ ਬਣ ਜਾਂਦੀ ਹੈ। ਇਹ JavaScript ਉੱਤੇ ਇਕ ਚੈਕਡ ਸਟ੍ਰਕਚਰ ਦੀ ਪਰਤ ਜੋੜਦਾ ਹੈ, ਜੋ ਟੀਮਾਂ ਨੂੰ ਟੈਸਟਿੰਗ ਉੱਤੇ ਹੀ ਨਿਰਭਰ ਹੋਏ ਬਿਨਾਂ ਭਰੋਸੇ ਨਾਲ ਕੋਡ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਜਦੋਂ ਕਈ ਲੋਕ ਇੱਕੋ ਫੀਚਰ ਨੂੰ ਛੂਹਦੇ ਹਨ, ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਅਕਸਮਾਤ ਤੌਰ 'ਤੇ ਬ੍ਰੇਕ ਹੋਣਾ ਹੈ: ਫੰਕਸ਼ਨ ਸਿਗਨੇਚਰ ਬਦਲਣਾ, ਫੀਲਡ ਦਾ ਨਾਮ ਬਦਲਣਾ, ਜਾਂ ਕਿਸੇ ਵੈਲਿਊ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣਾ। TypeScript ਉਹ ਗਲਤੀਆਂ ਤੁਹਾਡੇ ਕੋਡ ਲਿਖਦੇ ਸਮੇਂ ਹੀ ਦਰਸਾ ਦੇਂਦਾ ਹੈ, ਤਾਂ ਟੀਮ ਨੂੰ "QA ਦੀ ਉਡੀਕ" ਜਾਂ "ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਪਤਾ ਲੱਗਣ" ਵਾਲੀ ਰਵਾਇਤ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਫੀਡਬੈਕ ਮਿਲਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਪ੍ਰੋਡਕਟ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਸਿਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅਕਸਰ ਕੋਡ ਨੂੰ ਰਿਫੈਕਟਰ ਕਰੋਗੇ: ਲੌਜਿਕ ਨੂੰ ਫਾਇਲਾਂ ਵਿਚੋਂ ਹਟਾਉਣਾ, ਮੋਡੀਊਲਾਂ ਨੂੰ ਵੰਡਣਾ, ਰੀਯੂਜ਼ਬਲ ਯੂਟਿਲਿਟੀਜ਼ ਨਿਕਾਲਣਾ। TypeScript ਤੁਹਾਨੂੰ ਗਾਰਡਰੇਲ ਦਿੰਦਾ—ਆਪਣਾ ਐਡੀਟਰ ਅਤੇ ਕੰਪਾਇਲਰ ਉਹ ਸਾਰੀਆਂ ਥਾਂਆਂ ਦੱਸ ਸਕਦੇ ਹਨ ਜਿਹਨਾਂ ਨੂੰ ਬਦਲਣਾ ਲੋੜੀਂਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ ਉਹਨਾਂ ਥਾਂਵਾਂ ਨੂੰ ਜੋ ਤੁਸੀਂ ਯਾਦ ਰੱਖਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਫਰੰਟਐਂਡ ਅਤੇ Node.js ਬੈਕਐਂਡ ਵਿਚ ਟਾਈਪਸ ਜਾਂ ਯੂਟਿਲਿਟੀਜ਼ ਸਾਂਝੇ ਕਰਦੇ ਹੋ, TypeScript ਅਣ-ਮੇਲ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, date string ਵਿਰੁੱਧ timestamp, ਜਾਂ ਲਾਪਤਾ ਫੀਲਡ)। ਸਾਂਝੇ typed ਮਾਡਲ API request/response ਸ਼ੇਪਜ਼ ਨੂੰ ਇਕਸਾਰ ਰੱਖਣੇ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ API client ਜਾਂ SDK ਪਬਲਿਸ਼ ਕਰਦੇ ਹੋ, TypeScript ਉਪਭੋਗੀ ਅਨੁਭਵ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਉਪਭੋਗਤਿਆਂ ਨੂੰ autocomplete, ਸਪਸ਼ਟ ਡੌਕਸ, ਅਤੇ ਪਹਿਲਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਮਿਲਦੀਆਂ ਹਨ। ਇਸਦਾ ਸਿੱਧਾ ਨਤੀਜਾ ਘੱਟ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਮੁੱਦੇ ਅਤੇ ਘੱਟ ਸਪੋਰਟ ਟਿਕਟਸ ਹੁੰਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ TypeScript ਵੱਲ ਝੁਕ ਰਹੇ ਹੋ, ਅਗਲਾ ਪ੍ਰੈਕਟਿਕਲ ਸਵਾਲ ਹੈ ਕਿ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਲਿਆਂਦਾ ਜਾਵੇ—ਵਖ-ਵਖ ਵਿਕਲਪਾਂ ਲਈ ਦੇਖੋ /blog/migrating-from-javascript-to-typescript-without-disruption.
TypeScript "ਸਿਰਫ JavaScript ਟਾਈਪਸ ਨਾਲ" ਨਹੀਂ ਹੈ, ਪਰ ਸਿੱਖਣ ਦੀ ਰੁਕਾਵਟ ਅਸਲ ਵਿੱਚ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਕੋਡ ਬਾਰੇ ਇੱਕ ਨਵਾਂ ਸੋਚ-ਤਰੀਕਾ ਸਿੱਖ ਰਹੇ ਹੋ। ਜ਼ਿਆਦਾਤਰ ਰੁਕਾਵਟ ਕੁਝ ਵਿਸ਼ੇਸ਼ ਫੀਚਰਾਂ ਅਤੇ ਕੰਪਾਇਲਰ ਸੈਟਿੰਗਜ਼ ਤੋਂ ਆਉਂਦੀ ਹੈ ਜੋ ਸ਼ੁਰੂ ਵਿੱਚ ਸਖਤ ਲੱਗ ਸਕਦੀਆਂ ਹਨ।
ਯੂਨੀਅਨਾਂ ਅਤੇ ਨੈਰੋਇੰਗ ਕਈ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰ ਦਿੰਦੇ ਹਨ। string | null ਵਾਲੀ ਵੈਲਿਊ ਤੱਕ ਇਹ ਸਿੱਧਾ string ਨਹੀਂ ਹੁੰਦੀ ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਸਾਬਤ ਨਾ ਕਰੋ। ਇਸ ਲਈ ਤੁਸੀਂ ਬਹੁਤ ਜਗ੍ਹਾਂ if (value) { ... } ਜਾਂ if (value !== null) { ... } ਵਰਗੇ ਪੈਟਰਨ ਦੇਖੋਗੇ।
ਜੈਨੇਰਿਕਸ ਦੂਜਾ ਵੱਡਾ ਚੈਲੈਂਜ ਹੈ। ਇਹ ਤਾਕਤਵਰ ਹਨ, ਪਰ ਸ਼ੁਰੂ ਵਿੱਚ ਉਨਾਂ ਨੂੰ ਵੱਧ ਵਰਤਣਾ ਔਖਾ ਹੋ ਸਕਦਾ ਹੈ। ਪਹਿਲਾਂ ਲਾਇਬ੍ਰੇਰੀਜ਼ ਵਿੱਚ ਉਨਾਂ ਨੂੰ ਪਛਾਣੋ (Array<T>, Promise<T>) ਫਿਰ ਆਪਣੀਆਂ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ।
ਕੰਫਿਗਰেশন ਵੀ ਕਨਫਿਊਜ਼ਿੰਗ ਹੋ ਸਕਦੀ ਹੈ। tsconfig.json ਵਿੱਚ bahut ਸਾਰੇ ਵਿਕਲਪ ਹਨ, ਅਤੇ ਕੁਝ ਤੁਹਾਡੇ ਰੋਜ਼ਾਨਾ ਤਜ਼ੁਰਬੇ ਨੂੰ ਬਹੁਤ ਬਦਲ ਦਿੰਦੇ ਹਨ।
"strict": true ਚਾਲੂ ਕਰਨ ਨਾਲ ਅਕਸਰ ਇੱਕ ਲਹਿਰ of errors ਆਉਂਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ any, null/undefined, ਅਤੇ ਆਦਿ ਆਧਾਰ ਤੇ implicit ਟਾਈਪਸ ਦੇ ਆਸਪਾਸ। ਇਹ ਹੌਂਸਲਾ ਟੋਟਦਾ ਹੋ ਸਕਦਾ ਹੈ।
ਪਰ strict mode ਹੀ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ TypeScript ਆਪਣਾ ਲਾਭ ਦਿਖਾਉਂਦਾ ਹੈ: ਇਹ ਤੁਹਾਨੂੰ edge-case ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਹેન્ડਲ ਕਰਨ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਬੱਗਾਂ ਰੋਕਦਾ ਹੈ ਜੋ "ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ" ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਪ੍ਰੈਕਟਿਕਲ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਨਵੇਂ ਫਾਇਲਾਂ ਵਿੱਚ ਪਹਿਲਾਂ strict ਚਾਲੂ ਕਰੋ, ਫਿਰ ਫੈਲਾਓ।
TypeScript ਦੀ ਟਾਈਪ ਇੰਫਰੈਂਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਨਾਰਮਲ JavaScript ਲਿਖੋ, ਐਡੀਟਰ ਨੂੰ ਟਾਈਪਸ ਅਨੁਮਾਨ ਕਰਨ ਦਿਓ, ਅਤੇ ਸਿਰਫ ਜਿੱਥੇ ਕੋਡ ਅਸਪਸ਼ਟ ਹੈ ਉਥੇ ਐਨੋਟੇਸ਼ਨ ਜੋੜੋ।
ਟਾਈਪਸ ਧੀਰੇ-ਧੀਰੇ ਜੋੜੋ:
typeof, in, Array.isArray) 'ਤੇ ਨਿਰਭਰ ਰੱਖੋਦੋ ਕਲਾਸਿਕ ਜਾਲ:
as any ਵਰਤ ਕੇ "ਐਰਰਾਂ ਦੂਰ ਕਰਨਾ" ਬਜਾਏ ਮੂਲ ਧਾਰਣਾ ਨੂੰ ਠੀਕ ਕਰਨਾਜੇ TypeScript ਸਖਤ ਲੱਗ ਰਿਹਾ ਹੈ, ਅਕਸਰ ਇਹ ਤੁਹਾਡੇ ਕੋਡ ਵਿੱਚ ਇੱਕ ਅਣਿਸ਼ਚਿਤਤਾ 'ਤੇ ਇਸ਼ਾਰਾ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ—ਉਸ ਅਣਿਸ਼ਚਿਤਤਾ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਣਾ ਮੁੱਖ ਹੁਨਰ ਹੈ।
ਤੁਹਾਨੂੰ TypeScript ਅਪਨਾਉਣ ਲਈ "ਦੁਨੀਆ ਰੋਕਣ" ਦੀ ਲੋੜ ਨਹੀਂ। ਸਭ ਤੋਂ ਚੰਗੀ ਮਾਈਗ੍ਰੇਸ਼ਨ TypeScript ਨੂੰ ਇਕ ਅੱਪਗਰੇਡ ਰਸਤਾ ਮੰਨਦੀ ਹੈ, ਨਾ ਕਿ ਇਕ ਰੀਰਾਈਟ।
TypeScript ਮੌਜੂਦਾ JavaScript ਦੇ ਨਾਲ ਰਹਿ ਸਕਦਾ ਹੈ। ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਕੰਫਿਗਰ ਕਰੋ ਕਿ .js ਅਤੇ .ts ਫਾਇਲਾਂ ਇਕੱਠੇ ਰਹਿ ਸਕਣ, ਫਿਰ ਜਦੋਂ-ਜਦ ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਛੂਹਦੇ ਹੋ ਫਾਇਲ-ਬਾਈ-ਫਾਇਲ ਕੋਨਵਰਟ ਕਰੋ। ਬਹੁਤੀਆਂ ਟੀਮਾਂ allowJs ਅਤੇ checkJs ਨੂੰ ਸੇਲੇਕਟਿਵ ਤਰੀਕੇ ਨਾਲ ਚਾਲੂ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਤੁਸੀਂ ਪੂਰੇ ਰੀਫੈਕਟਰ ਤੋਂ ਬਿਨਾਂ ਸ਼ੁਰੂਆਤੀ ਫੀਡਬੈਕ ਲੈ ਸਕੋ।
ਇਕ ਪ੍ਰੈਕਟਿਕਲ ਨਿਯਮ: ਨਵੇਂ ਮੋਡੀਊਲ TypeScript ਵਿੱਚ ਹੋਣ। ਮੌਜੂਦਾ ਮੋਡੀਊਲ ਜਦ ਤੱਕ ਬਦਲਾਅ ਦੀ ਲੋੜ ਨਾ ਹੋ, ਉਹ ਅਜੇ ਵੀ ਜਿਵੇਂ ਹਨ ਰੱਖੋ। ਇਸ ਨਾਲ ਲੰਮੀ-ਅਵਧੀ ਰਖ-ਚਾਲ 'ਤੇ ਤੁਰੰਤ ਸੁਧਾਰ ਮਿਲਦਾ ਹੈ ਕਿਉਂਕਿ ਜੋ ਕੋਡ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਵੱਧੇਗਾ (ਨਵੀਂ ਫੀਚਰ) ਉਸਨੂੰ ਪਹਿਲਾਂ ਟਾਈਪ ਮਿਲਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਲੋਕਪ੍ਰਿਯ ਪੈਕੇਜ ਪਹਿਲਾਂ ਹੀ TypeScript ਟਾਈਪਸ ਦੇ ਸਾਥ ਆਉਂਦੇ ਹਨ। ਜੇ ਕਿਸੇ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਨਹੀਂ ਹਨ, ਤਾਂ community-maintained definitions (@types/...) ਵੇਖੋ। ਜਦ ਕੋਈ ਮਿਲਦਾ ਨਹੀਂ, ਤੁਸੀਂ:
ਤੁਸੀਂ ਕਦੇ-ਕਦੇ ਤੁਰੰਤ ਅੱਗੇ ਵਧਣ ਲਈ ਟਾਈਪ ਸਿਸਟਮ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦੀ ਲੋੜ ਪਏਗੀ:
unknown any ਨਾਲੋਂ ਸੁਰੱਖਿਅਤ ਹੈ ਕਿਉਂਕਿ ਇਹ ਵਰਤੋਂ ਤੋਂ ਪਹਿਲਾਂ ਚੈੱਕ ਮੰਗਦਾ ਹੈਮਕਸਦ ਦਿੰਨ-ਇੱਕ ਨਹੀਂ—ਦਿਨ ਇੱਕ unsafe ਸਥਾਨ ਨੂੰ ਦਿਸ਼ਾ-ਦਰਸ਼ਿਤ ਅਤੇ ਸੀਮਤ ਬਣਾਉਣਾ ਹੈ।
ਇੱਕ ਵਾਰੀ TypeScript ਜੁੜ ਜਾਵੇ, ਨਿਵੇਸ਼ ਦੀ ਰੱਖਿਆ ਕਰੋ:
any ਅਤੇ unsafe assertions ਨੂੰ ਘਟਾਉਣ ਲਈ lint ਨਿਯਮਚੰਗੀ ਤਰਾਂ ਕੀਤੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਇੰਕ੍ਰਿਮੈਂਟਲ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ: ਹਰ ਹਫ਼ਤੇ ਕੋਡਬੇਸ ਦਾ ਇਕ ਥੋੜਾ ਹਿੱਸਾ ਆਸਾਨੀ ਨਾਲ ਨੈਵੀਗੇਟ ਕਰਨ, ਰਿਫੈਕਟਰ ਕਰਨ, ਅਤੇ ਭਰੋਸੇ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਯੋਗ ਬਣ ਜਾਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਅਜੇ ਵੀ ਸ਼ੱਕ ਵਿੱਚ ਹੋ, ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਹਕੀਕਤਾਂ 'ਤੇ ਅਧਾਰਿਤ ਫੈਸਲਾ ਕਰੋ—ਬਜੱਸਟਕ। ਹੇਠਾਂ ਦਿੱਤੇ ਚੈੱਕਲਿਸਟ ਨਾਲ ਇਕ ਛੋਟਾ ਖਤਰਾ-ਸਕੈਨ ਕਰੋ, ਫਿਰ ਰਸਤਾ (JavaScript, TypeScript, ਜਾਂ ਹਾਈਬ੍ਰਿਡ) ਚੁਣੋ।
ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ:
ਇੱਕ ਨਿਯਮ-ਓਫ-ਥੰਬ: ਜਿਤਨਾ ਵੱਡਾ ਕੋਡਬੇਸ ਅਤੇ ਜਿਤਨੇ ਜ਼ਿਆਦਾ ਲੋਕ ਸ਼ਾਮਿਲ, TypeScript ਉਹਨਾ ਵਿੱਚ ਵੱਧ ਲਾਭ ਦਿਖਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸਹਾਇਤਾ ਚਾਹੁੰਦੇ ਹੋ ਠੀਕ ਸੈਟਅੱਪ ਚੁਣਨ ਅਤੇ ਲਾਗੂ ਕਰਨ ਵਿੱਚ (JS, TS, ਜਾਂ ਹਾਈਬ੍ਰਿਡ), ਤਾਂ ਸਾਡੇ ਯੋਜਨਾਵਾਂ ਵੇਖੋ /pricing.