ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ

ਸਮੱਗਰੀ:

• ਸਾਰ
  • ਮੁੱਦਾ
  • ਫੈਸਲਾ
  • ਸਥਿਤੀ
• ਵੇਰਵੇ
  • ਧਾਰਨਾਵਾਂ
  • ਬੰਦਸ਼ਾਂ
  • ਪੱਖ
  • ਦਲੀਲ
  • ਪ੍ਰਭਾਵ
• ਸੰਬੰਧਿਤ
  • ਸੰਬੰਧਿਤ ਫੈਸਲੇ
  • ਸੰਬੰਧਿਤ ਲੋੜਾਂ
  • ਸੰਬੰਧਿਤ ਕਲਾਕ੍ਰਿਤੀਆਂ
  • ਸੰਬੰਧਿਤ ਸਿਧਾਂਤ
• ਨੋਟ

ਸਾਰ

ਮੁੱਦਾ

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

ਫੈਸਲਾ

ਅਸੀਂ ਫਰੰਟ-ਐਂਡ ਲਈ TypeScript ਚੁਣ ਰਹੇ ਹਾਂ।

ਅਸੀਂ ਬੈਕ-ਐਂਡ ਲਈ Rust ਚੁਣ ਰਹੇ ਹਾਂ।

ਸਥਿਤੀ

ਤੈਅ ਹੋਇਆ। ਨਵੇਂ ਵਿਕਲਪ ਸਾਹਮਣੇ ਆਉਣ ਉੱਤੇ ਅਸੀਂ ਉਨ੍ਹਾਂ ਲਈ ਖੁੱਲ੍ਹੇ ਹਾਂ।

ਵੇਰਵੇ

ਧਾਰਨਾਵਾਂ

ਫਰੰਟ-ਐਂਡ ਐਪਲੀਕੇਸ਼ਨਾਂ ਆਮ ਹਨ:

• ਆਮ ਵਰਤੋਂਕਾਰ ਅਤੇ ਆਪਸੀ ਕਿਰਿਆਵਾਂ

• ਆਮ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਸਿਸਟਮ

• ਆਮ ਵਿਕਾਸ ਅਤੇ ਡਿਪਲਾਇਮੈਂਟ

ਫਰੰਟ-ਐਂਡ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਸਿਤ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ:

• ਅਸੀਂ ਤੇਜ਼ ਅਤੇ ਆਸਾਨ ਵਿਕਾਸ, ਡਿਪਲਾਇਮੈਂਟ, ਦੁਹਰਾਓ ਆਦਿ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ।

• ਅਸੀਂ ਸਾਬਤ ਹੋ ਸਕਣ ਦੀ ਯੋਗਤਾ, ਜਿਵੇਂ ਕਿ ਕਿਸਮ ਸੁਰੱਖਿਆ, ਦੀ ਕਦਰ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਇਸ ਨੂੰ ਹਾਸਲ ਕਰਨ ਲਈ ਥੋੜ੍ਹਾ ਵਧੇਰੇ ਕੰਮ ਕਰਨ ਵਿੱਚ ਸਾਨੂੰ ਕੋਈ ਇਤਰਾਜ਼ ਨਹੀਂ।

• ਸਾਨੂੰ ਪੁਰਾਣੇ ਸਿਸਟਮਾਂ ਨਾਲ ਅਨੁਕੂਲਤਾ ਦੀ ਲੋੜ ਨਹੀਂ।

ਬੈਕ-ਐਂਡ ਐਪਲੀਕੇਸ਼ਨਾਂ ਆਮ ਨਾਲੋਂ ਉੱਚੇ ਪੱਧਰ ਦੀਆਂ ਹਨ:

• ਗੁਣਵੱਤਾ ਲਈ ਆਮ ਨਾਲੋਂ ਉੱਚੇ ਟੀਚੇ, ਖਾਸ ਕਰਕੇ ਸਾਬਤ ਹੋ ਸਕਣ ਦੀ ਯੋਗਤਾ, ਭਰੋਸੇਯੋਗਤਾ, ਸੁਰੱਖਿਆ ਆਦਿ।

