John Resig ਦੀ jQuery ਨੇ JavaScript ਨੂੰ ਸਧਾਰਨ ਕੀਤਾ, ਬ੍ਰਾਉਜ਼ਰ quirks ਨੂੰ ਮਿਟਾਇਆ, ਅਤੇ ਉਹ ਪੈਟਰਨ ਪਸੰਦ ਕੀਤੇ ਜੋ ਸਾਲਾਂ ਤੱਕ ਫਰੰਟ‑ਐਂਡ ਟੂਲਾਂ 'ਤੇ ਅਸਰ ਕਰਨਗੇ। ਇਹ ਰਹੀ ਵੈੱਬ 'ਤੇ ਇਸਦਾ ਅਸਰ।
ਜੇ ਤੁਸੀਂ 2005–2008 ਦੇ ਆਸ‑ਪਾਸ ਵੈਬਸਾਈਟ ਬਣਾਉ ਰਹੇ ਸਨ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ “JavaScript ਲਿਖਦੇ” ਨਹੀਂ ਸੀ—ਤੁਸੀਂ ਬ੍ਰਾਉਜ਼ਰਾਂ ਨਾਲ ਵਵਹਾਰ ਕਰ ਰਹੇ ਹੁੰਦੇ।
ਇੱਕ ਸਧਾਰਣ ਫੀਚਰ—ਮੇਨੂ ਆਈਟਮ ਨੂੰ ਹਾਈਲਾਈਟ ਕਰਨਾ, ਮੋਡਲ ਦਿਖਾਉਣਾ, ਫਾਰਮ ਵੈਲਿਡੇਟ ਕਰਨਾ, ਬਿਨਾਂ ਪੂਰੇ ਰੀਫ੍ਰੈਸ਼ ਦੇ HTML ਲੋਡ ਕਰਨਾ—ਇਕ ਛੋਟੇ ਰਿਸਰਚ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਸੀ। ਤੁਸੀਂ ਵੇਖਦੇ ਕਿ ਕਿਹੜਾ ਮੈਥਡ ਕਿਸ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਹੈ, ਕਿਹੜਾ ਇਵੈਂਟ ਵੱਖਰਾ ਤਰੀਕੇ ਨਾਲ ਵਰਤਦਾ, ਅਤੇ ਕਿਉਂ ਇੱਕ DOM ਕਾਲ ਤੁਹਾਡੇ ਮਸ਼ੀਨ ਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਚਲਦੀ ਪਰ ਅੱਧੇ ਯੂਜ਼ਰਾਂ ਲਈ ਟੁੱਟ ਜਾਂਦੀ ਸੀ।
ਡਿਵੈਲਪਰ ਚਾਹੁੰਦੇ ਸਨ “ਲਿਖੋ ਇਕ ਵਾਰੀ, ਚਲਾਓ ਹਰ ਜਗ੍ਹਾ,” ਪਰ ਬ੍ਰਾਉਜ਼ਰ ਫਰਕਾਂ ਨੇ ਇਸਨੂੰ ਅਹਿਸਾਸ ਕਰਵਾਇਆ ਕਿ ਇਹ "ਤਿੰਨ ਵਾਰੀ ਲਿਖੋ, ਹਰ ਥਾਂ ਟੈਸਟ ਕਰੋ" ਵਰਗਾ ਹੈ। Internet Explorer ਦੇ ਆਪਣੇ quirks ਸਨ, Firefox ਅਤੇ Safari ਦੇ पुराने ਵਰਜਨ ਕਈ edge cases 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੁੰਦੇ, ਅਤੇ ਇਵੈਂਟ ਹੈਂਡਲਿੰਗ ਜਾਂ DOM ਮੈਨਿਪੁਲੇਸ਼ਨ ਵਰਗੀਆਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਵੀ ਗੈਰ-ਇਕਸਪੈਕਟਿਡ ਹੋ ਸਕਦੀਆਂ ਸਨ।
ਇਹ ਮਿਸਮੇਚ صرف ਸਮਾਂ ਖਰਚ ਨਹੀਂ ਸੀ—ਇਸ ਨੇ ਇਹ ਤੈਅ ਕਰਵਾਇਆ ਕਿ ਟੀਮਾਂ ਕੀ ਬਣਾਉਣ ਦੀ ਹਿੰਮਤ ਕਰਦੀਆਂ। ਇੰਟਰਐਕਟਿਵ UI ਸੰਭਵ ਸੀ, ਪਰ ਮਿਹਨਤ ਮਹਿੰਗੀ ਅਤੇ ਮੈਨਟੇਨੈਂਸ ਵਿੱਚ ਨਾਜ਼ੁਕ ਸੀ। ਬਹੁਤ ਸਾਈਟਾਂ ਉਹਨਾਂ ਦੀ ਲੋੜ ਤੋਂ ਸਧਾਰਨ ਰਹਿ ਗਈਆਂ ਕਿਉਂਕਿ ਬ੍ਰਾਉਜ਼ਰਾਂ 'ਤੇ ਠੀਕ ਕੰਮ ਕਰਨ ਦੀ ਲਾਗਤ ਵੱਧ ਸੀ।
jQuery, ਜੋ John Resig ਦੁਆਰਾ ਬਣਾਈ ਗਈ, ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿ ਇਸ ਨੇ ਰੋਜ਼ਾਨਾ ਕਾਰਜਾਂ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ: ਐਲੇਮੈਂਟ ਚੁਣਨਾ, ਯੂਜ਼ਰ ਦੀ ਕਾਰਵਾਈਆਂ 'ਤੇ ਰੀਐਕਟ ਕਰਨਾ, ਪੰਨਾ ਬਦਲਣਾ, ਛੋਟੀ transitions animate ਕਰਨਾ ਅਤੇ AJAX ਬੇਨਤੀਆਂ ਕਰਨਾ। ਇਸ ਨੇ ਇੱਕ ਛੋਟਾ, ਪੜ੍ਹਨਯੋਗ API ਪੇਸ਼ ਕੀਤਾ ਜੋ ਬ੍ਰਾਉਜ਼ਰ ਫਰਕਾਂ ਨੂੰ ਸਮਤੋਲ ਕਰਦਾ ਸੀ ਤਾਂ ਕਿ ਤੁਸੀਂ ਫੀਚਰ ਬਣਾਉਣ 'ਤੇ ਵੱਧ ਸਮਾਂ ਲਗਾ ਸਕੋ ਅਤੇ ਪਲੇਟਫਾਰਮ ਨਾਲ ਲੜਨ 'ਤੇ ਘੱਟ।
ਅਮਲ ਵਿੱਚ, ਇਹ ਆਮ ਇੰਟਰਐਕਸ਼ਨਾਂ ਨੂੰ ਸਧਾਰਨ ਅਤੇ ਦੁਹਰਾਉਣਯੋਗ ਬਣਾਉਂਦਾ—ਉਹ ਕਿਛ ਜਿਹੜਾ ਤੁਸੀਂ ਸਿੱਖਾ ਸਕਦੇ, ਸਾਂਝਾ ਕਰ ਸਕਦੇ, ਅਤੇ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੇ।
ਕਹਾਣੀ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ jQuery ਸਮਾਂ ਬਚਾਉਂਦਾ ਸੀ। ਇਸਨੇ ਡਿਵੈਲਪਰਾਂ ਦੇ ਸੋਚਣ ਦੇ ਢੰਗ 'ਤੇ ਅਸਰ ਕੀਤਾ: chaining, ਸੰਖੇਪ selectors 'ਤੇ ਨਿਰਭਰ ਹੋਣਾ, ਇਵੈਂਟਾਂ ਦੇ ਆਧਾਰ 'ਤੇ UI ਕੋਡ ਨੂੰ ਆਯੋਜਿਤ ਕਰਨਾ, ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਤੋਂ ਇੱਕ ਸਥਿਰ “developer experience” ਦੀ ਉਮੀਦ ਕਰਨਾ। ਇਹ ਆਦਤਾਂ ਉਸke਼ ਟੂਲਾਂ ਨੂੰ ਰੂਪ ਦਿੱਤਾ ਜੋ ਬਾਅਦ ਵਿੱਚ ਆਏ—ਅਜਿਹੇ ਸਮੇਂ ਵਿੱਚ ਭਾਵੇਂ web standards ਅੱਗੇ ਵਧ ਗਏ ਅਤੇ ਨਵੇਂ ਫਰੇਮਵਰਕ ਤੁਹਾਡੇ ਉਪਰ ਚੜ੍ਹੇ।
ਇਹ “ਆਮ ਰਾਹ ਨੂੰ ਆਸਾਨ ਬਣਾਓ” ਵਾਲਾ ਮੈਨਡਸੈੱਟ ਅੱਜ ਦੀਆਂ ਟੂਲਿੰਗ ਵਿੱਚ ਵੀ ਮਿਲਦਾ ਹੈ। ਆਧੁਨਿਕ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਉਹੀ developer-experience ਸਿਧਾਂਤ ਵੱਖਰੇ ਲੇਅਰ 'ਤੇ ਲਗਾਉਂਦੇ ਹਨ—ਟੀਮਾਂ ਨੂੰ chat-ਚਲਾਏ workflow ਰਾਹੀਂ ਵੈਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦਿੰਦੇ—ਜਿੱਥੇ ਇਕ ਸਮੇਂ jQuery ਨੇ browser-facing UI ਕੋਡ ਨੂੰ ਸਨੇਹੀ ਅਤੇ ਪਹੁੰਚਯੋਗ ਬਣਾਇਆ।
John Resig ਮੂਢ ਵਿੱਚ ਕਿਸੇ ਆندੋਲਨ ਦੀ ਸ਼ੁਰੂਆਤ ਨਹੀਂ ਕਰ ਰਹੇ ਸਨ ਜਦੋਂ ਉਹ ਮਿਡ-2000 ਵਿੱਚ ਇੱਕ ਛੋਟੀ JavaScript ਮਦਦਗਾਰ ਲਾਇਬ੍ਰੇਰੀ 'ਤੇ ਹੱਥ ਤੇਜ਼ ਕਰ ਰਹੇ ਸਨ। ਉਹ ਇੱਕ ਕਾਰਜ ਕੀਤਾ ਡਿਵੈਲਪਰ ਸੀ ਜਿਸ ਨੂੰ ਉਹੀ friction ਮਹਿਸੂਸ ਹੁੰਦੀ ਸੀ ਜੋ ਹੋਰ ਹਰ ਕੋਈ ਮਹਿਸੂਸ ਕਰਦਾ ਸੀ: ਵੈੱਬ 'ਤੇ ਸਧਾਰਣ ਚੀਜ਼ਾਂ ਲਈ ਬਹੁਤ ਲੰਬਾ ਕੋਡ ਲੱਗਦਾ ਸੀ, ਅਚਾਨਕ ਬ੍ਰਾਉਜ਼ਰਾਂ ਵਿੱਚ ਟੁੱਟ ਜਾਂਦਾ ਸੀ, ਅਤੇ ਟੀਮਮੇਟਾਂ ਨੂੰ ਸਮਝਾਉਣਾ ਔਖਾ ਹੁੰਦਾ ਸੀ।
Resig ਦਾ ਮੁੱਖ ਉਦੇਸ਼ ਸਪੱਸ਼ਟਤਾ ਸੀ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਦਹਾਂ browser quirks ਯਾਦ ਕਰਨ ਦੀ ਬਜਾਏ, ਉਹ ਇੱਕ ਛੋਟਾ ਸੈੱਟ ਕਮਾਂਡ ਚਾਹੁੰਦੇ ਸਨ ਜੋ ਲੋਕਾਂ ਦੀ ਸੋਚ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ: “ਇਹ ਐਲੇਮੈਂਟ ਲੱਭੋ,” “ਇਸਨੂੰ ਬਦਲੋ,” “ਜਦ ਯੂਜ਼ਰ ਕਲਿਕ ਕਰੇ ਤਾਂ ਐਸਾ ਕਰੋ।” jQuery ਦਿਖਾਵੇ ਲਈ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ ਸੀ—ਇਹ ਰੋਜ਼ਾਨਾ ਚਿੰਤਾ ਘਟਾਉਣ ਅਤੇ ਆਮ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਰੇਲਿਜ਼ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ।
ਇਕੋ ਜਿੰਨੀ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ ਸੀ ਉਹ ਸੀ ਸਹਿਯੋਗ ਅਤੇ ਸਧਾਰਨ ਡਿਵੈਲਪਰ ਦੀ ਦ੍ਰਿਸ਼ਟੀ। ਬਹੁਤ ਲੋਕ ਜਾਨਚ-ਪੜਤਾਲ ਵਾਲੇ ਡੈਮੋ ਨਹੀਂ ਬਣਾਉਂਦੇ ਸਨ; ਉਹ ਮਾਰਕੀਟਿੰਗ ਸਾਈਟਾਂ, ਐਡਮਿਨ ਪੈਨਲ, ਅਤੇ ਪ੍ਰੋਡਕਟ ਪੰਨਿਆਂ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੁੰਦੇ। jQuery ਦਾ ਧਿਆਨ ਇੱਕ ਸੰਕੁਚਿਤ, ਪੜ੍ਹਨਯੋਗ API 'ਤੇ ਉਸ ਹਕੀਕਤ ਨੂੰ ਦਰਸਾਉਂਦਾ ਸੀ।
jQuery ਇਸ ਲਈ ਤੇਜ਼ ਫੈਲਿਆ ਕਿਉਂਕਿ ਇਹ ਸਿੱਖਣ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਅੱਗੇ ਪਹੁੰਚਾਉਣ ਵਿੱਚ ਆਸਾਨ ਸੀ। Resig ਨੇ talks ਅਤੇ demos ਕੀਤੇ ਜੋ ਤੁਰੰਤ ਫ਼ਾਇਦੇ ਦਿਖਾਉਂਦੇ ਸਨ, ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਨੇ ਤੁਰੰਤ ਵਧੀਆ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਅਤੇ ਮਿਲਣਯੋਗ ਉਦਾਹਰਣਾਂ ਲਈ ਇੱਕ ਚੰਗਾ ਨਾਮ ਬਣਾਇਆ। ਇਹ ਮੱਤਵਪੂਰਨ ਸਨ: ਜਦੋਂ ਕੋਈ ਟੂਲ ਤੁਹਾਨੂੰ ਸੱਚਾ ਸਮੱਸਿਆ ਪਿੰਜੜੇ ਵਿੱਚ ਕੁੱਝ ਮਿੰਟਾਂ 'ਚ ਠੀਕ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ, ਤਾਂ ਤੁਸੀਂ ਹੋਰ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਦੱਸਦੇ ਹੋ।
ਸ਼ੁਰੂਆਤੀ ਸਮੁਦਾਇ ਨੇ ਇਸ ਲੂਪ ਨੂੰ ਮਜਬੂਤ ਕੀਤਾ। ਲੋਕ snippets ਸਾਂਝੇ ਕਰਦੇ, plugins ਲਿਖਦੇ, ਅਤੇ ਉਹ ਬ੍ਰਾਉਜ਼ਰ ਅਤੇ ਡਿਵਾਈਸਾਂ ਦੇ edge cases ਰਿਪੋਰਟ ਕਰਦੇ ਜੋ Resig ਏਕੱਲਾ ਟੈਸਟ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ। jQuery ਲੋਕਾਂ ਦੀ ਫੀਡਬੈਕ ਨਾਲ ਪਬਲਿਕ ਰੂਪ ਵਿੱਚ ਵੱਧਿਆ, ਜਿਸ ਨਾਲ ਇਹ ਨਿਰਧਾਰਤ ਹੋਇਆ ਕਿ ਕੀ ਸਿਮਪਲ ਰਹੇਗਾ ਅਤੇ ਕੀ ਸੁਧਾਰਿਆ ਜਾਵੇ।
jQuery ਨੂੰ ਇੱਕ "ਜੀਨੀਅਸ ਮੋਮੈਂਟ" ਤੱਕ ਘਟਾਉਣਾ ਆਸਾਨ ਹੈ, ਪਰ ਸੱਚੀ ਕਹਾਣੀ ਜ਼ਿਆਦਾਤਰ ਲਗਾਤਾਰਤਾ ਅਤੇ ਵਧੀਆ ਫੈਸਲਿਆਂ ਦੀ ਹੈ: ਵਿਆਪਕ ਦਰਦ ਨੂੰ ਨੋਟ ਕਰਨਾ, ਰੋਜ਼ਾਨਾ ਕਾਰਜਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਨਾ, ਅਤੇ ਸਖਤੀ ਨਾਲ ਇਮਾਨਦਾਰੀ ਬਣਾ ਕੇ ਭਰੋਸਾ ਕਮਾਉਣਾ। Resig ਨੇ ਸਿਰਫ਼ ਕੋਡ ਨਹੀਂ ਲਿਖਿਆ—ਉਸਨੇ ਇੱਕ ਐਸਾ ਟੂਲ ਬਣਾਇਆ ਜੋ ਵੈੱਬ ਦੇ ਸੱਚੇ ਢੰਗ ਲਈ ਇੱਕ ਦੋਸਤਾਨਾ ਸ਼ਾਰਟਕੱਟ ਵਰਗਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਸੀ।
jQuery ਤੋਂ ਪਹਿਲਾਂ, “ਸਧਾਰਣ” ਇੰਟਰਐਕਟਿਵ बिहੇਵਿਅਰ ਲਿਖਣਾ ਅਕਸਰ ਬ੍ਰਾਉਜ਼ਰ-ਵਿਸ਼ੇਸ਼ ਟ੍ਰਿਕਸ ਦਾ ਇਕ ਢੇਰ ਬਣਾਉਣ ਵਾਲਾ ਕੰਮ ਹੁੰਦਾ। ਤੁਸੀਂ ਬੇਸ਼ੱਕ ਰਿਚ ਇੰਟਰਫੇਸ ਬਣਾ ਸਕਦੇ ਸਨ, ਪਰ ਲਾਗਤ ਸਮਾਂ, ਧੀਰਜ, ਅਤੇ ਕਾਫੀ ਟੈਸਟਿੰਗ ਹੁੰਦੀ।
ਅੱਜ, ਬਟਨ ਚੁੱਕਣਾ ਅਤੇ ਉਸਦਾ ਟੈਕਸਟ ਬਦਲਣਾ ਇੱਕ ਲਾਈਨ ਦਾ ਕੰਮ ਲੱਗਦਾ ਹੈ। ਉਸ ਸਮੇਂ, DOM ਚੋਣ ਅਸਮਰੱਥ ਅਤੇ ਝੜਪ ਭਰੀ ਸੀ। ਕੁਝ ਬ੍ਰਾਉਜ਼ਰਾਂ ਕੋਲ ਮਦਦਗਾਰ ਮੈਥਡ ਸਨ, ਹੋਰਾਂ ਕੋਲ ਨਹੀਂ, ਅਤੇ ਤੁਸੀਂ getElementById, getElementsByTagName, ਮੈਨੁਅਲ ਲੂਪ ਅਤੇ ਸਟਰਿੰਗ ਚੈੱਕ ਵਰਗੀਆਂ ਤਕਨੀਕਾਂ ਮਿਲਾ ਕੇ ਲਕੜੀ ਇकटਾ ਕਰ ਰਹੇ ਹੁੰਦੇ ਕਿ ਜਿਸ ਨਾਲ ਸਹੀ ਐਲੇਮੈਂਟ ਨੂੰ ਟਾਰਗੇਟ ਕੀਤਾ ਜਾ ਸਕੇ।
ਜਦੋਂ ਤੁਸੀਂ ਉਹ ਚੁਣ ਲੈਂਦੇ ਵੀ, ਤਾਂ ਅਕਸਰ ਤੁਹਾਨੂੰ ਕਲੈਕਸ਼ਨ ਸੰਭਾਲਣ, ਉਨ੍ਹਾਂ ਨੂੰ ਐਰੇ ਵਿੱਚ ਬਦਲਣ, ਜਾਂ ਝੱਟੇ edge cases ਦੇ ਕੰਮ ਕਰਨ ਲਈ ਵਾਧੂ ਕੋਡ ਲਿਖਣਾ ਪੈਂਦਾ।
ਕਲਿਕ ਹੈਂਡਲਰ, ਕੀ ਪ੍ਰੈੱਸ, ਅਤੇ hover ਪ੍ਰਭਾਵ ਆਮ ਲੋੜਾਂ ਸਨ—ਪਰ ਬ੍ਰਾਉਜ਼ਰ ਇਸ ਗੱਲ 'ਤੇ ਸਹਿਂਮਤ ਨਹੀਂ ਹੁੰਦੇ ਕਿ ਇਵੈਂਟ ਬਾਈਂਡਿੰਗ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਅਤੇ ਇਵੈਂਟ ਆਬਜੈਕਟ ਕਿਵੇਂ ਦਿਖਦਾ। ਇੱਕ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਬਿਲਕੁਲ ਠੀਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਕੋਡ ਦੂਜੇ ਵਿੱਚ ਸ਼ਾਂਤ ਢੰਗ ਨਾਲ ਫੇਲ ਹੋ ਸਕਦਾ ਸੀ।
ਡਿਵੈਲਪਰ normalization wrappers ਲਿਖਦੇ: “ਜੇ ਇਹ API ਮੌਜੂਦ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਵਰਤੋ; ਨਹੀਂ ਤਾਂ ਉਸਨੂੰ fallback ਕਰ ਦਿਓ।” ਇਸ ਦਾ ਅਰਥ ਹੋਰ ਕੋਡ, ਹੋਰ ਡੀਬੱਗਿੰਗ, ਅਤੇ ਹੋਰ ਬੱਗਾਂ ਲਈ ਹੋਰ ਦਰਵੇਜ਼ੇ ਬਣਣਾ ਸੀ।
Asynchronous ਬੇਨਤੀਆਂ ਸੰਭਵ ਸਨ, ਪਰ ਉਹ ਦੋਸਤੂਰ ਨਹੀਂ ਸਨ। XMLHttpRequest ਸੈਟਅਪ ਕਰਨ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਕਦਮ, ਵੱਖ-ਵੱਖ ਬ੍ਰਾਉਜ਼ਰ ਲਈ branching logic, ਅਤੇ response states ਦੀ ਧਿਆਨਪੂਰਵਕ ਸੰਭਾਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ।
ਇੱਕ ਛੋਟਾ ਫੀਚਰ—ਜਿਵੇਂ ਫਾਰਮ ਨੂੰ ਬਿਨਾਂ ਪੇਜ਼ ਰੀਲੋਡ ਕੀਤੇ submit ਕਰਨਾ—ਦਹਾਕੀ ਲਾਈਨਾਂ ਅਤੇ retries, error handling, ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ ਟੈਸਟਿੰਗ ਵਿੱਚ ਫੈਲ ਸਕਦਾ ਸੀ।
ਸਭ ਤੋਂ ਵੱਡੀ ਪੀੜਾ ਇਕ ਵਾਰੀ ਕੋਡ ਲਿਖਣ ਦੀ ਨਹੀਂ ਸੀ; ਇਹ ਸਾਰਾ ਕੁਝ ਹਰ ਥਾਂ ਚਲਾਣا ਸੀ। ਟੀਮਾਂ ਨੂੰ ਕੁਝ ਐਸਾ ਚਾਹੀਦਾ ਸੀ ਜੋ ਭਰੋਸੇਯੋਗ, ਸਿੱਖਣ ਵਿੱਚ ਆਸਾਨ, ਅਤੇ ਇੰਨਾ ਸਥਿਰ ਹੋ ਕਿ ਨਵੇਂ ਡਿਵੈਲਪਰ ਬਿਨਾਂ browser compatibility checklist ਯਾਦ ਕੀਤੇ ਯੋਗਦਾਨ ਦੇ ਸਕਣ। jQuery ਉਸ ਰੋਜ਼ਾਨਾ friction ਦਾ ਜਵਾਬ ਵਜੋਂ ਆਇਆ।
jQuery ਦੀ ਉਲੰਘਣਾ ਕੋਈ ਨਵੀਂ ਬ੍ਰਾਉਜ਼ਰ ਸਮਰੱਥਾ ਨਹੀਂ ਸੀ—ਇਹ ਦਿਨ-ਪਰ-ਦਿਨ UI ਕੰਮਾਂ ਬਾਰੇ ਸੋਚਣ ਦਾ ਨਵਾਂ ਤਰੀਕਾ ਸੀ। ਬ੍ਰਾਉਜ਼ਰ-ਵਿਸ਼ੇਸ਼ JavaScript ਲਿਖਣ ਦੀ ਬਜਾਏ ਤਾਂ ਕਿ ਐਲੇਮੈਂਟ ਲੱਭੋ, ਉਸਨੂੰ ਅੱਪਡੇਟ ਕਰੋ, ਅਤੇ ਇਵੈਂਟ ਵਾਇਰ ਕਰੋ, jQuery ਨੇ ਰੋਜ਼ਾਨਾ ਰੱਨੀਤੀ ਨੂੰ ਇਕ ਸਧਾਰਨ ਪੈਟਰਨ 'ਤੇ ਸੰਕੁਚਿਤ ਕੀਤਾ: ਕੁਝ ਲੱਭੋ, ਫਿਰ ਉਸ ਉੱਤੇ ਕੁਝ ਕਰੋ।
ਕੇਂਦਰ ਵਿੱਚ $() ਫੰਕਸ਼ਨ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ CSS-ਨੁਮਾ ਸਿਲੇਕਟਰ (ਜਾਂ ਇੱਕ ਐਲੇਮੈਂਟ) ਪਾਸ ਕਰਦੇ ਹੋ, ਅਤੇ ਤੁਸੀਂ ਇੱਕ jQuery ਆਬਜੈਕਟ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ—ਮੈਚ ਹੋਏ ਐਲੇਮੈਂਟਾਂ ਦੇ ਆਸਾਨ-ਉਪਯੋਗ wrapper।
ਉੱਥੋਂ, ਤੁਸੀਂ ਉਹ ਮੈਥਡ ਕਾਲ ਕਰਦੇ ਹੋ ਜੋ ਟਾਸਕ ਵਾਂਗ ਪੜ੍ਹਨ ਵਿੱਚ ਆਉਂਦੇ ਹਨ: ਇੱਕ ਕਲਾਸ ਜੋੜੋ, ਇੱਕ ਐਲੇਮੈਂਟ ਛੁਪਾਓ, ਟੈਕਸਟ ਬਦਲੋ, ਇੱਕ ਕਲਿਕ ਹੈਂਡਲਰ ਜੋੜੋ। ਮਕਸਦ ਹਰ ਨੀਵੇਂ ਤਫਸੀਲ ਨੂੰ ਬੇਨਤ ਕਰਨ ਦਾ ਨਹੀਂ ਸੀ; ਇਹ ਇਹ ਕਵਰ ਕਰਨਾ ਸੀ ਜੋ 80% UI ਕੰਮਾਂ ਲਈ ਲੋੜੀਂਦਾ ਸੀ।
jQuery ਇੱਕ fluent ਅੰਦਾਜ਼ ਨੂੰ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਹਰ ਕਦਮ ਇੱਕੋ jQuery ਆਬਜੈਕਟ ਰਿਟਰਨ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਇਕ readable line ਵਿੱਚ ਕਈ ਕਾਰਵਾਈਆਂ "chained" ਕਰ ਸਕਦੇ ਹੋ:
$(".notice")
.addClass("active")
.text("Saved!")
.fadeIn();
ਭਾਵੇਂ ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਕੰਮਕਾਜ ਨੂੰ ਸਮਝਦੇ ਨਾ ਹੋ, ਤੁਸੀਂ ਕਹਾਣੀ ਸਮਝ ਸਕਦੇ ਹੋ: notices ਲੱਭੋ, ਉਹਨਾਂ ਨੂੰ active ਬਣਾਓ, ਸੁਨੇਹਾ ਸੈਟ ਕਰੋ, ਦਿਖਾਓ।
jQuery ਤੋਂ ਪਹਿਲਾਂ, ਡਿਵੈਲਪਰ ਲਗਾਤਾਰ ਪੁੱਛਦੇ: “ਕਿਹੜਾ ਮੈਥਡ ਇਸ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਕੰਮ ਕਰੇਗਾ?” ਜਾਂ “ਕੀ ਇਸ property ਦਾ ਨਾਮ ਪੁਰਾਣੇ ਵਰਜਨਾਂ ਵਿੱਚ ਵੱਖਰਾ ਹੈ?” jQuery ਨੇ ਇਹਨਾਂ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਇੱਕ ਸਥਿਰ ਮੈਥਡ ਸੈੱਟ ਅਤੇ ਪੂਰਵਾਨੁਮਾਨ ਯੋਗ ਵਿਵਹਾਰ ਨਾਲ ਦਿੱਤਾ। ਮੀਆਂ ਨਵੇਂ ਲੋਕ JavaScript ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਸਕਦੇ ਸਨ ਬਿਨਾਂ edge cases ਨਾਲ ਪਿੱਠੇ। ਪ੍ਰੋਫੈਸ਼ਨਲਜ਼ ਨੂੰ ਤੇਜ਼ੀ ਮਿਲੀ: ਘੱਟ custom helper functions, ਘੱਟ compatibility hacks, ਅਤੇ ਘੱਟ ਕੋਡ ਰਿਵਿਊ ਦੀ ਲੋੜ।
ਕਿਉਂਕਿ API ਸੰਕੁਚਿਤ ਸੀ ਅਤੇ ਮੈਥਡ ਨਾਮ UI ਇਰਾਦਿਆਂ ਨਾਲ ਮਿਲਦੇ ਸਨ, jQuery ਟੀਮਾਂ ਨੂੰ ਉਹਨਾਂ ਸਕ੍ਰਿਪਟਾਂ ਵੱਲ ਧੱਕ ਦਿੱਤਾ ਜੋ ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦੀਆਂ। ਵਿਖਰੇ DOM ਕਾਲਾਂ ਅਤੇ ਅਸਥਾਈ ਵੈਰੀਐਬਲਾਂ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਕੋਡ ਨੂੰ UI ਅਦਾਇਗੀ ਦੇ ਕਦਮਾਂ ਵਜੋਂ ਪੜ੍ਹ ਸਕਦੇ—ਫਰੰਟ-ਐਂਡ ਕੰਮ ਨੂੰ ਇੱਕ ਕਥਾ ਜਿਹੇ ਬਣਾਉਂਦਾ, ਨਾ ਕਿ browser ਨਾਲ ਜੰਗ।
jQuery ਦੀ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਸੀ ਕਿ ਕਿਸੇ UI ਟਾਸਕ ਦਾ ਪਹਿਲਾ ਕਦਮ—ਸਹੀ ਐਲੇਮੈਂਟ ਲੱਭਣਾ—ਸਭ ਤੋਂ ਆਸਾਨ ਹੋ ਗਿਆ। ਬ੍ਰਾਉਜ਼ਰ-ਖਾਸ DOM ਮੈਥਡਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ quirks ਯਾਦ ਰੱਖਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਕੁਝ ਐਸਾ ਲਿਖ ਸਕਦੇ ਸੀ ਜੋ CSS ਵਰਗਾ ਦਿਖਦਾ ਅਤੇ ਤੁਰੰਤ ਸਮਝ ਆ ਜਾਂਦਾ।
ਡਿਜ਼ਾਇਨਰ ਅਤੇ ਫਰੰਟ-ਐਂਡ ਡਿਵੈਲਪਰ ਪਹਿਲਾਂ ਹੀ selectors ਵਿੱਚ ਸੋਚਦੇ ਸਨ: “header ਵਿੱਚ ਸਾਰੇ .buttons ਲੱਗਣਗੇ,” “ਪਹਿਲੇ ਆਈਟਮ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਓ,” “ਕਿਸੇ ਕਿਸਮ ਦੇ ਇਨਪੁੱਟ ਲੱਭੋ।” jQuery ਨੇ ਉਸ ਮਾਨਸਿਕ ਮਾਡਲ ਨੂੰ JavaScript ਟੂਲ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ:
$(".nav a") ਨਾਲ navigation ਵਿੱਚ ਲਿੰਕਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ$("#signup-form input[type=email]") ਇੱਕ ਖਾਸ ਫੀਲਡ ਲੱਭਣ ਲਈ$("ul li:first") ਤੁਰੰਤ “ਪਹਿਲਾ ਆਈਟਮ” ਲਾਜ਼ਮੀ ਕਾਰਵਾਈ ਲਈਇਹ ਪੜ੍ਹਨਯੋਗਤਾ ਮੈਟ翻 翻
$(selector) ਦੇ ਪਿੱਛੇ Sizzle ਸੀ, jQuery ਦਾ selector engine। ਸ਼ੁਰੂਆਤੀ ਬ੍ਰਾਉਜ਼ਰ ਚੱਲਦਾ-ਫਿਰਦਾ ਨਹੀਂ ਸੀ ਕਿ ਕੁਝ selectors ਕਿਵੇਂ ਵਰਤਣੇ ਜਾਣ, ਅਤੇ ਕੁਝ ਪੂਰੇ ਸੈੱਟ ਨੂੰ ਸਹਾਰਾ ਨਹੀਂ ਦਿੰਦੀਆਂ। Sizzle ਇੱਕ ਸਥਿਰ ਵਿਆਖਿਆ ਅਤੇ fallback ਮੁਹੱਈਆ ਕਰਵਾਉਂਦਾ ਸੀ, ਤਾਂ ਜੋ $(".card > .title") ਕਿਸੇ ਬ੍ਰਾਉਜ਼ਰ ਬਰਾਬਰ ਇੱਕ ਲਾਟਰੀ ਨਾ ਬਣੇ।
ਨਤੀਜਾ ਰੀਅਲ ਉਤਪਾਦਕਤਾ ਸੀ: ਘੱਟ conditional branches, ਘੱਟ "ਜੇ IE ਤਾਂ..." ਵਰਕਅਰਾਊਂਡ, ਅਤੇ ਘੱਟ ਸਮਾਂ selector ਇਸ ਲਈ ਕੰਮ ਨਹੀਂ ਕਰ ਰਹੇ ਇਸਦੀ ਡੀਬੱਗਿੰਗ ਵਿੱਚ।
Selector ਸ਼ਕਤੀ ਨੇ ਵੀ ਲਾਗਤ छੁਪਾ ਦਿੱਤੀ:
ਫਿਰ ਵੀ, ਦਿਨ-ਪਰ-ਦਿਨ ਇੰਟਰਫੇਸ ਕੰਮ ਲਈ, "ਲੱਭੋ" ਆਸਾਨ ਹੋਣਾ ਇੱਕ ਵੱਡਾ ਬਦਲਾਅ ਸੀ—ਅਤੇ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਕਿ jQuery ਇਕ ਤਾਕਤਵਰ ਯੰਤਰ ਵਾਂਗ ਲੱਗੀ।
ਕਈ ਡਿਵੈਲਪਰਾਂ ਲਈ, jQuery "ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ" ਨਹੀਂ ਸੀ—ਇਹ روزانہ ਦੀਆਂ ਟੂਲਾਂ ਦਾ ਸੈੱਟ ਸੀ ਜੋ ਤੁਸੀਂ ਇੰਟਰਐਕਸ਼ਨਾਂ ਬਣਾਉਣ ਵੇਲੇ ਹੱਥ ਪਾ ਕੇ ਲੈਂਦੇ। ਇਸ ਨੇ ਆਮ UI ਕੰਮਾਂ ਨੂੰ ਕੁਝ ਪੇਸ਼ਗੋਈ ਯੋਗ ਕਾਲਾਂ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ, ਭਾਵੇਂ ਬ੍ਰਾਉਜ਼ਰ ਵੇਰਵੇ 'ਤੇ ਅਸਹਿਮਤ ਹੁੰਦੇ।
jQuery ਤੋਂ ਪਹਿਲਾਂ, ਕਲਿਕ ਹੈਂਡਲਰ ਜੋੜਨਾ ਵੱਖ-ਵੱਖ ਇਵੈਂਟ ਮਾਡਲਾਂ ਅਤੇ ਅਜੀਬ edge cases ਨਾਲ jongle ਕਰਨਾ ਹੋ ਸਕਦਾ ਸੀ। jQuery ਦੀ .on() (ਅਤੇ ਪਹਿਲਾਂ .bind()/.click()) ਨੇ ਯੂਜ਼ਰ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸੁਣਨ ਲਈ ਇੱਕ ਸਥਿਰ ਤਰੀਕਾ ਦਿੱਤਾ: click, submit, ਅਤੇ ਕੀਬੋਰਡ ਇਨਪੁੱਟ ਵਰਗੀਆਂ।
ਇਹ "page ready" 'ਤੇ ਕੋਡ ਚਲਾਉਣ ਨੂੰ ਵੀ ਸਪੱਸ਼ਟ ਬਣਾਉਂਦਾ ਸੀ:
$(function () {
// safe to touch the DOM
});
ਇਸ ਇੱਕ ਆਦਤ ਨੇ ਆਮ ਪੰਨਿਆਂ ਲਈ timing bugs ਘਟਾ ਦਿੱਤੇ—ਹੁਣ ਇਹ ਸੁਝਣ ਨਹੀਂ ਰਹਿੰਦਾ ਸੀ ਕਿ ਐਲੇਮੈਂਟ ਮੌਜੂਦ ਹਨ ਜਾਂ ਨਹੀਂ।
jQuery ਦਾ DOM API ਜਾਣਬੂਝ ਕੇ ਛੋਟਾ ਅਤੇ ਪ੍ਰਾਇਕਟਿਕਲ ਰੱਖਿਆ ਗਿਆ ਸੀ। ਕੰਟੈਂਟ ਅਪਡੇਟ ਕਰਨੀ ਹੋਵੇ ਤਾਂ .text() ਜਾਂ .html()। UI ਟੁਕੜੇ ਬਣਾਉਣ ਲਈ ('<div>...</div>') ਅਤੇ .append()। ਵਿਜ਼ੂਅਲ ਸਥਿਤੀਆਂ ਲਈ .addClass(), .removeClass(), ਅਤੇ .toggleClass()।
className, attribute quirks, ਅਤੇ inconsistent node methods ਦੇ ਫਰਕ ਨੂੰ ਹੇਠਾਂ ਰੱਖ ਕੇ ਡਿਵੈਲਪਰ ਉਹ ਕੰਮਾਂ ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਜੋ ਉਹ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਸਨ।
ਬਿਲਟ-ਇਨ animations ਜਿਵੇਂ .hide(), .show(), .fadeIn(), ਅਤੇ .slideToggle() ਨੇ ਪੰਨਿਆਂ ਨੂੰ ਘੱਟ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਜੀਵੰਤ ਮਹਿਸੂਸ ਕਰਵਾਇਆ। ਡਿਜ਼ਾਇਨਰਾਂ ਨੂੰ ਇਹ ਪਸੰਦ ਆਏ, stakeholder ਨੇ ਨੋਟ ਕੀਤਾ, ਅਤੇ tutorials ਨੇ ਇਨ੍ਹਾਂ ਨੂੰ ਬਹੁਤ ਵਰਤਿਆ।
ਨੁਕਸ: ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਅਤਿ-ਵਰਤੋਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ—ਬਹੁਤ ਸਾਰੀਆਂ fades ਅਤੇ slides ਇੰਟਰਫੇਸ ਨੂੰ ਧੀਮਾ ਜਾਂ ਗਿਮਿਕੀ ਬਣਾਉਂਦੇ। ਫਿਰ ਵੀ, ਆਮ ਇੰਟਰਐਕਸ਼ਨਾਂ (menus, accordions, notifications) ਲਈ, jQuery ਨੇ "ਪਾਲਿਸ਼ਡ" ਲੱਗਣ ਦੀ ਰੁਕਾਵਟ ਘੱਟ ਕੀਤੀ।
ਇਵੈਂਟਸ, DOM ਬਦਲ, ਅਤੇ ਪ੍ਰਭਾਵਾਂ ਵਿੱਚ ਅਸਲ ਜਿੱਤ ਸੀ ਸਾਦਗੀ: ਰੋਜ਼ਾਨਾ ਕੰਮਾਂ ਵਿੱਚ ਘੱਟ edge cases, ਅਤੇ ਇਕ ਸਾਂਝਾ ਕੀਤੇ ਗਏ ਪੈਟਰਨ ਜਿਸਨੂੰ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖ ਸਕਦੀ ਸੀ।
jQuery ਤੋਂ ਪਹਿਲਾਂ, “AJAX” ਇੱਕ trick ਵਾਂਗ ਲੱਗਦਾ ਸੀ: ਪੰਨਾ ਬਿਨਾਂ ਰੀਲੋਡ ਕੀਤੇ ਕੁਝ ਅਪਡੇਟ ਕਰੋ। ਸਾਫ਼ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਹ ਸਿਰਫ਼ ਬ੍ਰਾਉਜ਼ਰ ਪਿਛਲੇ ਪੱਛੇ ਇੱਕ ਬੇਨਤੀ ਭੇਜਦਾ, ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਦਾ (ਅਕਸਰ HTML ਜਾਂ JSON), ਅਤੇ ਫਿਰ ਪੰਨਾ ਅਪਡੇਟ ਕਰਦਾ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਅੱਗੇ ਵੱਧ ਸਕੇ।
XMLHttpRequest ਤੋਂ ਇੱਕ-ਲਾਈਨਰਾਂ ਤੱਕਅਧਾਰਭੂਤ ਬ੍ਰਾਉਜ਼ਰ ਵਿਸ਼ੇਸ਼ਤਾ XMLHttpRequest ਸੀ, ਪਰ ਇਸਨੂੰ ਸੀਧਾ ਵਰਤਣਾ ਕਾਫ਼ੀ ਦੁਹਰਾਉਣ ਵਾਲਾ ਕੋਡ ਮੰਗਦਾ: request ਬਣਾਉਣਾ, ਉਸਦੀ state ਵੇਖਣਾ, responses ਨੂੰ parse ਕਰਨਾ, ਬ੍ਰਾਉਜ਼ਰ quirks ਤੋਂ ਨਿਬਟਣਾ।
jQuery ਨੇ ਉਸ ਜਟਿਲਤਾ ਨੂੰ helper ਮੈਥਡਾਂ ਵਿੱਚ ਲਪੇਟਿਆ ਜੋ ਰੋਜ਼ਾਨਾ ਸੰਦਾਂ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦੇ:
$.ajax() ਪੂਰੇ ਕੰਟਰੋਲ ਲਈ$.get() / $.post() ਸਧਾਰਨ ਬੇਨਤੀਆਂ ਲਈ.load() HTML ਲੈ ਕੇ ਇੱਕ ਐਲੇਮੈਂਟ ਵਿੱਚ inject ਕਰਨ ਲਈਇਸ ਦੀ ਬਜਾਏ ਕਿ ਤੁਸੀਂ event handlers ਬੁਨਦੇ, query strings ਬਣਾਉਂਦੇ ਅਤੇ response parsing ਖੁਦ ਕਰਦੇ, ਤੁਸੀਂ ਉਸ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਸੀ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਅਗਲਾ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਹ ਪੈਟਰਨ ਤੇਜ਼ੀ ਨਾਲ ਵੈਬਸਾਈਟਾਂ 'ਤੇ ਆਮ ਹੋ ਗਏ:
ਭਾਵੇਂ ਸਰਵਰ ਪੁਰਾਣਾ‑ਸਕੂਲ ਹੋਵੇ, jQuery ਇੰਟਰਫੇਸ ਨੂੰ responsive ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਸੀ।
jQuery ਨੇ ਬੇਨਤੀਆਂ ਸ਼ੁਰੂ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਇਆ—ਪਰ ਅਕਸਰ ਖਤਮ ਕਰਨ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਮੁਸ਼ਕਲ ਰਿਹਾ। ਆਮ ਗਲਤੀਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਸਨ:
API ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਰੁਕਾਵਟ ਘੱਟ ਕਰਦਾ ਸੀ, ਪਰ ਇਹ ਵੀ ਸਿਖਾਉਂਦਾ ਸੀ ਕਿ “ਖੁਸ਼ੀ ਦਾ ਰਸਤਾ” ਸਿਰਫ਼ ਆਦ੍ਹਾ ਕੰਮ ਹੈ—ਭਰੋਸੇਯੋਗ ਇੰਟਰਫੇਸ ਬਣਾਉਣ ਲਈ ਹੋਰ ਚੀਜ਼ਾਂ ਵੀ ਜ਼ਰੂਰੀ ਹਨ।
jQuery ਸਿਰਫ਼ ਡਾਊਨਲੋਡ ਕਰਨ ਯੋਗ ਲਾਇਬ੍ਰੇਰੀ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਪਲੇਟਫਾਰਮ ਸੀ ਜਿਸ 'ਤੇ ਲੋਕ ਬਣਾਉਂਦੇ ਸਨ। “Plugins” ਛੋਟੇ-ਛੋਟੇ ਐਡ-ਆਨ ਸਨ ਜੋ ਆਮ ਤੌਰ 'ਤੇ $.fn ਤੇ ਮੈਥਡ ਜੋੜ ਕੇ jQuery ਨੂੰ ਨਵੇਂ ਫੰਕਸ਼ਨ ਦੇ ਦੇਂਦੇ। ਡਿਵੈਲਪਰਾਂ ਲਈ ਇਸਦਾ ਅਰਥ ਸੀ ਕਿ ਤੁਸੀਂ ਇੱਕ ਫੀਚਰ ਡ੍ਰੌਪ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਉਸਨੂੰ ਉਹੀ ਅੰਦਾਜ਼ ਵਿੱਚ ਕਾਲ ਕਰ ਸਕਦੇ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਵਰਤਦੇ ਸੀ।
ਘੁੰਮਣ ਦੀ ਰੁਕਾਵਟ ਘੱਟ ਸੀ। ਜੇ ਤੁਸੀਂ jQuery ਜਾਣਦੇ ਸੀ, ਤਾਂ plugin ਪੈਟਰਨ ਤੁਹਾਡੇ ਲਈ ਪਹਿਲਾਂ ਹੀ ਪਰਿਚਿਤ ਸੀ: ਐਲੇਮੈਂਟ ਚੁਣੋ, ਮੈਥਡ ਕਾਲ ਕਰੋ, options ਪਾਸ ਕਰੋ।
ਇਸ ਤੋਂ ਵੀ ਵਧ ਕੇ, jQuery ਦੀਆਂ ਰੀਤਾਂ ਨੇ plugins ਨੂੰ ਇੱਕਸਾਰ ਮਹਿਸੂਸ ਕਰਵਾਇਆ—ਅਲੱਗ-ਅਲੱਗ ਲੇਖਕਾਂ ਹੋਣ ਦੇ ਬਾਵਜੂਦ:
$('.menu').dropdown() ਨੈਟਿਵ jQuery ਵਾਂਗ ਪੜ੍ਹਦਾ$('.btn').addClass('x').plugin().fadeIn(){ speed: 200, theme: 'dark' } ਆਮ ਰੂਪ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦਾPlugins ਨੇ raw DOM ਕੰਮ ਅਤੇ ਪੂਰੇ application frameworks ਦਰਮਿਆਨ ਦੀ "missing middle" ਭਰ ਦਿੱਤੀ। ਆਮ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਸਨ sliders/carousels, form validation, modals/lightboxes, date pickers, autocomplete, tooltips, ਅਤੇ table helpers।
ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਲਈ, ਖਾਸ ਕਰਕੇ ਜੋ ਮਾਰਕੀਟਿੰਗ ਸਾਈਟਾਂ ਜਾਂ ਅੰਦਰੂਨੀ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਕੰਮ ਕਰਦੀਆਂ, plugins ਨੇ UI ਦੇ ਹਫ਼ਤਿਆਂ ਦੇ ਕੰਮ ਨੂੰ ਇਕ ਦਿਨ ਦੀ assembly ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ।
plugin ਬੂਮ ਦੀ ਕੀਮਤ ਸੀ। ਗੁਣਵੱਤਾ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਸੀ, ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਕਮਜ਼ੋਰ ਹੋ ਸਕਦੀ ਸੀ, ਅਤੇ ਕਈ plugins ਨੂੰ ਮਿਲਾ ਕੇ CSS ਜਾਂ event handlers ਵਿੱਚ ਟੱਕਰ ਹੋ ਸਕਦੀ ਸੀ। ਡਿਪੇਂਡੈਂਸੀ ਫੈਲਾਅ ਵੀ ਵਕਤ ਦੇ ਨਾਲ ਸਮੱਸਿਆ ਬਣ ਗਿਆ: ਇੱਕ ਫੀਚਰ ਦੋ ਹੋਰ plugins 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਸੀ, ਹਰ ਇਕ ਦੀ ਆਪਣੀ ਅਪਡੇਟ ਇਤਿਹਾਸ। ਲੇਖਕ ਜਦੋਂ ਅੱਗੇ ਵੱਧ ਜਾਂਦੇ, ਅਨమెੰਟੇਨਡ plugins ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਪੁਰਾਣੀਆਂ jQuery ਵਰਜਨਾਂ 'ਤੇ ਲਾਕ ਕਰ ਸਕਦੇ ਸਨ—ਜਾਂ ਸੁਰੱਖਿਆ ਅਤੇ ਸਥਿਰਤਾ ਦਾ ਖ਼ਤਰਾ ਬਣ ਸਕਦੇ ਸਨ।
jQuery ਦਾ ਕੋਰ DOM ਕੰਮ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਡਿਕਟਬਲ ਬਣਾਇਆ ਸੀ, ਪਰ ਟੀਮਾਂ ਨੂੰ ਫਿਰ ਵੀ ਇੰਟਰਫੇਸ ਟੁਕੜੇ ਬਣਾਉਣੇ ਪੈਂਦੇ ਸਨ। jQuery UI ਨੇ ਇਹ ਖਾਲੀ ਜਗ੍ਹਾ ਭਰ ਦਿੱਤੀ—date pickers, dialogs, tabs, sliders, accordions, draggable/sortable ਵਰਤੀ-ਯੋਗ ਕੰਪੋਨੈਂਟ ਜੋ ਬਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਘੱਟ ਚੇੰਤਾ ਨਾਲ ਕੰਮ ਕਰਦੇ। ਛੋਟੀ ਟੀਮਾਂ ਅਤੇ ਏਜੰਸੀਆਂ ਲਈ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਮਾਰਕੀਟਿੰਗ ਸਾਈਟਾਂ ਜਾਂ ਅੰਦਰੂਨੀ ਟੂਲ ਜਾਰੀ ਕਰਦੀਆਂ, ਇਹ "ਚੰਗਾ-ਚੱਲਿਆ ਜਾਂਦਾ" ਮੁੱਲ ਮੰਨਣ ਵਿੱਚ ਅਸਾਨ ਸੀ।
ਵੱਡੀ ਜਿੱਤ ਸਿਰਫ਼ widgets ਨਹੀਂ ਸੀ—ਉਹ widgets + consistent API ਅਤੇ theming ਦਾ ਮਿਲਾਪ ਸੀ। ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ prototype ਕਰ ਸਕਦੇ ਸੀ ਇਕ dialog ਜਾਂ autocomplete ਡ੍ਰਾਪ ਕਰਕੇ, ਫਿਰ ThemeRoller ਨਾਲ "on brand" ਬਣਾਵਾਂਗੇ, ਬਜਾਏ ਹਰ ਪ੍ਰੋਜੈਕਟ ਲਈ markup ਅਤੇ CSS ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੁੜ ਲਿਖਣ ਦੇ। ਉਸ ਦੋਹਰੇਪਣ ਨੇ jQuery UI ਨੂੰ ਇੱਕ practical toolkit ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਇਆ ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ design system।
jQuery Mobile ਇੱਕ ਵੱਖਰਾ ਮੁਦਦਾ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ: ਸ਼ੁਰੂਆਤੀ ਸਮਾਰਟਫੋਨਾਂ ਵਿੱਚ ਬ੍ਰਾਉਜ਼ਰ ਸਮਰੱਥਾ ਅਸਮਰੱਥ ਸਨ ਅਤੇ CSS ਸਹਿਯੋਗ ਸੀਮਤ ਸੀ, ਅਤੇ responsive design conventions ابھی settle ਹੋ ਰਹੀਆਂ ਸਨ। ਇਸ ਨੇ ਟਚ-ਫਰੈਂਡਲੀ UI ਕੰਪੋਨੈਂਟ ਅਤੇ ਇੱਕ "single-page" ਨੈਵੀਗੇਸ਼ਨ ਮਾਡਲ ਦਿੱਤਾ Ajax page transitions ਨਾਲ, ਜੋ ਇਕੋ ਕੋਡਬੇਸ ਨੂੰ native- ਜਿਹਾ ਐਪ ਵਰਗ ਬਿਹੇਵ ਕਰਵਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਸੀ।
ਜਿਵੇਂ ਜੇ web standards ਸੁਧਰ ਗਏ—CSS3, ਬੇਟਰ ਮੋਬਾਈਲ ਬ੍ਰਾਉਜ਼ਰ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਨੈਟਿਵ form controls ਅਤੇ layout primitives—ਤਾਂ ਕੁਝ abstractions ਲਾਗਤ ਬਣ ਗਏ। jQuery UI widgets ਭਾਰੀ ਹੋ ਸਕਦੇ ਸਨ, accessibility ਨੂੰ ਬਣਾਓਣਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਸੀ, ਅਤੇ ਆਧੁਨਿਕ ਡਿਜ਼ਾਈਨ ਉਮੀਦਾਂ ਨਾਲ ਮਿਲਾਉਣਾ ਔਖਾ। jQuery Mobile ਦੀ DOM rewriting ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ ਮਾਡਲ ਵੀ ਬਾਅਦ ਵਰਗੀਆਂ approaches ਨਾਲ ਟਕਰਾਉਂਦੀ ਜਿਵੇਂ responsive-first layouts ਅਤੇ framework-driven routing।
ਫਿਰ ਵੀ, ਦੋਹਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਨੇ ਇੱਕ ਮੁੱਖ ਵਿਚਾਰ ਸਾਬਤ ਕੀਤਾ: ਸਾਂਝੇ, ਪੁਨਰ-ਵਰਤਣਯੋਗ UI ਕੰਪੋਨੈਂਟ ਅਸਲੀ ਦੁਨੀਆ 'ਚ ਜ਼ਬਰਦਸਤ ਤਰੱਕੀ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਨ।
jQuery ਨੇ ਸਿਰਫ਼ ਬ੍ਰਾਉਜ਼ਰਾਂ ਨੂੰ ਅਨੁਕੂਲ ਨਹੀਂ ਕੀਤਾ; ਇਸਨੇ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਕਿ "ਸਧਾਰਨ" ਫਰੰਟ-ਐਂਡ ਕੋਡ ਕਿਵੇਂ ਦਿਖਦਾ। ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਹਰ ਰੋਜ਼ JavaScript ਲਿਖਣ ਲੱਗੀਆਂ, ਨਾ ਕਿ ਸਿਰਫ਼ ਖਾਸ ਪੰਨਿਆਂ ਲਈ, ਕਿਉਂਕਿ ਆਮ UI ਟਾਸਕ ਹੁਣ ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਹੁੰਦੇ।
jQuery ਦਾ ਇੱਕ ਸਭ ਤੋਂ ਵੱਡਾ ਸਾਂਸਕ੍ਰਿਤਿਕ ਬਦਲਾਅ chaining ਨੂੰ ਲੋਕਪ੍ਰિય ਕਰਨਾ ਸੀ: ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਚੁਣੋ, ਫਿਰ ਉਸ 'ਤੇ ਲਗਾਤਾਰ ਕਾਰਵਾਈਆਂ ਕਰੋ ਇੱਕ ਪੜ੍ਹਨਯੋਗ ਪ੍ਰਵਾਹ ਵਿੱਚ।
$(".card")
.addClass("active")
.find(".title")
.text("Updated")
.end()
.fadeIn(200);
ਉਹ fluent ਅੰਦਾਜ਼ ਬਾਅਦ ਵਾਲੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਭ nawet ਮੌਡਰਨ ਨੈਟਿਵ APIs 'ਤੇ ਵੀ ਅਸਰ ਪਾਇਆ। ਇਸ ਨਾਲ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਛੋਟੇ, ਜੋੜਯੋਗ operations ਦੀ ਆਦਤ ਪਈ ਨਾਂ ਕਿ ਵੱਡੇ, monolithic ਫੰਕਸ਼ਨਾਂ ਦੀ।
jQuery ਦੇ helpers—$.each, $.map, $.extend, AJAX shortcuts—ਇਸਨੂੰ ਲੋਭਨীয় ਬਣਾਉਂਦੇ ਕਿ ਤਰੱਕੀ ਨੂੰ ਘੱਟ ਲਾਈਨਾਂ ਵਿੱਚ ਸੰਕੁਚਿਤ ਕੀਤਾ ਜਾਵੇ। ਇਸ ਨਾਲ ਗਤੀ ਵਧੀ, ਪਰ ਇਸਨੇ ਬੇਹੁਸ਼ੀ ਨਾਲ "ਕਲੈਵਰ" ਇੱਕ-ਲਾਈਨਰ ਅਤੇ ਅਣਕਹੇ ਵਿਵਹਾਰ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜੋ ਮਾਸਾਂ ਬਾਅਦ ਮੁਸ਼ਕਲ ਰਿਹਾਂਗਾ।
ਕਈ ਕੋਡਬੇਸ ਵਿੱਚ ਬਿਜਨੇਸ ਲਾਜ਼ਮੀ ਨੂੰ ਸਿੱਧਾ click handlers ਵਿੱਚ ਮਿਕਸ ਕਰ ਦਿੱਤਾ ਗਿਆ, ਕਿਉਂਕਿ "ਇਥੇ ਹੀ ਕਰ ਦਿੰਦਾ ਹਾਂ" ਕਰਨਾ ਆਸਾਨ ਸੀ। ਇਹ ਸੁਲਤਤ-ਮੁੜ-ਜਾਰੀ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ, ਪਰ ਲੰਬੇ ਸਮੇਂ ਵਿੱਚ ਜਟਿਲਤਾ ਵਧਾ ਦਿੰਦਾ।
ਕੰਪੋਨੈਂਟ ਅਤੇ ਪੈਟਰਨਸ ਜਦ ਤੱਕ ਸਥਿਰ ਨਹੀਂ ਹੋਏ, jQuery ਐਪਸ ਅਕਸਰ state DOM ਵਿੱਚ ਰੱਖਦੀਆਂ: classes, hidden inputs, ਅਤੇ data attributes। ਡੀਬੱਗਿੰਗ ਦਾ ਅਰਥ ਸੀ live HTML ਦੀ ਜਾਂਚ ਅਤੇ ਐਸੇ event callbacks ਦੇ ذریعے ਗੁਜ਼ਰਨਾ ਜੋ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਕ੍ਰਮ ਵਿੱਚ ਫਾਇਰ ਹੋ ਸਕਦੇ ਸਨ।
ਯੂਨਿੱਟ ਟੈਸਟਿੰਗ ਸੰਭਵ ਸੀ, ਪਰ ਟੀਮਾਂ ਜ਼ਿਆਦਾਤਰ ਮੈਨੂਅਲ QA ਅਤੇ browser devtools 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੀਆਂ। ਮੁੱਦੇ ਅਕਸਰ timing-ਸਬੰਧੀ ਹੁੰਦੇ (animations, AJAX, event bubbling), ਜਿਸ ਨਾਲ bugs ਇੰਟਰਮੀਟੈਂਟ ਮਹਿਸੂਸ ਹੁੰਦੇ।
jQuery ਕੋਡ ਅਕਸਰ maintainable ਰਹਿੰਦਾ ਜਦੋਂ ਟੀਮਾਂ:
ਇਹ ਗੁੰਝਲਦਾਰ ਬਣ ਜਾਂਦਾ ਜਦੋਂ ਪੰਨੇ ਹੋਰ-ਤੇ-ਹੋਰ handlers ਜੋੜ ਲੈਂਦੇ, selectors ਹਰ ਥਾਂ ਦੁਹਰਾਏ ਜਾਂਦੇ, ਅਤੇ animation callback ਵਿੱਚ "ਸਿਰਫ਼ ਇੱਕ ਹੋਰ" ਸੁਧਾਰ ਕਰ ਦਿਤਾ ਜਾਂਦਾ। ਲਾਇਬ੍ਰੇਰੀ ਤੇਜ਼ iteration ਆਸਾਨ ਬਣਾਉਂਦੀ; ਅਨੁਸ਼ਾਸਨ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਕਿ ਨਤੀਜਾ ਕਿਵੇਂ ਉਮਰ ਰਿਹਾ।
jQuery ਇਕੱਠੇ ਨਾ ਗਿਆ, ਅਤੇ ਇਹ "ਘੱਟੀਆਂ" ਨਹੀਂ ਹੋਇਆ ਕਿਉਂਕਿ ਇਹ ਖਰਾਬ ਹੋ ਗਿਆ। ਇਹ ਹੌਲੀ ਹੋ ਗਿਆ ਕਿਉਂਕਿ ਬ੍ਰਾਉਜ਼ਰ ਪਲੇਟਫਾਰਮ ਨੇ translator ਦੀ ਲੋੜ ਘੱਟ ਕੀਤੀ। ਉਹੀ ਸਮੱਸਿਆਵਾਂ ਜੋ jQuery ਨੇ ਹੀ ਸੁਲਝਾਈਆਂ—ਗੁੰਝਲਦਾਰ APIs, ਅਸਮਰੱਥ ਵਿਵਹਾਰ, ਅਤੇ ਝੰਜਟ ਵਾਲੇ ਵਰਕਫਲੋ—ਘੱਟ ਆਮ ਹੋ ਗਈਆਂ ਜਦੋਂ standards ਮਜ਼ਬੂਤ ਹੋਏ ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ ਇੱਕੱਠੇ ਹੋਏ।
ਜਿਵੇਂ DOM ਅਤੇ JavaScript APIs standardize ਹੋਏ, ਕਈ ਹਰਰੋਜ਼ jQuery calls ਨੂੰ ਸਿੱਧੇ ਬਰਾਬਰ ਮਿਲਣ ਲੱਭੇ:
document.querySelector() ਅਤੇ document.querySelectorAll() ਬਹੁਤੇ ਮਾਮਲੇ ਕਵਰ ਕਰਨ ਲੱਗੇaddEventListener() ਹਰੇਕ ਥਾਂ ਭਰੋਸੇਯੋਗ ਹੋ ਗਿਆfetch() (ਅਤੇ ਬਾਅਦ async/await) AJAX-ਸਟਾਈਲ ਕਾਲ ਨੂੰ native ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਬਣਾਇਆਜਦੋਂ "ਨੈਟਿਵ ਤਰੀਕਾ" ਬ੍ਰਾਉਜ਼ਰਾਂ ਵਿੱਚ ਇਕਸਾਰ ਹੋ ਗਿਆ, helper library ਦੀ ਲੋੜ ਘੱਟ ਹੋ ਗਈ।
ਜਿਵੇਂ ਵੈਬ ਐਪਸ ਵੱਡੇ ਹੋਏ, ਟੀਮਾਂ load time ਅਤੇ JavaScript ਲਾਗਤ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਦੇਖਣ ਲੱਗੇ। ਇੱਕ-ਵਾਰ jQuery (ਅਤੇ plugins) ਭੇਜਣਾ ਸਿਰਫ਼ ਕੁਝ ਸੁਵਿਧਾਵਾਂ ਲਈ ਔਖਾ ਜਨਦਾ ਸੀ—ਖਾਸ ਕਰਕੇ ਮੋਬਾਈਲ ਨੈਟਵਰਕਾਂ 'ਤੇ।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ jQuery ਸਲੋ ਸੀ; ਮਤਲਬ ਇਹ ਸੀ ਕਿ "ਹੋਰ ਇਕ dependency" ਭੇਜਣ ਦਾ ਫੈਸਲਾ ਇੱਕ ਅਸਲ ਟਰੇਡਆਫ ਬਣ ਗਿਆ। ਡਿਵੈਲਪਰ ਛੋਟੇ, ਫੋਕਸਡ ਯੂਟਿਲਿਟੀਜ਼ ਜਾਂ ਪਲੇਟਫਾਰਮ-ਪੂਰਨ ਤਰੀਕਿਆਂ ਦੀ ਪਰਵਾਹ ਕਰਨ ਲੱਗੇ।
Single-page application frameworks ਨੇ ਧਿਆਨ manual DOM ਨੂੰ ਛੇੜਨ ਤੋਂ state ਨੂੰ ਮੈਨੇਜ ਕਰਨ ਅਤੇ UI ਨੂੰ components ਤੋਂ ਜੋੜਨ ਵੱਲ ਵਧਾਇਆ। React/Vue/Angular ਦੀ ਸੋਚ ਵਿੱਚ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਪૃੰਨ ਤੋਂ ਨਹੀਂ ਪੁੱਛਦੇ, "ਇਹ ਐਲੇਮੈਂਟ ਲੱਭੋ ਅਤੇ ਉਸਨੂੰ ਬਦਲੋ"—ਤੁਸੀਂ ਡੇਟਾ ਅਪਡੇਟ ਕਰਦੇ ਹੋ ਅਤੇ UI ਦੁਬਾਰਾ ਰੀ-ਰੇਂਡਰ ਹੁੰਦੀ।
ਇਸ ਮਾਡਲ ਵਿੱਚ, jQuery ਦੀਆਂ ਤਾਕਤਾਂ—imperative DOM ਮੈਨਿਪੁਲੇਸ਼ਨ, effects, ਅਤੇ ਇੱਕ-ਆਫ਼ event wiring—ਘੱਟ ਕੇਂਦਰੀ ਹੋ ਜਾਂਦੀਆਂ, ਅਤੇ ਕਈ ਵਾਰ ਵਾਰ-ਵਾਰ ਮਨਜ਼ੂਰ-ਨਹੀਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ।
jQuery ਦਾ ਮਿਸ਼ਨ ਵੈੱਬ ਨੂੰ ਵਰਤਣ ਯੋਗ ਅਤੇ ਸਥਿਰ ਬਣਾਉਣਾ ਸੀ। ਜਿਵੇਂ ਬ੍ਰਾਉਜ਼ਰ ਸੁਧਰੇ, jQuery ਘੱਟ ਜ਼ਰੂਰੀ ਹੋ ਗਿਆ—ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ। ਕਈ ਪ੍ਰੋਡਕਸ਼ਨ ਸਾਈਟਾਂ ਅਜੇ ਵੀ ਇਸ ਨੂੰ ਵਰਤਦੀਆਂ ਹਨ, ਅਤੇ ਕਈ ਆਧੁਨਿਕ APIs (ਅਤੇ ਡਿਵੈਲਪਰ ਉਮੀਦਾਂ) jQuery ਤੋਂ ਸਿੱਖੀਆਂ ਸਿੱਧਾਂਤਾਂ ਨੂੰ ਅੰਦਰ ਸ਼ਾਮਿਲ ਕਰਦੀਆਂ ਹਨ।
jQuery ਹੁਣ ਨਵੇਂ ਫਰੰਟ-ਐਂਡ ਕੰਮ ਲਈ ਮੂਲ ਚੋਣ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਅਜੇ ਵੀ ਵੈੱਬ ਦਾ ਇੱਕ ਹਿੱਸਾ ਚਲਾਉਂਦਾ ਹੈ—ਅਤੇ ਇਸਦਾ ਪ੍ਰਭਾਵ ਅਜੇ ਵੀ ਇਸ ਗੱਲ ਵਿੱਚ ਗੁੰਝਿਆ ਹੈ ਕਿ ਕਈ ਡਿਵੈਲਪਰ JavaScript ਬਾਰੇ ਸੋਚਦੇ ਹਨ।
ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ jQuery ਨੂੰ ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਮਿਲੋਗੇ ਜੋ ਸਥਿਰਤਾ ਨੂੰ rewrite ਕਰਵਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ:
ਜੇ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਮੇਨਟੇਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਫਾਇਦਾ predictability ਹੈ: ਕੋਡ ਸਮਝਣਯੋਗ, ਵਧੀਆ ਦਸਤਾਵੇਜ਼ੀ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਪੈਚ ਕਰਨ ਵਿੱਚ ਸੌਖਾ।
ਆਧੁਨਿਕ ਟੂਲਾਂ ਨੇ jQuery ਨੂੰ ਲਾਈਨ-ਬਾਈ-ਲਾਈਨ ਨਕਲ ਨਹੀਂ ਕੀਤਾ, ਪਰ ਉਹਨਾਂ ਨੇ ਇਸ ਦੀਆਂ ਸਭ ਤੋਂ ਵਧੀਆ ਸੋਚਾਂ ਨੂੰ ਆਪਣੀ ਅੰਦਰ ਲਿਆ։
ਇੱਥੋਂ ਤੱਕ vanilla JavaScript ਦੇ ਵਿਕਾਸ (ਜਿਵੇਂ querySelectorAll, classList, fetch, ਅਤੇ ਬੇਟਰ event handling) ਉਹ ਸਮੱਸਿਆਵਾਂ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ jQuery ਨੇ ਰੋਜ਼ਾਨਾ ਡਿਵੈਲਪਰਾਂ ਲਈ ਹੱਲ ਕੀਤੀਆਂ।
ਸਭ ਤੋਂ ਵੱਡਾ ਪਾਠ product thinking ਹੈ: ਇੱਕ ਛੋਟਾ, ਸਥਿਰ API ਅਤੇ ਵਧੀਆ ਡੌਕਸ ਨੇ ਇਕ ਸਾਰੇ ਉਦਯੋਗ ਦੇ ਕੋਡ ਲਿਖਣ ਦੇ ਢੰਗ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ।
ਇਹ ਇਹ ਵੀ ਯਾਦ ਦਿਲਾਂਦਾ ਹੈ ਕਿ "developer experience" ਮਿਲਾ ਕੇ ਹੁੰਦੀ ਹੈ। jQuery ਦੇ ਜ਼ਮਾਨੇ ਵਿੱਚ, DX ਦਾ ਮਤਲਬ browser quirks ਨੂੰ ਛੁਪਾਉਣਾ ਸੀ; ਅਜ kal DX ਦਾ ਮਤਲਬ idea ਤੋਂ ਚੱਲਦੇ ਸੌਫਟਵੇਅਰ ਤੱਕ ਦੀ ਰਾਹ ਨੂੰ ਘਟਾਉਣਾ ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ vibe-coding ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਕਈ ਟੀਮਾਂ ਨੂੰ ਪਸੰਦ ਆਉਂਦੇ ਹਨ: ਬਜਾਏ ਬੋਇਲਰਪਲੇਟ ਹੱਥੋਂ ਹੱਥ ਜੋੜਨ ਦੇ, ਤੁਸੀਂ chat ਇੰਟਰਫੇਸ ਵਿੱਚ iterate ਕਰ ਸਕਦੇ ਹੋ, React front end, Go + PostgreSQL backend (ਜਾਂ Flutter mobile app) generate ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਅਜੇ ਵੀ ਜਦੋਂ ਚਾਹੋ source code export ਕਰਨ ਦਾ ਵਿਕਲਪ ਰੱਖ ਸਕਦੇ ਹੋ।
jQuery ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿ ਇਸ ਨੇ ਅਸਮਰੱਥ ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ-ਨਿਰਭਰ DOM ਸਕ੍ਰਿਪਟਿੰਗ ਨੂੰ ਛੋਟੇ, ਭਰੋਸੇਯੋਗ ਔਜ਼ਾਰਾਂ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ। ਇਸ ਨੇ ਰੋਜ਼ਾਨਾ ਕਾਰਜ—ਤੱਤ ਚੁਣਨਾ, ਇਵੈਂਟ ਜੋੜਨਾ, DOM ਬਦਲਣਾ, AJAX ਕਰਨਾ—ਨੂੰ ਬ੍ਰਾਉਜ਼ਰਾਂ ਵਿੱਚ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਬਣਾਇਆ, ਜਿਸ ਨਾਲ ਟੀਮਾਂ ਦੀ ਗਤੀ ਅਤੇ ਭਰੋਸਾ ਵਧਿਆ।
jQuery ਤੋਂ ਪਹਿਲਾਂ ਡਿਵੈਲਪਰ ਅਕਸਰ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਮੁਸ਼ਕਲਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਸਨ:
XMLHttpRequest ਦੀ ਸੈਟਅੱਪ ਅਤੇ ਐਡਜ ਕੇਸ)ਮੁੱਖ ਲਾਗਤ ਕੋਡ ਇਕ ਵਾਰੀ ਲਿਖਣਾ ਨਹੀਂ ਸੀ—ਇਹ ਸਾਰਾ ਕੋਡ ਹਰ ਥਾਂ ਚਲਾਉਂ ਕਾਰਜਕੁਸ਼ਲ ਰੱਖਣਾ ਸੀ।
$() ਮੁੱਖ ਫੰਕਸ਼ਨ ਹੈ: ਤੁਸੀਂ ਇਸ ਨੂੰ CSS-ਨੁਮਾ ਸਿਲੇਕਟਰ (ਜਾਂ ਇੱਕ ਐਲੇਮੈਂਟ) ਦੇ ਦਿੰਦੇ ਹੋ ਅਤੇ ਇਹ ਤੁਹਾਨੂੰ ਮਿਲਣ ਵਾਲੇ ਐਲੇਮੈਂਟਾਂ ਨੂੰ ਵੱਢੇ ਹੋਏ jQuery ਆਬਜੈਕਟ ਦੇ ਤੌਰ ਤੇ ਵਾਪਸ ਦਿੰਦਾ ਹੈ। ਉਹ ਆਬਜੈਕਟ ਇੱਕ ਸੰਯਮਿਤ ਮੈਥਡ ਸੈੱਟ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ "ਲੱਭੋ, ਫਿਰ ਕਰੋ" ਦੇ ਤਰੀਕੇ ਨਾਲ ਬਿਨਾਂ ਬ੍ਰਾਉਜ਼ਰ ਕੁਇਰਕਸ ਦੀ ਚਿੰਤਾ ਕੀਤੇ ਕੰਮ ਕਰ ਸਕੋ।
Chaining ਇਸ ਲਈ ਵੱਡੀ ਗੱਲ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ jQuery ਮੈਥਡ ਇਕੋ jQuery ਆਬਜੈਕਟ ਨੂੰ ਵਾਪਸ ਕਰਦੇ ਹਨ ਕਾਰਰਵਾਈ ਦੇ ਬਾਅਦ। ਇਸ ਨਾਲ ਤੁਸੀਂ ਇੱਕ ਪੜ੍ਹਨਯੋਗ ਪ੍ਰਵਾਹ ਵਿੱਚ UI ਕਦਮ ਲਗਾ ਸਕਦੇ ਹੋ (select → modify → animate) ਬਿਨਾਂ ਝੁਟਪੁਟ ਵੈਰੀਐਬਲਾਂ ਦੇ।
Sizzle $(selector) ਦੇ ਪਿੱਛੇ ਵਾਲਾ selector engine ਹੈ। ਉਹ ਵੱਖ-ਵੱਖ ਬ੍ਰਾਉਜ਼ਰਾਂ ਵਿੱਚ selector ਦੇ ਨਿਰਵਾਚਨ ਨੂੰ ਸਥਿਰਤਾ ਦਿੰਦਾ ਸੀ ਅਤੇ ਉਹਨਾਂ ਸਿਲੇਕਟਰਾਂ ਦਾ ਵਿਆਖਿਆਨ ਸਮਝਦਾਰ ਤਰੀਕੇ ਨਾਲ ਕਰਦਾ ਸੀ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਈ ਬ੍ਰਾਉਜ਼ਰ ਪੂਰਾ ਸਹਾਰਾ ਨਹੀਂ ਦਿੰਦੇ ਸਨ।
jQuery ਆਮ ਇਵੈਂਟ ਕਾਰਜਾਂ ਨੂੰ ਸਧਾਰਨ ਬਣਾਉਂਦਾ ਸੀ ਤਾਂ ਕਿ ਤੁਹਾਨੂੰ ਬ੍ਰਾਉਜ਼ਰ-ਖਾਸ ਬਰਾਂਚਿੰਗ ਨਾ ਲਿਖਣੀ ਪਏ। ਇਹ DOM ਤਿਆਰ ਹੋਣ 'ਤੇ ਕੋਡ ਚਲਾਉਣ ਜਿਹੇ ਆਮ ਨਮੂਨੇ ਪ੍ਰਚਲਿਤ ਕਰਦਾ ਸੀ:
$(function () {
// safe to touch the DOM
});
ਇਸ ਨੇ ਆਮ ਪੰਨਿਆਂ ਲਈ timing-ਸਬੰਧੀ ਬਗ ਘੱਟ ਕੀਤੇ।
jQuery ਨੇ XMLHttpRequest ਦੇ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਹਿੱਸਿਆਂ ਨੂੰ ਲੈਪ ਕੀਤਾ ਅਤੇ ਆਮ ਮਾਮਲੇ ਆਸਾਨ ਬਣਾਏ:
$.ajax() ਪੂਰੇ ਕੰਟਰੋਲ ਲਈ$.get() / $.post() ਸਧਾਰਨ ਬੇਨਤੀਆਂ ਲਈ.load() HTML ਨੂੰ ਲੋਡ ਕਰਕੇ ਕਿਸੇ ਐਲੇਮੈਂਟ ਵਿੱਚ ਸੁੱਟਣ ਲਈਇਸ ਨਾਲ responsive-ਲੱਗਣ ਵਾਲੀ UI ਬਣਾਉਣ ਦੀ ਰੁਕਾਵਟ ਘੱਟ ਹੋ ਗਈ, ਪਰ ਅਜੇ ਵੀ ਤਰੱਕੀਯਾਬ error handling ਅਤੇ UI ਫੀਡਬੈਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
Plugins jQuery ਨੂੰ ਵਧਾਉਂਦੇ ਸਨ ਬਾਜ਼ਾਰ ਵਿੱਚ ਛੋਟੇ-ਛੋਟੇ ਐਡ-ਆਨ ਰਾਹੀਂ ਜੋ ਕਿ $.fn ਤੇ ਫੰਕਸ਼ਨ ਜੁੜ ਕੇ ਨਵੀਂ ਵਰਤੋਂ ਦਿੰਦੇ। ਜੇ ਤੁਸੀਂ jQuery ਜਾਣਦੇ ਸੀ ਤਾਂ plugin pattern ਸਮਝਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਸੀ: select elements → call method → pass options।
ਇਸ ਕਰਕੇ sliders, modals, validation, date pickers ਆਦਿ ਜਲਦੀ ਫੈਲ ਗਏ।
jQuery ਨੇ ਉਹ ਸਮੱਸਿਆ ਹੱਲ ਕੀਤੀਆਂ ਜੋ ਪਹਿਲਾਂ ਪਲੇਟਫਾਰਮ ਤੇ ਸੀ—ਜਿਵੇਂ ਕਿ ਗੈਰ-ਇਕਾਈ APIs ਅਤੇ ਅਸਮਰੱਥ ਵਿਵਹਾਰ—ਜਦੋਂ browsers ਨੇ ਉਹ ਚੀਜ਼ਾਂ ਮੈਨਕੀ ਲਿਆ, ਤਾਂ ਜ਼ਰੂਰਤ ਘੱਟ ਹੋ ਗਈ।
querySelector(All) ਨੇ ਬਹੁਤੇ selector ਮਾਮਲੇ ਕਵਰ ਕਰ ਲਏaddEventListener() ਹੁਣ ਦੇਸ਼-ਵਿਆਪੀ ਤੌਰ 'ਤੇ ਭਰੋਸੇਯੋਗ ਹੋ ਗਿਆfetch() ਅਤੇ async/await ਨੇ network calls ਨੂੰ ਸਾਫ਼ ਕੀਤਾਜਦੋਂ Native ਤਰੀਕਾ ਸਰਬ-ਬ੍ਰਾਉਜ਼ਰ ਤੈਅ ਹੋ ਗਿਆ, helper library ਦੀ ਲੋੜ ਘੱਟ ਹੋ ਗਈ।
ਸੁਝਾਵ: ਜੇ ਕੋਡ ਸਥਿਰ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਲੋਡ ਹੋਇਆ ਹੈ ਤਾਂ jQuery ਨੂੰ ਰੱਖੋ। ਸੁਤੰਤਰ ਨਵੀਂ ਕੋਡ ਲਈ ਮੌਡਰਨ APIs ਜਾਂ framework-native ਪੈਟਰਨ ਵਰਤੋ। ਅਸਤ-ਇਤਿਹਾਸਕ jQuery ਕੋਡ ਲਈ ਸਿਰਫ਼ ਉਦੋਂ ਰੀਫੈਕਟਰ ਕਰੋ ਜਦੋਂ ਇਹ ਖਤਰਾ ਘਟਾਉਂਦਾ ਹੋਵੇ ਜਾਂ ਮੇੰਟੇਨੈਂਸ ਲਾਗਤ ਘਟੇ।