Betekenis van geïnterpreteerd of samengesteld in JavaScript

Computers kunnen de code waarin u schrijft niet echt uitvoeren JavaScript (of welke andere taal dan ook). Computers kunnen alleen machinecode uitvoeren. De machinecode die door een bepaalde computer kan worden uitgevoerd, is gedefinieerd binnen de processor die deze opdrachten gaat uitvoeren en kan verschillen voor verschillende processors.

Klaarblijkelijk, machine code schrijven was moeilijk voor mensen om te doen (is 125 een add-commando of is het 126 of misschien 27). Om dat probleem te omzeilen, zijn zogenaamde assembleertalen gemaakt. Deze talen gebruikten meer voor de hand liggende namen voor de commando's (zoals ADD om toe te voegen) en schrapten dus de noodzaak om de exacte machinecodes te onthouden. Assemblagetalen hebben nog steeds een één-op-één-relatie met de specifieke processor en machinecode waarnaar de computer die opdrachten converteert.

Al heel vroeg werd ingezien dat schrijven makkelijker was talen nodig waren en dat de computer zelf kon worden gebruikt om die te vertalen naar de machinecode-instructies die de computer daadwerkelijk kan begrijpen. Er konden met deze vertaling twee benaderingen worden gevolgd en voor beide alternatieven werd gekozen (de ene of de andere wordt gebruikt, afhankelijk van de taal die wordt gebruikt en waar deze wordt uitgevoerd).

Een gecompileerde taal is een taal waarin, zodra het programma is geschreven, u de code invoert via een programma genaamd a compiler en dat levert een machinecodeversie van het programma op. Als u het programma vervolgens wilt uitvoeren, belt u gewoon de machinecodeversie. Als u wijzigingen in het programma aanbrengt, moet u het opnieuw compileren voordat u de gewijzigde code kunt testen.

Een geïnterpreteerde taal is een taal waarin de instructies worden geconverteerd van wat u hebt geschreven naar machinecode terwijl het programma wordt uitgevoerd. Een geïnterpreteerde taal krijgt in feite een instructie van de programmabron en converteert deze naar een machine code, voert die machinecode uit en pakt dan de volgende instructie van de bron om de te herhalen werkwijze.

Een variant maakt gebruik van een proces in twee fasen. Bij deze variant wordt de bron van uw programma niet direct in de machinecode gecompileerd maar wordt in plaats daarvan geconverteerd naar een assembly-achtige taal die nog steeds onafhankelijk is van het specifieke processor. Wanneer u de code wilt uitvoeren, verwerkt deze vervolgens de gecompileerde code via een interpreter die specifiek is voor de processor om de machinecode te krijgen die geschikt is voor die processor. Deze benadering heeft veel voordelen van compileren met behoud van de processoronafhankelijkheid, aangezien dezelfde gecompileerde code door veel verschillende processors kan worden geïnterpreteerd. Java is een taal die deze variant vaak gebruikt.

De andere variant wordt een Just in Time-compiler (of JIT) genoemd. Met deze aanpak voer je de compiler niet uit nadat je je code hebt geschreven. In plaats daarvan gebeurt dat automatisch wanneer u de code uitvoert. Met behulp van een Just in Time-compiler wordt de code niet statement voor statement geïnterpreteerd, maar wordt alles in één gecompileerd ga elke keer wanneer het wordt aangeroepen om te worden uitgevoerd en dan krijgt de gecompileerde versie die het zojuist heeft gemaakt rennen. Deze benadering zorgt ervoor dat het lijkt alsof de code wordt geïnterpreteerd, behalve dat er in plaats van fouten alleen worden gevonden wanneer de instructie met de fout is bereikt, alle fouten die door de compiler worden gedetecteerd, resulteren in het niet uitvoeren van de code in plaats van dat alle code tot op dat moment wordt uitgevoerd rennen. PHP is een voorbeeld van een taal die gewoonlijk just in time compilatie gebruikt.