• ਲਗਭਗ-ਰੀਅਲ-ਟਾਈਮ ਲਈ ਆਮ ਨਾਲੋਂ ਉੱਚੇ ਟੀਚੇ, ਯਾਨੀ ਅਸੀਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੀ ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ ਕਾਰਨ ਰੁਕਾਵਟਾਂ ਨਹੀਂ ਚਾਹੁੰਦੇ।

• ਫੰਕਸ਼ਨਲ ਪ੍ਰੋਗਰਾਮਿੰਗ ਲਈ ਆਮ ਨਾਲੋਂ ਉੱਚੇ ਟੀਚੇ, ਖਾਸ ਕਰਕੇ ਸਮਾਂਤਰੀਕਰਨ, ਮਲਟੀ-ਕੋਰ ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਮੈਮਰੀ ਸੁਰੱਖਿਆ ਲਈ।

ਅਸੀਂ ਕੰਪਾਇਲ-ਸਮੇਂ ਦੀ ਸੁਰੱਖਿਆ ਅਤੇ ਰਨਟਾਈਮ ਦੀ ਗਤੀ ਦੇ ਹੱਕ ਵਿੱਚ ਘੱਟ ਕੰਪਾਇਲ-ਸਮੇਂ ਦੀ ਗਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੇ ਹਾਂ।

ਬੰਦਸ਼ਾਂ

ਸਾਡੇ ਉੱਤੇ ਉਨ੍ਹਾਂ ਭਾਸ਼ਾਵਾਂ ਬਾਰੇ ਮਜ਼ਬੂਤ ਬੰਦਸ਼ ਹੈ ਜੋ Amazon Lambda ਵਰਗੇ ਫੰਕਸ਼ਨਾਂ ਲਈ ਪ੍ਰਮੁੱਖ ਕਲਾਊਡ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀਆਂ ਸੇਵਾਵਾਂ ਨਾਲ ਵਰਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।

ਪੱਖ

ਅਸੀਂ ਇਨ੍ਹਾਂ ਭਾਸ਼ਾਵਾਂ ਬਾਰੇ ਵਿਚਾਰ ਕੀਤਾ:

• C

• C++

• Clojure

• Elixir

• Erlang

• Elm

• Flow

• Go

• Haskell

• Java

• JavaScript

• Kotlin

• Python

• Ruby

• Rust

• TypeScript

ਦਲੀਲ

ਹਰ ਭਾਸ਼ਾ ਦਾ ਸਾਰ:

• C: ਘੱਟ ਸੁਰੱਖਿਆ ਕਾਰਨ ਰੱਦ ਕੀਤੀ; Rust ਲਗਭਗ ਹਰ ਚੀਜ਼ ਬਿਹਤਰ ਕਰ ਸਕਦੀ ਹੈ।

• C++: ਇਹ ਗੜਬੜ ਵਾਲੀ ਹੋਣ ਕਾਰਨ ਰੱਦ ਕੀਤੀ; Rust ਲਗਭਗ ਹਰ ਚੀਜ਼ ਬਿਹਤਰ ਕਰ ਸਕਦੀ ਹੈ।

• Clojure: ਸ਼ਾਨਦਾਰ ਮਾਡਲਿੰਗ; ਸਭ ਤੋਂ ਵਧੀਆ Lisp ਨਜ਼ਦੀਕੀ; JVM ਉੱਤੇ ਬਹੁਤ ਵਧੀਆ ਰਨਟਾਈਮ।

• Elixir: ਡਿਪਲਾਇ ਕਰਨ ਦੀ ਯੋਗਤਾ ਅਤੇ ਸਮਕਾਲੀਪਣ ਸਮੇਤ ਸ਼ਾਨਦਾਰ ਰਨਟਾਈਮ; ਸ਼ਾਨਦਾਰ ਡਿਵੈਲਪਰ ਤਜਰਬਾ; ਮੁਕਾਬਲਤਨ ਛੋਟਾ ਈਕੋਸਿਸਟਮ।

