jQuery ਨੇ DOM, ਇਵੈਂਟਸ ਅਤੇ AJAX ਨਾਲ JavaScript ਨੂੰ ਆਸਾਨ ਬਣਾਇਆ। ਜਾਣੋ ਇਹ ਕੀ ਹੈ, ਕਿਉਂ ਇਹ ਘਟਿਆ, ਅਤੇ ਅਜੇ ਵੀ ਕਿਦਾਂ ਇਹ ਲਾਜ਼ਮੀ ਹੋ ਸਕਦਾ ਹੈ।

jQuery ਇੱਕ ਛੋਟੀ JavaScript ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ ਵੈਬ ਪੇਜ 'ਤੇ ਆਮ ਕੰਮ ਆਸਾਨ ਬਣਾਉਂਦੀ—ਜਿਵੇਂ ਕਿ ਐਲੀਮੈਂਟ ਚੁਣਨਾ, ਕਲਿੱਕ ਆਦਿ 'ਤੇ ਪ੍ਰਤਿਕਿਰਿਆ ਦੇਣਾ, ਟੈਕਸਟ ਬਦਲਣਾ, ਪੇਜ਼ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਦਿਖਾਉਣਾ/ਛੁਪਾਉਣਾ ਅਤੇ ਸਰਵਰ ਨੂੰ ਬੇਨਤੀ ਭੇਜਣਾ।
ਜੇ ਤੁਸੀਂ ਕਦੇ $("button").click(...) ਵਰਗਾ ਕੋਡ ਵੇਖਿਆ ਹੈ, ਉਹ jQuery ਹੈ। $ ਸਿਰਫ਼ "ਪੇਜ 'ਤੇ ਕੁਝ ਲੱਭੋ ਅਤੇ ਉਸ 'ਤੇ ਕੁਝ ਕਰੋ" ਦਾ ਛੋਟਾ ਰੂਪ ਹੈ।
ਇਹ ਮਾਰਗਦਰਸ਼ਿਕ ਪ੍ਰਾਇਕਟਿਕਲ ਅਤੇ ਗੈਰ-ਟੈਕਨੀਕਲ ਹੈ: jQuery ਕੀ ਹੈ, ਇਹ ਕਿਉਂ ਲੋਕਪ੍ਰਿਯ ਹੋਇਆ, ਕਿਉਂ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਇਸਨੂੰ ਘੱਟ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਜੇ ਤੁਹਾਡੀ ਸਾਈਟ ਅਜੇ ਵੀ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੈ ਤਾਂ ਤੁਹਾਨੂੰ ਕਿਵੇਂ ਨਿਬਟਣਾ ਚਾਹੀਦਾ। ਇਹ ਜਾਣਕਾਰੀ ਸਪਸ਼ਟ ਉਦਾਹਰਨਾਂ ਅਤੇ ਹਕੀਕਤੀ ਰਾਹਦਰਸ਼ਨ ਦੇਣ ਲਈ ਕੁਝ ਲੰਮੀ ਬਣਾਈ ਗਈ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਛੇਤੀ ਸੋਚ।
ਜਦ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ jQuery "ਭੁੱਲਿਆ ਹੋਇਆ" ਹੈ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਨਹੀਂ ਕਹਿ ਰਹੇ ਕਿ ਇਹ ਗਾਇਬ ਹੋ ਗਿਆ। ਉਹ ਇਸ ਦਾ ਮਤਲਬ ਹੈ:
ਇਸ ਲਈ ਕਹਾਣੀ ਇਹ ਨਹੀਂ ਹੈ "jQuery ਮ੍ਰਿਤ ਹੈ"। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ: jQuery ਮੂਲ ਤੌਰ 'ਤੇ ਫਰੰਟ‑ਐਂਡ ਕੰਮ ਲਈ ਡਿਫੌਲਟ ਟੂਲ ਤੋਂ ਲੈ ਕੇ ਇੱਕ ਲੈਗੇਸੀ ਡੀਪੈਂਡੈਂਸੀ ਬਣ ਗਈ—ਜੋ ਤੁਸੀਂ ਵਾਰਸੇ ਵਜੋਂ ਮਿਲ ਸਕਦੀ ਹੈ, ਅਤੇ ਕਦੇ‑ਕਦੇ ਉਦੇਸ਼ਪੂਰਵਕ ਵੀ ਚੁਣੀ ਜਾਂਦੀ ਹੈ।
jQuery ਦੇ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਫਰੰਟ‑ਐਂਡ ਕੰਮ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕੋ-ਇਹ ਛੋਟੇ, ਨਿਰਾਥਾਰ ਕੋਡ ਨੂੰ ਬਾਰ‑ਬਾਰ ਲਿਖਣਾ ਹੂੰਦਾ ਸੀ—ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਕਈ browsers ਵਿੱਚ ਟੈਸਟ ਕਰਨਾ ਅਤੇ ਵੇਖਣਾ ਕਿ ਉਹ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਵਿਹਾਰ ਕਰਦੇ ਹਨ। ਸਧਾਰਨ ਗੋਲਾਂ ਜਿਵੇਂ "ਇਸ ਐਲੀਮੈਂਟ ਨੂੰ ਲੱਭੋ", "ਇੱਕ ਕਲਿੱਕ ਹੈਂਡਲਰ ਲਗਾਓ", ਜਾਂ "ਇੱਕ ਬੇਨਤੀ ਭੇਜੋ" ਵੀ ਇੱਕ ਤਿੰਨ‑ਚੌਥਾਈ ਵਿਸ਼ੇਸ਼ ਮਾਮਲਿਆਂ ਦਾ ਦਰਜਾ ਲੈ ਸਕਦੇ ਸਨ।
ਅਰੰਭਿਕ JavaScript ਬਹੁਤ ਹੱਦ ਤੱਕ ਫੀਚਰ ਬਣਾਉਣ ਦੇ ਬਜਾਏ ਮਾਹੌਲ ਨਾਲ ਸੰਘਰਸ਼ ਕਰਨ ਵਰਗਾ ਸੀ। ਤੁਸੀਂ ਉਹ ਕੋਡ ਲਿਖਦੇ ਜੋ ਇੱਕ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਚੱਲਦਾ, ਫਿਰ ਹੋਰ ਬਰਾਊਜ਼ਰ ਲਈ ਵੱਖਰੇ ਬ੍ਰਾਂਚ ਜੋੜਦੇ। ਟੀਮਾਂ ਆਪਣੇ ਅੰਦਰੂਨੀ "ਛੋਟੀ ਲਾਇਬ੍ਰੇਰੀਆਂ" ਰੱਖਦੀਆਂ ਸਨ ਸਿਰਫ਼ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ UI ਬਦਲਾਵਾਂ ਨਾਲ ਨਿਭਣ ਲਈ।
ਨਤੀਜਾ: ਵਿਕਾਸ ਦੀ ਗਤੀ ਘਟਦੀ, ਬੱਗ ਵੱਧਦੇ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਵੀ ਕਿਸੇ ਪੁਰਾਣੇ ਬਰਾਊਜ਼ਰ ਨੂੰ ਤੋੜ ਦੇਣ ਦਾ ਡਰ ਰਹਿੰਦਾ।
ਬ੍ਰਾਉਜ਼ਰ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੁੰਦੇ ਸਨ। DOM selection ਤਰੀਕੇ, ਇਵੈਂਟ ਹੇਨਡਲਿੰਗ, ਅਤੇ ਐਲੀਮੈਂਟ ਦੇ ਆਕਾਰ ਲੈਣ ਦਾ ਤਰੀਕਾ ਵੀ ਵੱਖ हो ਸਕਦਾ ਸੀ। Internet Explorer ਖ਼ਾਸ ਕਰਕੇ events ਅਤੇ XMLHTTP ਬੇਨਤੀਆਂ ਲਈ ਵੱਖਰੇ API ਰੱਖਦਾ ਸੀ, ਇਸ ਲਈ "ਸਟੈਂਡਰਡ" ਕੋਡ ਸਦਾ ਖ਼ਰੀ ਨਿਯਮਤ ਨਹੀਂ ਸੀ।
ਇਹ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ ਵੈਬਸਾਈਟ ਇਕ ਹੀ ਬਰਾਊਜ਼ਰ ਲਈ ਨਹੀਂ ਬਣਾਈਆਂ ਜਾ ਰਹੀਆਂ ਸਨ। ਜੇ ਤੁਹਾਡੀ ਚੈੱਕਆਊਟ ਫਾਰਮ, ਨੈਵੀਗੇਸ਼ਨ ਮੈਨੂ, ਜਾਂ ਮੋਡਲ ਡਾਇਲਾਗ ਕਿਸੇ ਪ੍ਰਸਿੱਧ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਫੇਲ ਹੋਵੇ, ਤਾਂ ਇਹ ਇੱਕ ਵਪਾਰਕ ਸਮੱਸਿਆ ਬਣ ਸਕਦੀ ਸੀ।
jQuery ਨੇ ਇੱਕ ਸਥਿਰ, ਦੋਸਤਾਨਾ API ਮੁਹੱਈਆ ਕਰਵਾਈ ਜੋ ਉਹਨਾਂ ਫਰਕਾਂ ਨੂੰ ਨਰਮ ਕਰ ਦਿੰਦਾ ਸੀ।
ਇਸ ਨੇ ਆਮ ਕੰਮਾਂ ਨੂੰ ਕਾਫੀ ਸਧਾਰਨ ਕੀਤਾ:
ਜਿਵੇਂ ਕਿ jQuery ਦੀ "ਘੱਟ ਲਿਖੋ, ਜ਼ਿਆਦਾ ਕਰੋ" ਅਦਤ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ—ਖਾਸ ਕਰਕੇ ਉਸ ਯੁੱਗ ਵਿੱਚ ਜਦ "ਆਧੁਨਿਕ DOM APIs" ਹੁਣ ਦੀ ਤਰ੍ਹਾਂ ਸਮਰੱਥ ਅਤੇ ਵਿਯਾਪੀ ਨਹੀਂ ਸਨ।
jQuery ਦੀ ਅਸਲ ਤਾਕਤ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਇਸ ਨੇ ਨਵੀਆਂ ਸੋਚਾਂ ਦੀ ਪੈਦਾਵਾਰ ਕੀتی—ਬਲਕਿ ਇਹ ਆਮ browser ਕੰਮਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ browsers ਵਿੱਚ ਇੱਕਸਾਰ ਅਤੇ ਆਸਾਨ ਬਣਾਉਂਦੀ ਸੀ। ਜੇ ਤੁਸੀਂ ਪੁਰਾਣਾ ਫਰੰਟ‑ਐਂਡ ਕੋਡ ਪੜ੍ਹ ਰਹੇ ਹੋ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ jQuery ਨੂੰ ਚਾਰ ਰੋਜ਼ਾਨਾ ਕੰਮਾਂ ਲਈ ਵਰਤਿਆ ਹੋਇਆ ਵੇਖੋਗੇ।
$ ਫੰਕਸ਼ਨ ਦੀ ਸੋਚ)$() ਫੰਕਸ਼ਨ ਤੁਹਾਨੂੰ CSS‑ਜੈਸੀ ਸਿਲੈਕਟਰਾਂ ਨਾਲ ਐਲੀਮੈਂਟ "ਪਕੜਨ" ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਸਮੂਹ ਵਜੋਂ ਕੰਮ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ।
ਬਰਾਊਜ਼ਰ ਖ਼ਾਮੀਆਂ ਅਤੇ ਲੰਬੇ APIs ਨਾਲ ਜੂਝਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਛੋਟੇ, ਚੇਨਏਬਲ ਕਾਲਾਂ ਨਾਲ ਸਭ ਆਈਟਮ ਚੁਣ ਸਕਦੇ, ਚਾਈਲਡ ਲੱਭ ਸਕਦੇ ਜਾਂ ਪੈਰੇਂਟ ਤੱਕ ਜਾ ਸਕਦੇ ਸੀ।
jQuery ਨੇ ਯੂਜ਼ਰ ਕਾਰਵਾਈਆਂ 'ਤੇ ਪ੍ਰਤਿਕਿਰਿਆ ਦੇਣਾ ਸਧਾਰਨ ਕੀਤਾ:
click ਬਟਨ ਅਤੇ ਲਿੰਕ ਲਈsubmit ਫਾਰਮਾਂ ਲਈready ਪੇਜ ਲੋਡ ਹੋਣ 'ਤੇ ਕੋਡ ਚਲਾਉਣ ਲਈਇਸਨੇ ਇਹ ਵੀ ਨਰਮ ਕੀਤਾ ਕਿ ਕਿਵੇਂ ਬਰਾਊਜ਼ਰ ਇਵੈਂਟ ਆਬਜੈਕਟ ਅਤੇ ਬਾਈਂਡਿੰਗ ਨੂੰ ਸਾਂਭਦੇ, ਜੋ ਬਰਾਊਜ਼ਰ ਸਹਿਯੋਗ ਨਾ‑ਸਮਾਨ ਹੋਣ 'ਤੇ ਕਾਫੀ ਮਾਇਨੇ ਰੱਖਦਾ ਸੀ।
ਜਦੋਂ fetch() ਸਟੈਂਡਰਡ ਨਹੀਂ ਸੀ, jQuery ਦੀ $.ajax(), $.get(), ਅਤੇ $.post() ਇੱਕ ਸਿੱਧਾ ਤਰੀਕਾ ਸਨ ਸਰਵਰ ਤੋਂ ਡੇਟਾ ਮੰਗਨ ਅਤੇ ਪੇਜ਼ ਨੂੰ ਰੀਲੋਡ ਕੀਤੇ ਬਿਨਾਂ ਅਪਡੇਟ ਕਰਨ ਲਈ।
ਇਸਨੇ ਉਹ ਪੈਟਰਨ ਸੰਭਵ ਬਣਾਏ ਜੋ ਹੁਣ ਆਮ ਲੱਗਦੇ—live search, "load more" ਬਟਨ, ਹਿੱਸੇਦਾਰ ਪੇਜ਼ ਅਪਡੇਟ—ਇੱਕ ਹੀ ਜਾਣੂ API ਨਾਲ।
jQuery ਨੇ ਤੇਜ਼ UI ਛੂਟਾਂ ਨੂੰ ਮਸ਼ਹੂਰ ਕੀਤਾ ਜਿਵੇਂ hide(), show(), fadeIn(), slideToggle(), ਅਤੇ animate()। ਇਹ ਮੈਨੂਜ਼, ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਅਤੇ ਬੁਨਿਆਦੀ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨਾਂ ਲਈ ਸੁਵਿਧਾਜਨਕ ਸਨ—ਖਾਸ ਕਰਕੇ ਉਸ ਸਮੇਂ ਜਦ CSS ਸਹਿਯੋਗ ਘੱਟ ਭਰੋਸੇਯੋਗ ਸੀ।
ਇਹ ਸਭ ਸੁਵਿਧਾਵਾਂ ਵਜ੍ਹਾ ਹੈ ਕਿ ਲੈਗੇਸੀ JavaScript ਕੋਡ ਅਕਸਰ $( ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ jQuery ਇਕ ਲੰਮਾ ਸਮਾਂ ਡਿਫੌਲਟ ਟੂਲ ਰਹੀ।
jQuery ਦੀ ਖਿਆਤੀ ਅਕਸਰ ਇਸ ਗੱਲ ਤੋਂ ਆਉਂਦੀ ਹੈ ਕਿ ਆਮ UI ਟਾਸਕ ਕਰਨ ਲਈ ਲਾਜਵਾਬ ਤੌਰ 'ਤੇ ਘੱਟ ਕੋਡ ਲੱਗਦਾ ਸੀ—ਖਾਸ ਕਰਕੇ ਜਦ ਬਰਾਊਜ਼ਰ ਫਰਕ ਦੁਖਦਾਈ ਸਨ। ਇੱਕ ਤੁਰੰਤ side-by-side ਇਸਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ।
jQuery
// Select a button and run code when it's clicked
$('#save').on('click', function (e) {
e.preventDefault();
$('.status').text('Saved!');
});
Modern (vanilla) JavaScript
// Select a button and run code when it's clicked
const saveButton = document.querySelector('#save');
const status = document.querySelector('.status');
saveButton?.addEventListener('click', (e) => {
e.preventDefault();
if (status) status.textContent = 'Saved!';
});
ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ, jQuery ਵਰਜ਼ਨ "ਸਾਫ਼" ਲੱਗਦਾ ਹੈ: ਇੱਕ ਲੜੀ ਐਲੀਮੈਂਟ ਨੂੰ ਚੁਣਦੀ, ਹੈਂਡਲਰ ਜੋੜਦੀ ਅਤੇ ਟੈਕਸਟ ਅਪਡੇਟ ਕਰਦੀ। ਇਹ ਸੰਕੁਚਿਤਤਾ ਇੱਕ ਵੱਡੀ ਵਿਕਰੀ ਬਿੰਦੂ ਸੀ।
ਆਧੁਨਿਕ JavaScript ਥੋੜ੍ਹਾ ਜ਼ਿਆਦਾ verbose ਹੈ, ਪਰ ਇਹ ਵੀ ਹੋਰ ਸਪਸ਼ਟ ਹੈ:
querySelector ਅਤੇ addEventListener ਠੀਕ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ।textContent ਇੱਕ ਸਟੈਂਡਰਡ DOM ਪ੍ਰਾਪਰਟੀ ਹੈ (ਕੋਈ ਲਾਇਬ੍ਰੇਰੀ ਰੈਪਰ ਨਹੀਂ)।?.) ਅਤੇ null checks ਇਸ ਗੱਲ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦੇ ਹਨ ਕਿ ਜੇ ਐਲੀਮੈਂਟ ਮੌਜੂਦ ਨਾ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਵੇਗਾ।ਸੰਦਰਭ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਪੁਰਾਣੇ ਕੋਡਬੇਸ ਨੂੰ ਮੇਂਟੇਨ ਕਰ ਰਹੇ ਹੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਹਰ ਥਾਂ jQuery ਵਰਤਦਾ ਹੈ, ਤਾਂ jQuery ਟੁਕੜਾ ਹੋਰ ਸਥਿਰ ਅਤੇ ਤੇਜ਼ ਕੰਮ ਕਰਨ ਯੋਗ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਨਵਾਂ ਕੋਡ ਲਿਖ ਰਹੇ ਹੋ, ਤਾਂ ਆਧੁਨਿਕ DOM APIs ਅਕਸਰ ਕਾਫੀ ਹਨ, dependency ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਅੱਜ ਦੇ ਟੂਲਿੰਗ ਅਤੇ ਫਰੇਮਵਰਕਸ ਨਾਲ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਮਿਲਦੇ ਹਨ।
ਕਾਫੀ ਸਮੇਂ ਲਈ, jQuery ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਲਾਭ ਹੈ ਭਰੋਸੇਯੋਗਤਾ। ਤੁਸੀਂ ਇੱਕ ਹੀ ਤਰੀਕੇ ਨਾਲ ਐਲੀਮੈਂਟ ਚੁਣ ਸਕਦੇ, events ਬਾਂਧ ਸਕਦੇ ਜਾਂ Ajax ਰਿਕੁੈਸਟ ਚਲਾ ਸਕਦੇ—ਅਤੇ ਇਹ ਜ਼ਿਆਦਾਤਰ ਥਾਵਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ।
ਸਾਲਾਂ ਵਿੱਚ, browsers ਨੇ ਸਟੈਂਡਰਡ ਕੀਤਾ ਅਤੇ ਸੁਧਾਰਿਆ। jQuery ਨੇ ਜੋ ਕਈ "ਜ਼ਰੂਰੀ" ਸੁਵਿਧਾਵਾਂ ਇਕੱਠੀਆਂ ਕੀਤੀਆਂ ਸਨ, ਉਹ ਹੁਣ JavaScript ਵਿੱਚ ਹੀ ਮੌਜੂਦ ਹਨ, ਇਸ ਲਈ ਅਕਸਰ ਸਧਾਰਨ ਕੰਮਾਂ ਲਈ ਵੱਖਰੀ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ।
ਆਧੁਨਿਕ DOM ਵਿਧੀਆਂ ਜ਼ਿਆਦਾਤਰ ਆਮ jQuery ਪੈਟਰਨਾਂ ਨੂੰ ਢੱਕਦੀਆਂ ਹਨ:
document.querySelector() / document.querySelectorAll() ਕਈ ਚੋਣਾਂ ਲਈ $(...) ਦੀ ਜਗ੍ਹਾ ਲੈਂਦੇ ਹਨ।element.classList.add() / .remove() / .toggle() ਕਲਾਸ ਮੈਨਿਪੂਲੇਸ਼ਨ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ।element.addEventListener() ਜ਼ਿਆਦਾਤਰ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਲਈ jQuery ਦੇ event wrapper ਦੀ ਜਗ੍ਹਾ ਲੈ ਗਿਆ।jQuery‑ਖ਼ਾਸ ਹੇਲਪਰ ਯਾਦ ਰੱਖਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਮਿਆਰੀ APIs 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਆਧੁਨਿਕ browsers 'ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।
fetch ਵੱਲ ਚਲੇ ਗਈਆਂਜਿੱਥੇ ਪਹਿਲਾਂ $.ajax() ਜ਼ਰੂਰੀ ਸੀ, fetch() ਹੁਣ ਬਹੁਤ ਸਾਰੇ ਦਿਨ‑ਪ੍ਰਤੀਦਿਨ ਬੇਨਤੀਆਂ ਸੰਭਾਲਦਾ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਜਦ ਇਹ JSON ਨਾਲ ਜੋੜਿਆ ਜਾਵੇ:
const res = await fetch('/api/items');
const data = await res.json();
ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ errors ਅਤੇ timeouts ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸੰਭਾਲਣਾ ਪੈਦਾ ਹੈ, ਪਰ ਮੁੱਖ ਵਿਚਾਰ—ਬਿਨਾਂ ਪਲੱਗਇਨ ਦੇ ਬੇਨਤੀਆਂ ਬਣਾਉਣਾ—ਹੁਣ ਨੈਟਿਵ ਹੈ।
jQuery ਨੇ ਕਈ ਲੋਕਾਂ ਨੂੰ asynchronous ਕੋਡ (callbacks ਅਤੇ $.Deferred) ਨਾਲ ਜਾਣੂ ਕਰਵਾਇਆ। ਅੱਜ Promises ਅਤੇ async/await async ਫਲੋਜ਼ ਨੂੰ ਪੜ੍ਹਨ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ES modules ਕੋਡ ਦੀ ਵਿਵਸਥਾ ਸਪਸ਼ਟ ਕਰਦੇ ਹਨ।
ਇਹ ਜੋੜ—ਆਧੁਨਿਕ DOM APIs + fetch + ਭਾਸ਼ਾ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ—ਉਹ ਮੁੱਖ ਵਜ੍ਹਾ ਹੈ ਕਿ ਟੀਮਾਂ ਹੁਣ jQuery ਨੂੰ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਲੈਣ ਦੀ ਲੋੜ ਘੱਟ ਮਹਿਸੂਸ ਕਰਦੀਆਂ ਹਨ।
jQuery ਇਕ "ਮਲਟੀ-ਪੇਜ਼ ਵੈਬਸਾਈਟ" ਯੁੱਗ ਵਿੱਚ ਉੱਭਰਿਆ: ਸਰਵਰ HTML ਰੈਂਡਰ ਕਰਦਾ, ਬ੍ਰਾਉਜ਼ਰ ਪੇਜ਼ ਲੋਡ ਕਰਦਾ, ਅਤੇ ਤੁਸੀਂ ਮਾਰਕਅੱਪ 'ਤੇ ਹੋਕਰ ਬਿਹੈਵਿਅਰ ਜੋੜਦੇ—ਕਲਿੱਕ ਹੈਂਡਲਰਾਂ, ਐਨੀਮੇਸ਼ਨਾਂ, AJAX ਕਾਲਾਂ—ਇਸ ਤਰ੍ਹਾਂ।
ਆਧੁਨਿਕ ਫਰੰਟ‑ਐਂਡ ਫਰੇਮਵਰਕਸ ਨੇ ਇਹ ਮਾਡਲ ਉਲਟ ਦਿੱਤਾ। ਬਦਲ ਵਿੱਚ, ਐਪ ਆਮ ਤੌਰ 'ਤੇ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ UI ਜਨਰੇਟ ਕਰਦੇ ਹਨ ਅਤੇ ਡੇਟਾ ਨਾਲ ਸਿੰਕ ਰੱਖਦੇ ਹਨ।
React, Vue, ਅਤੇ Angular ਨੇ ਕੰਪੋਨੈਂਟਸ ਦੀ ਸੋਚ ਪ੍ਰਸਿੱਧ ਕੀਤੀ—ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਹਿੱਸੇ ਜੋ ਆਪਣਾ ਮਾਰਕਅੱਪ, ਵਿਹੈਵਿਅਰ ਅਤੇ state ਨੂੰ ਮਾਲਕਾਂ ਬਣਾਉਂਦੇ ਹਨ।
ਇਸ ਵਿਵਸਥਾ ਵਿੱਚ, ਫਰੇਮਵਰਕ ਸਕਰੀਨ 'ਤੇ ਜੋ ਹੈ ਉਸਦਾ ਸਰੋਤ‑ਸੱਚ ਹੋਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਇਹ state ਨੂੰ ਟ੍ਰੈਕ ਕਰਦਾ, ਜਦ state ਬਦਲਦਾ ਤਾਂ UI ਦੇ ਹਿੱਸੇ ਰੀ-ਰੈਂਡਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਨੂੰ ਬਿਆਨਾਤਮਕ ਰੂਪ ਵਿੱਚ ਬਦਲਾਅ ਦਿਖਾਉਣੇ ਪੈਂਦੇ ਹਨ ("ਜਦ X ਸੱਚ ਹੈ, ਤਦ Y ਦਿਖਾਓ")।
ਦੂਜੇ ਪਾਸੇ, jQuery ਨਿਰਦੇਸ਼ਾਤਮਕ DOM ਮੈਨਿਪੂਲੇਸ਼ਨ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ("ਇਸ ਐਲੀਮੈਂਟ ਨੂੰ ਲੱਭੋ, ਇਸਦਾ ਟੈਕਸਟ ਬਦਲੋ, ਇਸਨੂੰ ਛੁਪਾਓ")। ਇਹ ਇੱਕ ਫਰੇਮਵਰਕ ਦੀ ਰੇਂਡਰਿੰਗ ਸਾਈਕਲ ਨਾਲ ਝਗੜਨ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਹੱਥੋਂ DOM ਨੋਡਸ ਬਦਲਦੇ ਹੋ ਜੋ ਕਿਸੇ ਕੰਪੋਨੈਂਟ "ਦੀ ਮਾਲਕੀ" ਹੈ, ਤਾਂ ਅਗਲਾ ਰੀ-ਰੈਂਡਰ ਤੁਹਾਡੇ ਬਦਲਾਅ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦਾ—ਜਾਂ ਤੁਸੀਂ ਅਨੁਪਾਤਿਕਤਾਵਾਂ ਨੂੰ ਡਿਬੱਗ ਕਰਦੇ ਰਹਿਣਾ ਪੈਂਦਾ।
ਜਿਵੇਂ ਜਦ SPAs ਆਮ ਹੋਏ, ਟੀਮਾਂ ਨੇ build tools ਅਤੇ bundlers (Webpack, Rollup, Vite) ਅਪਨਾਏ। ਥੱਲੇ ਸਿਰਫ़ ਕੁਝ script ਟੈਗਾਂ ਪਾਉਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ modules ਇੰਪੋਰਟ ਕਰਦੇ, सिरਫ ਜੋ ਵਰਤ ਰਹੇ ਹੋ ਉਹ ਬੰਡਲ ਕਰਦੇ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਲਈ optimize ਕਰਦੇ।
ਇਹ ਬਦਲਾਅ ਲੋਕਾਂ ਨੂੰ dependencies ਅਤੇ ਬੰਡਲ ਸਾਈਜ਼ ਲਈ ਜ਼ਿਆਦਾ ਸੰਵੇਦਨਸ਼ੀਲ ਬਣਾ ਦਿੱਤਾ। jQuery "ਸਿਰਫ़ ਸਟੇਜ਼ ਲਈ" ਜੋੜਨਾ ਘੱਟ ਕੁਦਰਤੀ ਲੱਗਿਆ ਜਦ ਹਰ ਕਿਲੋਬਾਈਟ ਅਤੇ ਤੀਜੀ-ਪਾਰਟੀ ਅਪਡੇਟ pipeline ਦਾ ਹਿੱਸਾ ਬਣ ਗਿਆ।
ਤੁਸੀਂ ਇੱਕ ਫਰੇਮਵਰਕ ਦੇ ਅੰਦਰ jQuery ਵਰਤ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਅਕਸਰ ਇੱਕ ਵਿਸ਼ੇਸ਼‑ਕੇਸ ਟਾਪੂ ਬਣ ਜਾਂਦਾ—ਟੈਸਟ ਕਰਨਾ ਔਖਾ, ਸੋਚਣਾ ਮੁਸ਼ਕਲ, ਅਤੇ ਰੀਫੈਕਟਰਾਂ ਦੌਰਾਨ टूटਣ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧਦੀ ਹੈ। ਇਸ ਕਰਕੇ ਕਈ ਟੀਮਾਂ jQuery‑ਸ਼ੈਲੀ DOM ਸਕ੍ਰਿਪਟਿੰਗ ਦੀ ਥਾਂ ਫਰੇਮਵਰਕ‑ਨੈਟੀਵ ਪੈਟਰਨ ਚੁਣਦੀਆਂ ਹਨ।
jQuery ਖੁਦ "ਵੱਡੀ" ਨਹੀਂ, ਪਰ ਇਹ ਅਕਸਰ ਬੈੱਗੇਜ ਨਾਲ ਆਉਂਦਾ ਹੈ। ਕਈ ਪ੍ਰੋਜੈਕਟ ਜਿਹੜੇ jQuery 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ, ਉਹ plugins (sliders, date pickers, modal libraries, validation helpers) ਕੱਢ ਲੈਂਦੇ ਹਨ, ਹਰ ਇੱਕ ਵਧੇਰੇ ਤੀਜੀ-ਪਾਰਟੀ ਕੋਡ ਸ਼ਾਮਲ ਕਰਦਾ। ਸਮੇਂ ਦੇ ਨਾਲ, ਇੱਕ ਪੇਜ਼ ਕਈ ਇਹੋ ਜਿਹੇ ਯੂਟਿਲਿਟीज਼ ਡਲੀਵਰ ਕਰ ਸਕਦਾ—ਖਾਸ ਕਰਕੇ ਜਦ ਫੀਚਰ ਤੇਜ਼ੀ ਨਾਲ ਜੋੜੇ ਗਏ ਅਤੇ ਮੁੜ-ਦੇਖੇ ਨਹੀਂ ਗਏ।
ਵਧੇਰੇ JavaScript ਆਮ ਤੌਰ 'ਤੇ ਬ੍ਰਾਉਜ਼ਰ ਲਈ ਹੋਰ fetch, parse, ਅਤੇ execute ਕੰਮ ਹੁੰਦਾ ਹੈ ਪਹਿਲਾਂ ਤੋਂ ਪਹਿਲਾਂ ਪੇਜ਼ ਯੂਜ਼ਬਲ ਮਹਿਸੂਸ ਹੋਵੇ। ਇਹ ਪ੍ਰਭਾਵ ਮੋਬਾਈਲ, ਹੌਲੀ ਨੈੱਟਵਰਕ ਅਤੇ ਪੁਰਾਣੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਚਾਹੇ ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਆਖ਼ਿਰਕਾਰ ਸੁਚੱਜਾ ਅਨੁਭਵ ਪ੍ਰਾਪਤ ਕਰਨ, "ਟਾਈਮ ਟੁ ਯੂਜ਼ਬਲ" ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਪੇਜ਼ ਵਾਧੂ ਸਕ੍ਰਿਪਟਾਂ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਡੀਪੈਂਡੈਂਸੀਜ਼ਾਂ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੋਵੇ।
ਲੰਬੇ ਸਮੇਂ ਚੱਲਦੇ ਸਾਈਟਾਂ ਵਿੱਚ ਇੱਕ ਆਮ ਪੈਟਰਨ "ਹਾਈਬ੍ਰਿਡ" ਕੋਡਬੇਸ ਹੈ: ਕੁਝ ਫੀਚਰ jQuery ਨਾਲ ਲਿਖੇ, ਨਵੇਂ ਹਿੱਸੇ React/Vue/Angular ਨਾਲ ਬਣਾਏ ਗਏ, ਅਤੇ ਕੁਝ vanilla JavaScript ਟੁਕੜੇ ਵੀ। ਇਸ ਮਿਲਾਪ ਨਾਲ ਗੁੰਝਲਦਾਰ ਹੋ ਸਕਦਾ ਹੈ:
ਜਦ ਅਨੇਕ ਸ਼ੈਲੀਆਂ ਇਕੱਠੇ ਹੋਂਦੀਆਂ ਹਨ, ਛੋਟੇ ਬਦਲਾਅ ਖਤਰਨਾਕ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਕ ਡੀਵੈਲਪਰ ਇੱਕ ਕੰਪੋਨੈਂਟ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਪਰ ਇੱਕ ਪੁਰਾਣਾ jQuery ਸਕ੍ਰਿਪਟ ਓਸੇ ਮਾਰਕਅੱਪ 'ਤੇ ਹੱਥ ਰੱਖਦਾ ਹੈ ਅਤੇ ਬਗ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਦੁਹਰਾਉਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।
ਟੀਮਾਂ ਹੌਲੀ-ਹੌਲੀ jQuery ਤੋਂ ਦੂਰ ਜਾਂਦੀਆਂ ਹਨ ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਇਹ "ਰੁਕ ਜਾਂਦੀ" ਹੈ, ਪਰ ਇਸ ਲਈ ਕਿ ਆਧੁਨਿਕ ਪ੍ਰੋਜੈਕਟ performance, چھੋਟੀ ਬੰਡਲ ਅਤੇ UI ਵਿਹੈਵਿਅਰ ਦੀ ਇੱਕਸਾਰ ਮਾਲਕੀ ਲਈ optimize ਕਰਦੇ ਹਨ। ਜਿਵੇਂ ਜ਼ਿਆਦਾ ਇੱਕ ਸਾਈਟ ਵਧਦੀ ਹੈ, ਤੀਜੀ‑ਪਾਰਟੀ ਕੋਡ ਘਟਾਉਣਾ ਅਤੇ ਇੱਕ ਪਹੁੰਚ 'ਤੇ ਸਟੈਂਡਰਡ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ performance tuning, ਡੀਬੱਗਿੰਗ ਅਤੇ onboarding ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
jQuery ਸਿਰਫ਼ ਲੋਕਪ੍ਰਿਯ ਨਹੀਂ ਬਣੀ—ਇਹ ਡਿਫੌਲਟ ਬਣ ਗਈ। ਸਾਲਾਂ ਤੱਕ, ਇਹ ਇੰਟਰਨੈੱਟ 'ਤੇ ਇੰਟਰਐਕਟੀਵ ਪੰਨਿਆਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਸੀ, ਇਸ ਕਰਕੇ ਇਹ ਅਨੇਕ templates, ਨਮੂਨੇ, tutorials ਅਤੇ copy‑paste ਹੱਲਾਂ ਵਿੱਚ ਪੈ ਗਈ।
ਇੱਕ ਵਾਰੀ ਇਹ ਹੋ ਗਿਆ, jQuery ਤੋਂ ਬਚਣਾ ਮੁਸ਼ਕਲ ਹੋ ਗਿਆ: ਭਾਵੇਂ ਇੱਕ ਸਾਈਟ ਸਿਰਫ਼ ਇਕ ਛੋਟਾ ਫੀਚਰ ਵਰਤੇ, ਉਹ ਅਕਸਰ ਪੂਰੀ ਲਾਇਬ੍ਰੇਰੀ ਲੋਡ ਕਰਦੀ ਸੀ ਕਿਉਂਕਿ ਹੋਰ ਸਭ ਕੁਝ ਉਹ ਮੰਨ ਕੇ ਲਿਖਿਆ ਹੋਇਆ ਸੀ।
ਬਹੁਤ ਵੱਡਾ ਕਾਰਨ ਜੋ jQuery ਅਜੇ ਵੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਉਹ ਇਹ ਹੈ: ਇਸ ਦੀ ਕਾਮਯਾਬੀ ਨੇ ਇਸਨੂੰ ਤੀਜੀ‑ਪਾਰਟੀ ਕੋਡ ਵਿੱਚ "ਹਰ ਥਾਂ" ਕਰ ਦਿੱਤਾ। ਪੁਰਾਣੇ UI widgets, sliders, lightboxes, ਫਾਰਮ validators, ਅਤੇ ਥੀਮ ਸਕ੍ਰਿਪਟ ਆਮ ਤੌਰ 'ਤੇ jQuery plugins ਵਜੋਂ ਲਿਖੇ ਗਏ। ਜੇ ਇੱਕ ਸਾਈਟ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ jQuery ਹਟਾਉਣ ਦਾ ਮਤਲਬ ਉਹ dependency ਦੁਬਾਰਾ ਲਿਖਣਾ ਜਾਂ ਬਦਲਣਾ ਹੋ ਸਕਦਾ—ਸਿਰਫ਼ ਕੁਝ ਲਾਈਨਾਂ ਬਦਲਣਾ ਨਹੀਂ।
WordPress jQuery ਦਾ ਇੱਕ ਵੱਡਾ ਸਰੋਤ ਹੈ। ਕਈ themes ਅਤੇ plugins—ਖ਼ਾਸ ਕਰਕੇ ਜੋ ਸਾਲਾਂ ਪਹਿਲਾਂ ਬਣਾਏ ਗਏ—front-end ਵਿਹੈਵਿਅਰ ਲਈ jQuery ਵਰਤਦੇ ਸਨ ਅਤੇ ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ WordPress admin ਸਕਰੀਨਾਂ ਨੇ ਵੀ ਇਸ 'ਤੇ ਆਧਾਰ ਕੀਤਾ। ਜਦੋਂ ਨਵੀਂ ਵਰਜਨ ਆਧੁਨਿਕ JavaScript ਵੱਲ ਵਧਦੀਆਂ ਹਨ, ਫਿਰ ਵੀ ਲੰਬੀ ਲੜੀ ਦੇ ਮੌਜੂਦਾ ਐਕਸਟੈਨਸ਼ਨ jQuery ਨੂੰ ਬਹੁਤ ਸਾਈਟਾਂ 'ਤੇ ਜੀਵੰਤ ਰੱਖਦੇ ਹਨ।
ਪੁਰਾਣੀਆਂ ਸਾਈਟਾਂ ਅਕਸਰ "ਜੋ ਕੰਮ ਕਰਦਾ ਉਸਨੂੰ ਨਾ ਤੋੜੋ" ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ। jQuery ਨੂੰ ਰੱਖਣਾ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੋ ਸਕਦੀ ਹੈ ਜਦ:
ਖੁਲਾਸਾ, jQuery ਹਮੇਸ਼ਾ "ਭੁੱਲਿਆ" ਨਹੀਂ ਹੁੰਦਾ—ਬਲਕਿ ਇਹ ਅਕਸਰ ਉਹ ਅਧਾਰ ਹੁੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਇੱਕ ਸਾਈਟ ਬਣੀ ਸੀ, ਅਤੇ ਅਧਾਰ ਬਦਲਨਾ ਆਸਾਨ ਕੰਮ ਨਹੀਂ।
jQuery "ਖ਼ਰਾਬ" ਸਾਫਟਵੇਅਰ ਨਹੀਂ—ਇਹ ਸਿਰਫ਼ ਹੁਣ ਸੱਜਣ ਲੋੜੀ ਨਹੀਂ ਜਿਵੇਂ ਪਹਿਲਾਂ ਸੀ। ਫਿਰ ਵੀ ਕੁਝ ਹਾਲਾਤ ਹਨ ਜਿੱਥੇ ਇੱਕ ਛੋਟਾ jQuery ਰੱਖਣਾ ਜਾਂ ਈ ਜੋੜਨਾ ਸਭ ਤੋਂ ਅਮਲੀ ਚੋਣ ਹੋ ਸਕਦੀ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦ ਤੁਸੀਂ ਸਮਾਂ, ਅਨੁਕੂਲਤਾ ਜਾਂ ਸਥਿਰਤਾ ਲਈ optimize ਕਰ ਰਹੇ ਹੋ।
ਜੇ ਤੁਹਾਨੂੰ ਪੁਰਾਣੇ browsers (ਖ਼ਾਸ ਕਰਕੇ Internet Explorer ਦੀਆਂ ਪੁਰਾਣੀਆਂ ਵਰਜਨਾਂ) ਨੂੰ ਸਪੋਰਟ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ jQuery ਅਜੇ ਵੀ DOM selection, event handling, ਅਤੇ AJAX ਨੂੰ ਐੱਸੇ ਤਰੀਕੇ ਨਾਲ ਸਪਲਾਈ ਕਰ ਸਕਦੀ ਹੈ ਜੋ ਨੈਟਿਵ APIs ਬਿਨਾਂ ਵਾਧੂ polyfills ਦੇ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ।
ਮੁੱਖ ਪ੍ਰਸ਼ਨ ਲਾਗਤ ਹੈ: legacy browsers ਦਾ ਸਮਰਥਨ ਆਮ ਤੌਰ 'ਤੇ ਵਾਧੂ ਕੋਡ ਭੇਜਣ ਦਾ ਮਤਲਬ ਹੁੰਦਾ ਹੈ। ਇਸ ਸੰਦਰਭ ਵਿੱਚ, jQuery ਇੱਕ ਵਾਜਬ ਹਿੱਸਾ ਹੋ ਸਕਦੀ ਹੈ ਸਮਰਥਤਾ ਪੈਕੇਜ ਦੀ।
ਜੇ ਇੱਕ ਸਾਈਟ ਪਹਿਲਾਂ ਹੀ jQuery 'ਤੇ ਬਨੀ ਹੋਈ ਹੈ, ਤਾਂ ਛੋਟੀਆਂ UI ਟਵੀਕਸ ਅਕਸਰ ਉਸੇ ਢੰਗ ਵਿੱਚ ਕਰਨ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੁੰਦੀਆਂ ਹਨ। ਅਪ੍ਰੋਚਾਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਗੁੰਝਲ ਪੈਦਾ ਹੋ ਸਕਦੀ (ਇਵੈਂਟ ਦੇ ਦੋ ਤਰੀਕੇ, DOM ਮੈਨਿਪੂਲੇਸ਼ਨ ਦੇ ਦੋ ਤਰੀਕੇ), ਜੋ ਰੱਖ-ਰਖਾਵ ਨੂੰ ਔਖਾ ਬਣਾਉਂਦਾ ਹੈ।
ਇੱਕ ਢੰਗ: ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਜਾਂ ਦੋ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਛੂਹ ਰਹੇ ਹੋ ਅਤੇ ਐਪ ਹੋਰਥਰ ਥਾਂ ਇੱਕਸਾਰ ਹੈ, ਤਾਂ jQuery ਨਾਲ patch ਕਰਨਾ ਠੀਕ ਹੈ—ਸਿਰਫ਼ ਨਵੇਂ "ਸਿਸਟਮ" ਵਿੱਚ jQuery ਦੇ ਵਰਤੋਂ ਨੂੰ ਨਾ ਫੈਲਾਓ ਜੋ ਬਾਅਦ ਵਿੱਚ ਤੋੜਣੀ ਪਏਗੀ।
ਸਧਾਰਣ marketing site ਜਾਂ ਇਕ ਅੰਦਰੂਨੀ ਟੂਲ—ਜਿੱਥੇ ਕੋਈ bundler, transpiler ਜਾਂ component framework ਨਹੀਂ—ਵਿੱਚ jQuery ਅਜੇ ਵੀ ਇੱਕ ਸੁਵਿਧਾਜਨਕ "ਇਕ ਸਿਰਫ਼ ਸਕ੍ਰਿਪਟ ਟੈਗ" ਹੈਲਪਰ ਹੋ ਸਕਦਾ ਹੈ। ਜਦ ਤੁਸੀਂ ਕੁਝ interactions (toggle menus, ਸਾਦੇ form ਭੈਵਿਯਰ) ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ build pipeline ਨਹੀਂ ਲਾਉਣਾ ਚਾਹੁੰਦੇ, ਤਾਂ ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਮਦਦਗਾਰ ਹੈ।
ਕਈ ਮੱਚਰ plugin (date pickers, tables, lightboxes) jQuery 'ਤੇ ਬਣੇ ਹੋਏ ਹਨ। ਜੇ ਕੋਈ ਪੁਰਾਣਾ plugin ਬਿਜ਼ਨਸ ਲਈ ਅਹੰਕਾਰਪੂਰਕ ਅਤੇ ਸਥਿਰ ਹੈ, ਤਾਂ jQuery ਨੂੰ dependency ਵਜੋਂ ਰੱਖਣਾ ਸਭ ਤੋਂ ਘੱਟ‑ਖ਼ਤਰੇ ਵਾਲਾ ਵਿਕਲਪ ਹੋ ਸਕਦਾ ਹੈ।
ਕਿਸੇ ਨਿਰਣੈ ਤੋਂ ਪਹਿਲਾਂ, ਦੇਖੋ ਕਿ ਕੀ ਕੋਈ maintained, non-jQuery ਵਿਕਲਪ ਮੌਜੂਦ ਹੈ—ਜਾਂ plugin ਨੂੰ ਅੱਪਗਰੇਡ ਕਰਨ ਨਾਲ ਕੀ ਸਾਰਾ ਰਿਵ੍ਰਾਈਟ ਲਾਜ਼ਮੀ ਹੋ ਜਾਵੇਗਾ।
jQuery ਤੋਂ ਹਟਣਾ ਜ਼ਿਆਦਾਤਰ ਤੌਰ 'ਤੇ ਇੱਕ ਵੱਡੇ ਰੀਵ੍ਰਾਈਟ ਬਾਰੇ ਨਹੀਂ, ਸਗੋਂ ਆਹਿਸਟਾ‑ਆਹਿਸਟਾ dependency ਘਟਾਉਣ ਬਾਰੇ ਹੈ ਬਿਨਾਂ ਲੋਕਾਂ ਦੇ ਭਰੋਸੇਯੋਗ ਵਿਹੈਵਿਅਰ ਨੂੰ ਤੋੜੇ। ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਇੰਕ੍ਰੀਮੈਂਟਲ ਹੈ: ਪੇਜ਼ਾਂ ਨੂੰ ਕੰਮ ਕਰਦੇ ਹੋਏ ਰੱਖੋ ਜਦ ਤੁਸੀਂ ਹੇਠਾਂ ਟੁਕੜੇ ਬਦਲ ਰਹੇ ਹੋ।
ਤਿੰਨ ਪ੍ਰਾਇਕਟੀਕਲ ਸਵਾਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਇਹ ਆਡਿਟ ਤੁਹਾਨੂੰ ਬਿਨਾ ਲੋੜ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਬਦਲਣ ਤੋਂ ਰੋਕੇਗਾ ਅਤੇ ਚੁੱਕੀਆਂ ਹੋਈਆਂ ਡੀਪੈਂਡੈਂਸੀਜ਼ ਨੂੰ ਪਕੜੇਗਾ ਜਿਵੇਂ ਇੱਕ plugin ਜੋ ਗੁਪਤ ਤੌਰ 'ਤੇ $.ajax() ਵਰਤਦਾ ਹੈ।
ਅਕਸਰ ਟੀਮਾਂ ਸਭ ਤੋਂ ਤੇਜ਼ ਨਤੀਜੇ ਇਕੱਠੇ ਸੌਖੇ ਪੈਟਰਨ ਬਦਲ ਕੇ ਪਾਉਂਦੀਆਂ ਹਨ:
$(".card") → document.querySelectorAll(".card").addClass() / .removeClass() → classList.add() / classList.remove().on("click", ...) → addEventListener("click", ...)ਇਹ ਛੋਟੀਆਂ PRs ਵਿੱਚ ਕਰੋ ਤਾਂ ਕਿ Review ਆਸਾਨ ਰਹੇ ਅਤੇ Rollback ਵੀ ਆਸਾਨ ਹੋਵੇ।
ਜੇ ਤੁਸੀਂ $.ajax() ਵਰਤਦੇ ਹੋ, ਤਾਂ ਉਹ calls ਇੱਕ-ਇਕ endpoint fetch() (ਜਾਂ ਇੱਕ ਛੋਟਾ HTTP helper) 'ਤੇ ਮਾਈਗ੍ਰੇਟ ਕਰੋ। Response shapes ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਰੱਖੋ ਤਾਂ ਜੋ UI ਨੂੰ ਤੁਰੰਤ ਬਦਲਣ ਦੀ ਲੋੜ ਨਾ ਪਏ।
// jQuery
$.ajax({ url: "/api/items", method: "GET" }).done(renderItems);
// Modern JS
fetch("/api/items")
.then(r => r.json())
.then(renderItems);
jQuery ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਜਿੱਥੇ ਜ਼ਰੂਰੀ ਹੋ ਉਥੇ ਕਵਰੇਜ ਜੋੜੋ: ਮੁੱਖ ਯੂਜ਼ਰ ਫਲੋਜ਼, ਫਾਰਮ ਸਮਰਪਣ ਅਤੇ ਕੋਈ ਵੀ ਡਾਇਨਾਮਿਕ UI। ਹਲਕੀਆਂ ਜਾਂਚਾਂ (Cypress smoke tests ਜਾਂ QA ਚੈਕਲਿਸਟ) ਵੀ ਰੈਗ੍ਰੈਸ਼ਨਜ਼ ਨੂੰ ਜਲਦੀ ਫੜ ਸਕਦੀਆਂ ਹਨ। ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ, ਬਦਲਾਅਾਂ ਨੂੰ ਫੀਚਰ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਸ਼ਿਪ ਕਰੋ ਅਤੇ analytics/error rates ਨੂੰ ਸਥਿਰ ਰੱਖੋ।
ਜਦ ਤੁਸੀਂ ਵੱਧ ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰਨਾਂ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ tooling ਵਰਤੋ ਜੋ snapshots ਅਤੇ rollback ਸਹਾਇਤਾ ਦੇਵੇ। ਉਦਾਹਰਨ ਲਈ, legacy front ends ਨੂੰ ਆਧੁਨਿਕ ਕਰਨ ਵਾਲੀਆਂ ਟੀਮਾਂ ਕੁਝ ਵਾਰ Koder.ai ਵਰਗੇ platforms 'ਤੇ prototype ਬਣਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਆਪਣੇ snapshots/rollback ਵਰਕਫਲੋ ਨਾਲ iterate ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਜੋ "ਜਾਣਿਆ-ਪਛਾਣਿਆ" ਵਰਜਨ ਲੁੱਟਣਾ ਨਾ ਪੈਵੇ।
ਜੇ ਤੁਸੀਂ ਸਮੁੱਚੇ ਯੋਜਨਾ ਨੂੰ ਆਯੋਜਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ /blog/jquery-vs-vanilla-js ਦੀ ਤੁਲਨਾ ਬੇਸਲਾਈਨ ਵਰਗੇ ਰੈਫਰੰਸ ਵਰਤ ਸਕਦੇ ਹੋ।
jQuery ਤੋਂ ਦੂਰੀ ਬਣਾ ਰਹਿਣ ਅਕਸਰ "ਸਿੰਟੈਕਸ ਬਦਲਣਾ" ਤੋਂ ਵੱਧ assumptions ਨੂੰ ਖੋਲ੍ਹਣ ਬਾਰੇ ਹੁੰਦਾ ਹੈ ਜੋ ਸਾਲਾਂ ਤੋਂ ਇਕੱਠੇ ਹੋਏ। ਇਹ ਰੁਕਾਵਟਾਂ ਹਨ ਜੋ ਟੀਮਾਂ ਨੂੰ ਹੌਲਾ ਕਰਦੀਆਂ ਹਨ—ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਬਚਣ ਦੇ ਤਰੀਕੇ:
ਪੂਰਾ ਰੀਰਾਈਟ ਸੁਚੱਜਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਹ ਲੰਬੀ-ਦੌੜੀ ਸ਼ਾਖ਼, ਬਹੁਤ ਸਾਰੀਆਂ ਰੈਗ੍ਰੈਸ਼ਨਜ਼, ਅਤੇ ਅਧੂਰੇ ਕੰਮ ਦੇ ਦਬਾਅ ਦਾ ਕਾਰਣ ਬਣਦਾ ਹੈ। ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਇੰਕ੍ਰੀਮੈਂਟਲ ਹੈ: ਇੱਕ ਫੀਚਰ ਜਾਂ ਪੇਜ਼ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਬਦਲੋ, ਵਿਹੈਵਿਅਰ ਇਕੋ ਜਿਹਾ ਰੱਖੋ, ਅਤੇ ਟਚ ਕੀਤੇ ਹਿੱਸਿਆਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਟੈਸਟ ਜੋੜੋ।
ਜੇ ਤੁਸੀਂ React/Vue/Svelte (ਜਾਂ ਹਲਕਾ ਕੰਪੋਨੈਂਟ ਸਿਸਟਮ) ਲਿਆਉਂਦੇ ਹੋ ਜਦ ਕਿ jQuery ਅਜੇ ਵੀ ਓਸੇ DOM ਨੋਡਸ ਨੂੰ ਸਿੱਧਾ ਮੈਨਿਪੁਲੇਟ ਕਰ ਰਿਹਾ ਹੋਵੇ, ਤਾਂ ਤੁਹਾਨੂੰ "UI ਤਾਣ‑ਝਪਟ" ਮਿਲ ਸਕਦੀ ਹੈ: ਫਰੇਮਵਰਕ ਰੀ-ਰੈਂਡਰ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ jQuery ਬਦਲਾਅ ਉਤੇ ਲਿਖ ਲੈ ਜਾਂਦਾ ਹੈ, ਜਦ ਕਿ jQuery ਉਹਨਾਂ ਨੋਡਸ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ ਜੋ ਫਰੇਮਵਰਕ ਮੰਨਦਾ ਹੈ ਕਿ ਉਹਦਾ ਕੰਟਰੋਲ ਹੈ।
ਨਿਯਮ: ਇੱਕ ਸਪੱਸ਼ਟ ਸੀਮਾ ਰੱਖੋ। ਜਾਂ ਤਾਂ:
ਕਈ ਪੁਰਾਣੇ ਕੋਡ ਵਿਗਿਆਨਕ ਤੌਰ 'ਤੇ ਡੈਲੀਗੇਟ ਕੀਤੇ ਹੋਏ events ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ:
$(document).on('click', '.btn', handler)
ਨੈਟਿਵ DOM ਇਹ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਮੈਚਿੰਗ ਅਤੇ this/event.target ਦੀਆਂ ਉਮੀਦਾਂ ਬਦਲ ਸਕਦੀਆਂ ਹਨ। ਆਮ ਬੱਗਾਂ ਵਿੱਚ ਗਲਤ ਐਲੀਮੈਂਟ ਲਈ ਹੈਂਡਲਰ ਫਾਇਰ ਹੋਣਾ (ਕਿਉਂਕਿ nested icons/spans ਹਨ) ਜਾਂ ਜੋ ਡਾਇਨਾਮਿਕ ਤੌਰ 'ਤੇ ਜੋੜੇ ਗਏ ਆਈਟਮਾਂ ਲਈ ਹੈਂਡਲਰ ਫਾਇਰ ਨਾ ਹੋਣਾ ਕਿਉਂਕਿ ਲਿਸਨਰ ਗਲਤ ancestor 'ਤੇ ਲਾਇਆ ਗਿਆ ਸੀ। ਡੈਲੀਗੇਟ ਕੀਤੇ ਐਵੈਂਟ ਬਦਲਣ ਵੇਲੇ ਪੁਸ਼ਟੀ ਕਰੋ:
closest() ਅਕਸਰ ਲੋੜੀਂਦਾ)jQuery UI effects ਅਤੇ ਕਸਟਮ ਐਨੀਮੇਸ਼ਨਾਂ ਕਦੇ ਕਦੇ accessibility ਮੁੱਦਿਆਂ ਨੂੰ ਅਕਸਮਾਤ ਛੁਪਾਉਂਦੀਆਂ ਸੀ—ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਜਨਮ ਦਿੰਦੀਆਂ। ਜਦ ਤੁਸੀਂ fades, slides, ਅਤੇ toggles ਬਦਲਦੇ ਹੋ, ਤਦ ਇਹ ਮੁਦਿਆਂ ਨੂੰ ਮੁੜ-ਜਾਚੋ:
aria-expanded on disclosure buttons)prefers-reduced-motion)ਇਹ ਫੌਂਸੇ ਜਲਦੀ ਫੜ ਲਈਆਂ ਤਾਂ ਤੁਹਾਡੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੇਜ਼ ਹੋਵੇਗੀ ਅਤੇ UI ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਬਣੇਗਾ—ਇਹੋਂ ਪਹਿਲਾਂ ਕਿ ਆਖ਼ਰੀ $() ਦੂਰ ਹੋਵੇ।
jQuery "ਰੁਝਾਨੀ" ਨਹੀਂ ਹੈ। ਇਸਨੇ ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕੀਤੀਆਂ—ਖ਼ਾਸ ਕਰਕੇ ਜਦ browsers ਵੱਖ-ਵੱਖ ਵਿਹਾਰ ਕਰਦੇ ਸਨ ਅਤੇ ਇੰਟਰਐਕਟੀਵ ਪੇਜ ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਸਾਰਾ ਦੁਹਰਾਇਆ DOM ਕੋਡ ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ। ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਹੁਣ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੇ।
ਕੁਝ ਤਾਕਤਾਂ ਨੇ ਇਸਨੂੰ "ਡਿਫੌਲਟ ਚੋਣ" ਤੋਂ "ਲੈਗੇਸੀ ਡੀਪੈਂਡੈਂਸੀ" ਵੱਲ ਧੱਕਿਆ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਪੁਰਾਣੀ ਸਾਈਟ ਮੈਨਟੇਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ jQuery ਅਜੇ ਵੀ ਇੱਕ ਠੀਕ ਟੂਲ ਹੋ ਸਕਦਾ—ਖਾਸ ਕਰਕੇ ਛੋਟੇ ਫਿਕਸਾਂ, ਸਥਿਰ plugins, ਜਾਂ ਉਹਨਾਂ ਪੰਨਿਆਂ ਲਈ ਜੋ ਮੁੜ-ਤੇਰਕਣ ਨੂੰ ਹੱਕ ਨਹੀਂ ਦਿੰਦੇ। ਜੇ ਤੁਸੀਂ ਨਵੀਆਂ ਫੀਚਰਾਂ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ ਨੈਟਿਵ JavaScript ਨੂੰ ਪਹਿਲ ਦਿਓ ਅਤੇ ਸਿਰਫ਼ ਉਹਥੇ jQuery ਰੱਖੋ ਜਿੱਥੇ ਇਹ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੋਵੇ।
ਸਿੱਖਣ ਜਾਰੀ ਰੱਖਣ ਲਈ ਜੋ ਕੰਮ ਨਾਲ ਮੈਪ ਹੁੰਦਾ ਹੈ, ਇਨ੍ਹਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਆਧੁਨਿਕ ਕਰਨ ਦੀ ਸੁਚਨਾ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਟੂਲ ਵੇਖੋ ਜੋ ਤੁਹਾਨੂੰ ਇੰਕ੍ਰੀਮੈਂਟਲ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। Koder.ai ਇਸ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਵੇਰਵਾ ਦੇ ਸਕਦੇ ਹੋ, ਇੱਕ React-based UI ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ Go/PostgreSQL ਬੈਕਐਂਡ ਬਣਾ ਸਕਦੇ ਹੋ, ਅਤੇ ਜਦ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਟੂਲਿੰਗ ਜਾਂ ਸਹਾਇਤਾ ਵਿਕਲਪਾਂ ਦੀ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਥੇ ਵਿਕਲਪ ਵੇਖ ਸਕਦੇ ਹੋ: /pricing
jQuery ਇੱਕ JavaScript ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ ਆਮ browser ਕਾਰਜ ਜਿਵੇਂ ਐਲੀਮੈਂਟ ਚੁਣਨਾ, ਇਵੈਂਟ ਹੈਨਡਲ ਕਰਨਾ, Ajax ਬੇਨਤੀਆਂ ਭੇਜਣਾ ਅਤੇ ਬੁਨਿਆਦੀ ਇਫੈਕਟ (show/hide, fades, slides) ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ। ਇਸਦੀ ਵਿਸ਼ੇਸ਼ ਪੈਟਰਨ $() ਵਰਤਣਾ ਹੈ ਜੋ ਐਲੀਮੈਂਟ ਲੱਭਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਚੇਨ ਕੀਤੇ ਗਏ ਕਮਾਂਡ ਚਲਾਓਣ ਦੀ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ।
$ ਇੱਕ ਸਿਰਫ਼ ਸ਼ੌਰਟਕਟ ਫੰਕਸ਼ਨ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ jQuery ਵੱਲੋਂ ਦਿੱਤਾ ਜਾਂਦਾ) ਜੋ ਪੇਜ ਵਿੱਚ ਐਲੀਮੈਂਟ ਲੱਭਦਾ—ਇਹ document.querySelectorAll() ਵਾਂਗ ਕੰਮ ਕਰਦਾ—ਅਤੇ ਇੱਕ jQuery ਆਬਜੈਕਟ ਰੀਟਰਨ ਕਰਦਾ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਮੈਥਡ ਚੇਨ ਕਰ ਸਕਦੇ ਹੋ。
ਜੇ ਤੁਸੀਂ ਪੁਰਾਣੇ ਕੋਡ ਵਿੱਚ $() ਵੇਖਦੇ ਹੋ, ਤਾਂ ਇਸਦਾ ਅਰਥ ਆਮ ਤੌਰ 'ਤੇ "ਕੁਝ ਚੁਣੋ, ਫਿਰ ਉਸ ਨਾਲ ਕੁਝ ਕਰੋ" ਹੁੰਦਾ ਹੈ।
ਇਹ ਲੋਕਪ੍ਰਿਯ ਹੋਇਆ ਕਿਉਂਕਿ ਇਸ ਨੇ ਅਸਥਿਰ browser ਵਰਤਾਰੇ ਨੂੰ ਇੱਕ ਸਥਿਰ ਅਤੇ ਨਿਰਭਰਯੋਗ API ਵਿੱਚ ਮੋੜ ਦਿੱਤਾ। ਸ਼ੁਰੂਆਤੀ ਦਿਨਾਂ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਕੰਮ ਜਿਵੇਂ events, DOM traversal, ਅਤੇ Ajax ਲਈ browser-ਵਿਸ਼ੇਸ਼ حل ਲੋੜੀਂਦੇ ਸਨ।
jQuery ਨੇ ਇੱਕ ਇੱਕਸਾਰ API ਦਿੱਤੀ ਤਾਂ ਜੋ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਸੁਚੇਤ ਰੂਪ ਵਿੱਚ ਫੀਚਰ ਸ਼ਿਪ ਕਰ ਸਕਣ ਅਤੇ ਕਈ browser-ਵਿਸ਼ੇਸ਼ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚ ਸਕਣ।
ਜ਼ਿਆਦਾਤਰ ਇਸ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਆਧੁਨਿਕ browser ਅਤੇ JavaScript ਨੇ ਪਿਛੇ ਛੱਡ ਦਿੱਤਾ। ਅੱਜ ਤੁਸੀਂ ਅਕਸਰ ਕੁਲਸੀ jQuery ਟਾਸਕਾਂ ਨੂੰ ਬਿਲਟ-ਇਨ ਫੀਚਰ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹੋ:
querySelector / querySelectorAll ਚੁਣਾਈ ਲਈਨਹੀਂ। ਬਹੁਤ ਸਾਰੀਆਂ ਮੌਜੂਦਾ ਸਾਈਟਾਂ ਅਜੇ ਵੀ jQuery ਵਰਤਦੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਕੰਮ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ। "ਲੈਗੇਸੀ" ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਨਵੇਂ ਕੋਡਬੇਸز ਵਿੱਚ ਘੱਟ ਮਿਲਦੀ ਹੈ।
ਚਰਚਾ ਵਾਲਾ ਪ੍ਰਸ਼ਨ ਇਹ ਹੈ ਕਿ ਕੀ ਇਸਨੂੰ ਰੱਖਣਾ ਮੁਨਾਸਿਬ ਹੈ—ਪਰਫਾਰਮੈਂਸ, ਰੱਖ-ਰਖਾਵ ਅਤੇ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਡੀਪੈਂਡੈਂਸੀ (ਖਾਸ ਕਰਕੇ plugins) ਦੇ ਆਧਾਰ 'ਤੇ।
ਕਿਉਂਕਿ ਇਹ ਪੁਰਾਣੇ ਇਕੋ-ਸਿਰ ਸਿਸਟਮਾਂ ਵਿੱਚ ਗੂੰਥ ਗਿਆ—ਖਾਸ ਕਰਕੇ theme ਅਤੇ plugin ਕੋਡ। ਉਦਾਹਰਨ ਵਜੋਂ WordPress: ਕਈ themes ਅਤੇ plugins ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ front-end ਵਿਹੈਵਿਅਰ ਲਈ jQuery 'ਤੇ ਨਿਰਭਰ ਰਿਹਾ ਕਰਦੇ ਸਨ।
ਜੇ ਤੁਹਾਡੀ ਸਾਈਟ ਕਿਸੇ jQuery-ਮਾਤਰ plugin 'ਤੇ ਨਿਰਭਰ ਹੈ (sliders, date pickers, lightboxes, validators), ਤਾਂ jQuery ਹਟਾਉਣਾ ਅਕਸਰ plugin ਨੂੰ ਬਦਲਣ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਕੁਝ ਲਾਈਨਾਂ ਨੂੰ ਲਿਖਣ।
ਹਾਂ—ਕੁਝ ਪ੍ਰਯੋਗਿਕ ਹਾਲਾਤਾਂ ਵਿੱਚ jQuery ਰੱਖਣਾ ਸਭ ਤੋਂ ਵਿਆਵਹਾਰਿਕ ਚੋਣ ਹੋ ਸਕਦੀ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਸਮਾਂ, ਅਨੁਕੂਲਤਾ ਜਾਂ ਸਥਿਰਤਾ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿੰਦੇ ਹੋ:
ਇਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ, ਤਕਨੀਕੀ ਸ਼ੁੱਧਤਾ ਨਾਲੋਂ ਸਥਿਰਤਾ ਅਤੇ ਵੇਲਾਂ-ਚੁੱਕਣਾ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦਾ ਹੈ।
ਕੰਮ ਨੂੰ ਟੁੱਟਣ ਤੋਂ ਬਚਾਉਣ ਅਤੇ ਵਿਵਹਾਰ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ jQuery ਤੋਂ ਹੌਲੀ-ਹੌਲੀ ਦੂਰੀ ਬਣਾਉਣਾ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਹੈ। ਕੁਝ ਪ੍ਰਾਇਕਟੀਕਲ ਕਦਮ:
عام طور پر سب سے بڑا مسئلہ یہ ہوتا ہے کہ آپ سب کچھ ایک ساتھ ری رائٹ کرنے کی کوشش کریں۔ یہ لمبی شاخیں، بہت سی regression اور بنا مکمل کام کے دباؤ پیدا کر سکتا ہے۔ ایک محفوظ راستہ ہے آہستہ آہستہ: ایک فیچر یا صفحہ بیک وقت تبدیل کریں، رویے کو یکساں رکھیں، اور ٹچ کردہ حصوں کے آس پاس ٹیسٹ شامل کریں۔
ہاں—ایفیکٹس اور DOM ری رائٹس accessibility کو متاثر کر سکتی ہیں۔ جب آپ hide()/show() یا slide/fade برتاؤ تبدیل کرتے ہیں تو دوبارہ چیک کریں:
aria-expandedprefers-reduced-motion)رنگینی تبدیلیاں صرف بصری نہیں ہوتیں؛ وہ تعامل اور کی بورڈ فلو کو بھی متاثر کر سکتی ہیں۔
classListaddEventListener ਇਵੈਂਟਸ ਲਈfetch + async/await ਬੇਨਤੀਆਂ ਲਈਇਸ ਲਈ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਬੁਨਿਆਦੀ ਕੰਮਾਂ ਲਈ ਇੱਕ compatibility layer ਦੀ ਲੋੜ ਘੱਟ ਹੋ ਗਈ ਹੈ।
$.ajax() ਨੂੰ ਇੱਕ-ਇਕ endpoint fetch() ਤੇ ਪਰਵਰਤਿਤ ਕਰੋ।