JavaScript interpretat sau compilat?

Calculatoarele nu pot efectiv executa codul pe care îl scrieți în JavaScript (sau în orice altă limbă pentru această problemă). Calculatoarele pot rula doar codul mașinii. Codul de mașină pe care îl poate rula un anumit computer este definit în cadrul procesorului care va rula acele comenzi și poate fi diferit pentru diferite procesoare.

Evident, scrierea codului mașinii a fost dificil pentru oameni (este 125 o comandă de adăugare sau este 126 sau poate 27). Pentru a rezolva această problemă, au fost create cele cunoscute sub numele de limbaje de asamblare. Aceste limbi foloseau nume mai evidente pentru comenzi (cum ar fi ADD pentru adăugare) și astfel au eliminat nevoia de a aminti codurile exacte ale mașinii. Limbile de asamblare au încă o relație unu cu unu cu procesorul și codul mașinii în care computerul transformă aceste comenzi.

Limbile de asamblare trebuie să fie compilate sau interpretate

Foarte devreme s-a realizat că este nevoie de limbi de scris mai ușor și că computerul însuși poate fi folosit pentru a traduce cele în instrucțiunile codului mașinii pe care computerul le poate înțelege de fapt. Cu această traducere s-au putut adopta două abordări și s-au ales ambele alternative (una sau alta vor fi utilizate în funcție de limba utilizată și de unde se rulează).

Un limbaj compilat este unul în care odată ce programul a fost scris, alimentați codul printr-un program numit compilator și care produce o versiune de cod de mașină a programului. Când doriți să rulați apoi programul, sunteți doar la versiunea codului mașinii. Dacă faceți modificări ale programului, trebuie să îl recompilați înainte de a putea testa codul schimbat.

Un limbaj interpretat este unul în care instrucțiunile sunt convertite din ceea ce ați scris în codul mașinii pe măsură ce programul este rulat. Un limbaj interpretat primește practic o instrucțiune de la sursa programului, o convertește în codul mașinii, rulează codul mașinii și apoi preia instrucțiunea următoare de la sursă pentru a repeta procesul.

Două variante privind compilarea și interpretarea

O variantă folosește un proces în două etape. Cu această variantă, sursa programului dvs. este compilată nu direct în codul mașinii, ci este transformată într-un limbaj asemănător, care este încă independent de procesorul particular. Când doriți să rulați codul, atunci procesează codul compilat printr-un interpret specific procesorului, astfel încât să obțineți codul mașinii adecvat acelui procesor. Această abordare are multe dintre avantajele compilării păstrând independența procesorului, deoarece același cod compilat poate fi interpretat de mai multe procesoare diferite. Java este o limbă care folosește adesea această variantă.

Cealaltă variantă se numește un compilator Just in Time (sau JIT). Cu această abordare, nu executați de fapt compilatorul după ce v-ați scris codul. În schimb, asta se întâmplă automat atunci când rulați codul. Folosind un compilator Just in Time, codul nu este interpretat prin declarație, este compilat dintr-o dată de fiecare dată când este chemat să fie rulat, iar apoi versiunea compilată pe care tocmai a creat-o este cea care se execută. Această abordare face să pară mult ca și cum codul este interpretat, cu excepția faptului că în loc de erori se găsesc doar atunci când este atinsă instrucțiunea cu eroarea, orice eroare detectată de compilator nu duce la executarea niciunui cod în loc de tot codul. până în acel moment fiind rulat. PHP este un exemplu de limbaj care folosește de obicei doar la compilarea timpului.

Este compilat sau interpretat JavaScript?

Deci, acum știm ce înseamnă codul interpretat și codul compilat, întrebarea la care trebuie să răspundem în continuare este ce are de a face toate acestea cu JavaScript? În funcție de exact locul în care rulați JavaScript, codul poate fi compilat sau interpretat sau poate utiliza oricare din celelalte două variante menționate. De cele mai multe ori executați JavaScript într-un browser web și acolo JavaScript este de obicei interpretat.

Limbile interpretate sunt de obicei mai lente decât limbile compilate. Există două motive pentru aceasta. În primul rând, codul care trebuie interpretat de fapt trebuie interpretat înainte de a putea fi executat și în al doilea rând, asta trebuie să se întâmple de fiecare dată când executarea instrucțiunii (nu numai de fiecare dată când executați JavaScript, ci dacă este într-o buclă, atunci trebuie făcută de fiecare dată în jurul buclei). Aceasta înseamnă că codul scris în JavaScript va rula mai lent decât codul scris în multe alte limbi.

Cum ne ajută să cunoaștem acest lucru acolo unde JavaScript este singura limbă disponibilă pentru a rula pe toate browserele web? Interpretul JavaScript însuși care este încorporat în browserul web nu este scris în JavaScript. În schimb, este scris într-o altă limbă care a fost apoi compilată. Ceea ce înseamnă asta este că puteți face JavaScript să funcționeze mai rapid dacă puteți profita de orice comenzi pe care le oferă JavaScript care vă permit să descărcați sarcina în motorul JavaScript în sine.

Exemple pentru a obține JavaScript pentru a rula mai repede

Un exemplu în acest sens este faptul că unele browsere, dar nu toate, au implementat o metodă document.getElementsByClassName () în motorul JavaScript, în timp ce alții încă nu au făcut acest lucru. Când avem nevoie de această funcționalitate specială, putem face ca codul să ruleze mai repede în acele browsere în care motorul JavaScript îl furnizează folosind funcția de detectare pentru a vedea dacă metoda există deja și creând propria noastră versiune a codului respectiv în JavaScript atunci când motorul JavaScript nu face acest lucru. nu ne-o oferim. În cazul în care motorul JavaScript oferă această funcționalitate, ar trebui să funcționeze mai repede dacă folosim asta, în loc să rulăm propria noastră versiune scrisă în JavaScript. Același lucru este valabil pentru orice procesare pe care motorul JavaScript ne pune la dispoziție pentru a apela direct.

De asemenea, vor exista cazuri în care JavaScript oferă mai multe modalități de a face aceeași solicitare. În aceste cazuri, una dintre căile de acces la informații poate fi mai specifică decât cealaltă. De exemplu, document.getElementsByTagName ('table') [0] .tBodies și document.getElementsByTagName ('table') [0] .getElementsByTagName ('tbody') ambele preiau aceeași nodelistă a etichetelor de ton din prima tabelă de pe web. pagina cu toate acestea, prima dintre acestea este o comandă specifică pentru preluarea etichetelor tbody unde a doua identifică că recuperăm etichete tbody într-un parametru și alte valori pot fi înlocuite pentru a prelua alte tag-uri. În majoritatea browserelor, varianta mai scurtă și mai specifică a codului va rula mai repede (în unele cazuri mult mai rapid) decât a doua variantă și, deci, are sens să folosiți versiunea mai scurtă și mai specifică. De asemenea, face codul mai ușor de citit și de întreținut.

Acum, în multe dintre aceste cazuri, diferența reală a timpului de procesare va fi foarte mică și va fi doar atunci când adăugați multe astfel de alegeri de cod împreună, încât veți obține orice diferență notabilă în timpul de executare a codului. Este destul de rar, însă, faptul că schimbarea codului dvs. pentru a face să funcționeze mai repede va face ca codul să fie semnificativ mai lung sau mai greu de întreținut, și adesea inversul va fi adevărat. Există, de asemenea, avantajul că viitoarele versiuni ale motoarelor JavaScript pot fi create care grăbește și mai mult varianta mai specifică, astfel încât utilizarea variantei specifice poate însemna că codul dvs. va rula mai repede în viitor, fără a fi necesar să schimbați nimic.