• Erlang: ਡਿਪਲਾਇ ਕਰਨ ਦੀ ਯੋਗਤਾ ਅਤੇ ਸਮਕਾਲੀਪਣ ਸਮੇਤ ਸ਼ਾਨਦਾਰ ਰਨਟਾਈਮ; ਚੁਣੌਤੀਪੂਰਨ ਡਿਵੈਲਪਰ ਤਜਰਬਾ; ਮੁਕਾਬਲਤਨ ਛੋਟਾ ਈਕੋਸਿਸਟਮ।

• Elm: ਬਹੁਤ ਹੋਨਹਾਰ ਲੱਗਦੀ ਹੈ; IBM ਚੰਗੇ ਨਤੀਜਿਆਂ ਵਾਲੇ ਵੱਡੇ ਕੇਸ ਅਧਿਐਨ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਰਿਹਾ ਹੈ; ਛੋਟਾ ਈਕੋਸਿਸਟਮ।

• Flow: JavaScript ਉੱਤੇ ਦਿਲਚਸਪ ਸੁਧਾਰ; ਫਿਰ ਵੀ; ਡਿਵੈਲਪਰ ਇਸ ਤੋਂ ਦੂਰ ਜਾ ਰਹੇ ਹਨ।

• Go: ਸ਼ਾਨਦਾਰ ਡਿਵੈਲਪਰ ਤਜਰਬਾ; ਸ਼ਾਨਦਾਰ ਸਮਕਾਲੀਪਣ; ਪਰ ਮਾੜੇ ਫੈਸਲਿਆਂ ਦਾ ਇਤਿਹਾਸ ਜੋ ਭਾਸ਼ਾ ਨੂੰ ਅਪਾਹਜ ਕਰ ਦਿੰਦਾ ਹੈ।

• Haskell: ਸਭ ਤੋਂ ਵਧੀਆ ਫੰਕਸ਼ਨਲ ਭਾਸ਼ਾ; ਛੋਟਾ ਡਿਵੈਲਪਰ ਭਾਈਚਾਰਾ; ਪ੍ਰਕਾਸ਼ਿਤ ਉਤਪਾਦਨ ਸਫਲਤਾਵਾਂ ਕਾਫ਼ੀ ਹਾਸਲ ਨਹੀਂ ਕੀਤੀਆਂ।

• Java: ਸ਼ਾਨਦਾਰ ਰਨਟਾਈਮ; ਸ਼ਾਨਦਾਰ ਈਕੋਸਿਸਟਮ; ਔਸਤ ਤੋਂ ਹੇਠਾਂ ਡਿਵੈਲਪਰ ਤਜਰਬਾ।

• JavaScript: ਹੁਣ ਤੱਕ ਦੀ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਭਾਸ਼ਾ; ਸਭ ਤੋਂ ਵਿਆਪਕ ਈਕੋਸਿਸਟਮ।

• Kotlin: Java ਦਾ ਬਹੁਤ ਕੁਝ ਠੀਕ ਕਰਦੀ ਹੈ; JetBrains ਵੱਲੋਂ ਸ਼ਾਨਦਾਰ ਸਮਰਥਨ; Java ਤੋਂ Kotlin ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਦੇ ਚੰਗੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕੇਸ।

• Python: ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਨ ਲਈ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਭਾਸ਼ਾ; ਵਧੀਆ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲਿੰਗ; ਚੰਗੇ ਵੈੱਬ ਫਰੇਮਵਰਕ; ਪਰ Google ਨੇ Go ਦੇ ਹੱਕ ਵਿੱਚ ਇਸ ਨੂੰ ਛੱਡ ਦਿੱਤਾ।

• Ruby: ਹੁਣ ਤੱਕ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਡਿਵੈਲਪਰ ਤਜਰਬਾ; ਸਭ ਤੋਂ ਵਧੀਆ ਵੈੱਬ ਫਰੇਮਵਰਕ; ਸਭ ਤੋਂ ਪਿਆਰਾ ਭਾਈਚਾਰਾ; ਪਰ ਬਹੁਤ ਹੌਲੀ; ਪੈਕੇਜ ਕਰਨਾ ਕੁਝ ਔਖਾ।