Dus nu we weten wat geïnterpreteerde code en gecompileerde code betekenen, is de vraag die we vervolgens moeten beantwoorden, wat heeft dit allemaal met JavaScript te maken? Afhankelijk van waar u uw JavaScript precies uitvoert, kan de code worden samengesteld of geïnterpreteerd of een van de andere twee genoemde varianten gebruiken. Meestal ben je dat weluw JavaScript uitvoeren in een webbrowser en daar wordt JavaScript meestal geïnterpreteerd.

Geïnterpreteerde talen zijn doorgaans langzamer dan gecompileerde talen. Hiervoor zijn twee redenen. Ten eerste moet de te interpreteren code eigenlijk worden geïnterpreteerd voordat deze kan worden uitgevoerd, en ten tweede ook elke keer dat de instructie moet worden uitgevoerd (niet alleen elke keer dat u JavaScript uitvoert, maar ook als deze erin staat) een lus dan moet het elke keer rond de lus worden gedaan). Dit betekent dat code die in JavaScript is geschreven, langzamer zal werken dan code die in veel andere talen is geschreven.

Hoe helpt dit om ons te helpen waar JavaScript de enige taal is die beschikbaar is voor alle webbrowsers? De JavaScript-interpreter zelf die in de webbrowser is ingebouwd, is niet in JavaScript geschreven. In plaats daarvan is het geschreven in een andere taal die vervolgens is samengesteld. Wat dit betekent is dat u uw JavaScript sneller kunt laten werken als u kunt profiteren van alle opdrachten die JavaScript biedt waarmee u de taak naar de JavaScript-engine zelf kunt overzetten.

Een voorbeeld hiervan is dat sommige maar niet alle browsers een methode document.getElementsByClassName () hebben geïmplementeerd in de JavaScript-engine, terwijl andere dat nog niet hebben gedaan. Wanneer we deze specifieke functionaliteit nodig hebben, kunnen we zien dat code sneller wordt uitgevoerd in die browsers waar de JavaScript-engine deze biedt met behulp van de functie waarnemen om te zien of de methode al bestaat en alleen onze eigen versie van die code in JavaScript maken als de JavaScript-engine dit niet biedt ons. Waar de JavaScript-engine die functionaliteit biedt, zou deze sneller moeten werken als we die gebruiken in plaats van onze eigen versie in JavaScript uit te voeren. Hetzelfde geldt voor elke verwerking die de JavaScript-engine ons ter beschikking stelt om rechtstreeks te bellen.

Er zullen ook gevallen zijn waarin JavaScript meerdere manieren biedt om hetzelfde verzoek te doen. In die gevallen kan een van de manieren om toegang te krijgen tot de informatie specifieker zijn dan de andere. Bijvoorbeeld document.getElementsByTagName ('table') [0] .tBodies en document.getElementsByTagName ('table') [0] .getElementsByTagName ('tbody') beide haal dezelfde nodelist op van de tbody-tags in de eerste tabel op de webpagina, maar de eerste is een specifieke opdracht voor het ophalen de tbody-tags waarbij de tweede aangeeft dat we tbody-tags in een parameter ophalen en andere waarden kunnen worden vervangen om andere op te halen tags. In de meeste browsers zal de kortere en specifiekere variant van de code sneller werken (in sommige gevallen veel sneller) dan de tweede variant en daarom is het logisch om de kortere en meer specifieke te gebruiken versie. Het maakt de code ook gemakkelijker te lezen en te onderhouden.

In veel van deze gevallen zal het werkelijke verschil in verwerkingstijd echter zeer klein zijn en pas wanneer u voegt veel van dergelijke codekeuzes bij elkaar zodat u een merkbaar verschil krijgt in de tijd die uw code nodig heeft rennen. Het is echter vrij zeldzaam dat het wijzigen van uw code om deze sneller te laten werken, de code aanzienlijk langer of moeilijker zal maken, en vaak zal het omgekeerde het geval zijn. Er is ook het extra voordeel dat toekomstige versies van JavaScript-engines kunnen worden gemaakt die de meer specifieke variant zelfs versnellen verder zodat het gebruik van de specifieke variant kan betekenen dat uw code in de toekomst sneller zal werken zonder dat u iets hoeft te veranderen.