Vi som många andra utvecklare känner nog igen sig i hur mycket enklare man tyckte det blev att koda Javascript dagen då jQuery kom (https://jquery.com).

Man lade in en scripttagg med referens till jQuery och kunde sedan via det ökända $-tecknet ange ett CSS-klassnamn eller id för det DOM-element man ville komma åt.

Bara att skriva $(‘.min-klass’) eller $(‘#mitt-id’) för att sedan möjligen lägga till eller ta bort exempelvis ytterligare en klass, gömma/visa elementet, förändra attributen, iterera över flertalet element med hjälp av .each()-metoden etc. Möjligheterna kändes oändliga som om det var ett helt nytt språk utöver vanlig javascript.

Jag älskade jQuery och det har räddat mig flertalet gånger då vi i lätt panik var tvungna att lösa något akut på di.se.

T.ex. har det hänt att en text som endast var möjlig att förändras via en release av hela applikationen nu skulle ändras inom några minuter, och man hade inte tid att invänta en release p.g.a. vår då långsamma releaseprocess.

Svaret var då solklart att jag inifrån vårt CMS lade in en scripttagg med ett ”magiskt” jQuery-uttryck som såg till att leta upp texten på rätt DOM-element och därmed sedan förändra det enligt önskemål.
Ett sådant uttryck kunde vid en första anblick se lätt kryptiskt ut, kanske något i stil med:

$('.native-box .blaze').each(function(all, item) {
 $(item).text('Av: ' + $(item).text()));
 });

Dock i vårt nuvarande arbete i vår nya moderna plattform här på Dagens industri har jag och flera i teamet känt att flera års användande av jQuery satt sina spår. Man tar lätt för givet att $ alltid finns där och metoder som jQuery tillhandahåller kan man inte leva utan eller göra med vanlig javascript.

Men det kan man såklart, och varför läsa in jquery.min.js på cirka 30kb om vi ändå kan göra samma sak med vanlig javascript?

Via document.querySelector(selector) och document.querySelectorAll(selector) kan vi göra exakt samma sak som vi alltid gjort med $(selector).

https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector

https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelectorAll

Och each()-metoden kan vi t.ex. göra på samma sätt med forEach()

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach

Möjligen att vi på en nodlista först behöver konvertera den till en via t.ex. Array.from(nodelist) så då skulle det kunna ersätta med:

Array.from(document.querySelectorAll('.native-box .blaze')).forEach(function(element) {
 element.innerHTML = 'Av: ' + element.innerHTML;
 });

Läsbarheten och förståelsen för koden kanske inte blev varken bättre eller sämre, men vinsten ligger i att se styrkan i att inte alltid ta in och förlita sig på andra ramverk som man lika gärna kan skriva själv, och då också kunna känna att vi själva äger kontrollen på vad koden gör.

I vår lösning där vi dessutom har en modulbaserad javascriptlösning som vi bygger med Grunt och Webpack så är det smidigt att sakta men säkert bygga upp ett stabilt modulbibliotek av liknande förenklingar som jQuery erbjuder.

Ovanstående är bara ett litet exempel på att man oftast inte behöver jQuery, utan att det finns minst lika bra lösningar med vanlig javascriptkod.

Så nu har vi börjat rensa bort de ställen där vi ser att vi inte behöver använda jQuery för att snart kunna ta bort det helt ur nya di.se-applikationen.

Därmed har vi minskat vår totala storlek på den javascriptfil som besökaren kommer behöva ladda ner vid besök.
Många bäckar små för att sikta på hög prestanda och användarupplevelse på nya di.se.