• Rust: ਸਭ ਤੋਂ ਵਧੀਆ ਨਵੀਂ ਭਾਸ਼ਾ; ਜ਼ੀਰੋ-ਅਮੂਰਤੀਕਰਨ ਉੱਤੇ ਜ਼ੋਰ; ਸਮਕਾਲੀਪਣ ਉੱਤੇ ਜ਼ੋਰ; ਫਿਰ ਵੀ ਮੁਕਾਬਲਤਨ ਛੋਟਾ ਈਕੋਸਿਸਟਮ; ਅਤੇ ਕੰਪਾਇਲਰ ਦੀਆਂ ਕੁਝ ਕਿਸਮਾਂ ਦੀਆਂ ਤੇਜ਼ੀਆਂ ਉੱਤੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਸੀਮਾਵਾਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਸਿੱਧੀ ਮੈਮਰੀ ਪਹੁੰਚ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ ਉੱਤੇ ਅਸੁਰੱਖਿਅਤ (unsafe) ਹੋਣਾ ਪੈਂਦਾ ਹੈ।

• TypeScript: JavaScript ਵਿੱਚ ਕਿਸਮਾਂ ਜੋੜਦੀ ਹੈ; ਵਧੀਆ ਟ੍ਰਾਂਸਪਾਈਲਰ; JavaScript ਤੋਂ TypeScript ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਉੱਤੇ ਡਿਵੈਲਪਰਾਂ ਦਾ ਵਧ ਰਿਹਾ ਜ਼ੋਰ; Microsoft ਵੱਲੋਂ ਮਜ਼ਬੂਤ ਸਮਰਥਨ।

ਅਸੀਂ ਇਹ ਫੈਸਲਾ ਕੀਤਾ ਕਿ VM ਦੇ ਕੁਝ ਅਜਿਹੇ ਸਮਝੌਤੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਸਾਨੂੰ ਇਸ ਵੇਲੇ ਲੋੜ ਨਹੀਂ, ਜਿਵੇਂ ਕਿ ਵਾਧੂ ਗੁੰਝਲਤਾ ਜੋ ਰਨਟਾਈਮ ਸਮਰੱਥਾਵਾਂ ਦਿੰਦੀ ਹੈ।

ਸਾਡਾ ਮੰਨਣਾ ਹੈ ਕਿ ਸਾਡਾ ਮੁੱਖ ਫੈਸਲਾ ਦੋ ਸਰਬ-ਵਿਆਪੀ ਚਿੰਤਾਵਾਂ ਵੱਲੋਂ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ:

• ਸਭ ਤੋਂ ਤੇਜ਼ ਰਨਟਾਈਮ ਗਤੀ ਅਤੇ ਸਭ ਤੋਂ ਕੱਸੀ ਸਿਸਟਮ ਪਹੁੰਚ ਲਈ, ਅਸੀਂ JavaScript ਅਤੇ C ਚੁਣਾਂਗੇ।

• ਲਗਭਗ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਨਟਾਈਮ ਗਤੀ ਅਤੇ ਲਗਭਗ ਸਭ ਤੋਂ ਕੱਸੀ ਸਿਸਟਮ ਪਹੁੰਚ ਲਈ, ਅਸੀਂ TypeScript ਅਤੇ Rust ਚੁਣਦੇ ਹਾਂ।

ਸਨਮਾਨਯੋਗ ਜ਼ਿਕਰ ਉਨ੍ਹਾਂ VM ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਵੈੱਬ ਫਰੇਮਵਰਕਾਂ ਨੂੰ ਜਾਂਦਾ ਹੈ ਜੋ ਅਸੀਂ ਚੁਣਦੇ ਜੇ ਸਾਨੂੰ VM ਭਾਸ਼ਾ ਚਾਹੀਦੀ ਹੁੰਦੀ:

• Clojure ਅਤੇ Luminus

• Java ਅਤੇ Spring

• Elixir ਅਤੇ Phoenix

ਪ੍ਰਭਾਵ

ਫਰੰਟ-ਐਂਡ ਡਿਵੈਲਪਰਾਂ ਨੂੰ TypeScript ਸਿੱਖਣੀ ਪਵੇਗੀ। ਜੇ ਡਿਵੈਲਪਰ ਦਾ ਮੁੱਖ ਤਜਰਬਾ JavaScript ਵਰਤਣ ਦਾ ਹੈ ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਆਸਾਨ ਸਿੱਖਣ ਦਾ ਵਕਰ ਹੈ।

ਬੈਕ-ਐਂਡ ਡਿਵੈਲਪਰਾਂ ਨੂੰ Rust ਸਿੱਖਣੀ ਪਵੇਗੀ। ਜੇ ਡਿਵੈਲਪਰ ਦਾ ਮੁੱਖ ਤਜਰਬਾ C/C++ ਵਰਤਣ ਦਾ ਹੈ ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਦਰਮਿਆਨਾ ਸਿੱਖਣ ਦਾ ਵਕਰ ਹੈ, ਅਤੇ ਜੇ ਡਿਵੈਲਪਰ ਦਾ ਮੁੱਖ ਤਜਰਬਾ Java, Python, Ruby ਜਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਮੈਮਰੀ-ਪ੍ਰਬੰਧਿਤ ਭਾਸ਼ਾਵਾਂ ਵਰਤਣ ਦਾ ਹੈ ਤਾਂ ਔਖਾ ਸਿੱਖਣ ਦਾ ਵਕਰ ਹੈ।

TypeScript ਅਤੇ Rust ਦੋਵੇਂ ਮੁਕਾਬਲਤਨ ਨਵੀਆਂ ਹਨ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੇ ਟੂਲਾਂ ਕੋਲ ਅਜੇ ਇਨ੍ਹਾਂ ਭਾਸ਼ਾਵਾਂ ਲਈ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, devops ਪਾਈਪਲਾਈਨ ਨੂੰ ਇਨ੍ਹਾਂ ਭਾਸ਼ਾਵਾਂ ਲਈ ਸਥਾਪਿਤ ਕਰਨਾ ਪਵੇਗਾ, ਅਤੇ ਹੁਣ ਤੱਕ, ਜਿਹੜੇ ਵੀ devops ਟੂਲਾਂ ਦਾ ਅਸੀਂ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹਾਂ, ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਕੋਲ ਵੀ ਇਨ੍ਹਾਂ ਭਾਸ਼ਾਵਾਂ ਲਈ ਮੂਲ ਉਦਾਹਰਨਾਂ ਨਹੀਂ ਹਨ।

TypeScript ਅਤੇ Rust ਲਈ ਕੰਪਾਇਲ ਸਮਾਂ ਕਾਫ਼ੀ ਹੌਲੀ ਹੈ। ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਭਾਸ਼ਾਵਾਂ ਦੇ ਨਵੇਂ ਹੋਣ ਕਾਰਨ ਹੋ ਸਕਦਾ ਹੈ। ਸਾਨੂੰ ਇਹ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹੌਲੀ ਕੰਪਾਇਲ ਸਮੇਂ ਨੂੰ ਕਿਵੇਂ ਘਟਾਇਆ ਜਾਵੇ, ਜਿਵੇਂ ਕਿ ਮੰਗ ਉੱਤੇ ਕੰਪਾਇਲ ਕਰਨਾ, ਕੰਪਾਇਲ-ਸਮਕਾਲੀਪਣ ਆਦਿ।

ਇਨ੍ਹਾਂ ਭਾਸ਼ਾਵਾਂ ਲਈ IDE ਸਹਾਇਤਾ ਅਜੇ ਸਰਵ-ਵਿਆਪੀ ਅਤੇ ਪਹਿਲੀ-ਸ਼੍ਰੇਣੀ ਦੀ ਨਹੀਂ ਹੈ। ਉਦਾਹਰਨ ਲਈ, JetBrains Python ਲਈ ਪਹਿਲੀ-ਸ਼੍ਰੇਣੀ ਦੀ ਸਹਾਇਤਾ ਵਾਲਾ PyCharm IDE ਵੇਚਦਾ ਹੈ, ਪਰ Rust ਲਈ ਪਹਿਲੀ-ਸ਼੍ਰੇਣੀ ਦੀ ਸਹਾਇਤਾ ਵਾਲਾ IDE ਨਹੀਂ ਵੇਚਦਾ; ਇਸ ਦੀ ਬਜਾਏ, JetBrains Rust ਪਲੱਗ-ਇਨ ਵਰਤ ਸਕਦਾ ਹੈ ਜੋ Python ਭਾਸ਼ਾ ਸਹਾਇਤਾ ਦੇ ਮੁਕਾਬਲੇ ਸ਼ਾਇਦ 80% Rust ਭਾਸ਼ਾ ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ।

ਸੰਬੰਧਿਤ

ਸੰਬੰਧਿਤ ਫੈਸਲੇ

ਅਸੀਂ ਉਨ੍ਹਾਂ ਈਕੋਸਿਸਟਮ ਚੋਣਾਂ ਵੱਲ ਵਧਾਂਗੇ ਜੋ ਇਨ੍ਹਾਂ ਭਾਸ਼ਾਵਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਅਜਿਹਾ IDE ਚੁਣਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਜੋ ਇਨ੍ਹਾਂ ਭਾਸ਼ਾਵਾਂ ਲਈ ਚੰਗੀਆਂ ਸਮਰੱਥਾਵਾਂ ਰੱਖਦਾ ਹੋਵੇ।

ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਫਰੰਟ-ਐਂਡ ਵੈੱਬ ਫਰੇਮਵਰਕ ਲਈ, ਅਸੀਂ ਸਾਦੀ JavaScript ਵੱਲ ਝੁਕੇ ਫਰੇਮਵਰਕ (ਜਿਵੇਂ ਕਿ React) ਦੀ ਬਜਾਏ TypeScript ਵੱਲ ਝੁਕੇ ਫਰੇਮਵਰਕ (ਜਿਵੇਂ ਕਿ Vue) ਬਾਰੇ ਫੈਸਲਾ ਕਰਨ ਦੀ ਵਧੇਰੇ ਸੰਭਾਵਨਾ ਰੱਖਦੇ ਹਾਂ।

ਸੰਬੰਧਿਤ ਲੋੜਾਂ

ਸਾਡੀ ਪੂਰੀ ਟੂਲਚੇਨ ਨੂੰ ਇਨ੍ਹਾਂ ਭਾਸ਼ਾਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ।

ਸੰਬੰਧਿਤ ਕਲਾਕ੍ਰਿਤੀਆਂ

ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਕੁਝ ਗੁਪਤ ਜਾਣਕਾਰੀ ਨੂੰ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲਾਂ ਵਿੱਚ ਨਿਰਯਾਤ ਕਰ ਸਕਦੇ ਹਾਂ।

ਸੰਬੰਧਿਤ ਸਿਧਾਂਤ

ਦੋ ਵਾਰ ਮਾਪੋ, ਇੱਕ ਵਾਰ ਬਣਾਓ। ਅਸੀਂ ਕੁਝ ਗਤੀ ਨਾਲੋਂ ਕੁਝ ਸੁਰੱਖਿਆ ਨੂੰ ਤਰਜੀਹ ਦੇ ਰਹੇ ਹਾਂ।

ਰਨਟਾਈਮ ਕੰਪਾਇਲ ਸਮੇਂ ਨਾਲੋਂ ਵੱਧ ਕੀਮਤੀ ਹੈ। ਅਸੀਂ ਡਿਵੈਲਪਰ ਦੀ ਵਰਤੋਂ ਨਾਲੋਂ ਗਾਹਕ ਦੀ ਵਰਤੋਂ ਨੂੰ ਤਰਜੀਹ ਦੇ ਰਹੇ ਹਾਂ।

ਨੋਟ

ਕੋਈ ਵੀ ਨੋਟ ਇੱਥੇ।