Dette indlæg er alene udtryk for skribentens egen holdning.
Blogindlæg

JavaScript: Det mest mærkværdige

5. maj 2013 kl. 11:0616
person
Anne-Sofie Nielsen
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.
person
Anne-Sofie Nielsen

Jeg er ved at strikke et fordrag sammen om det næsten uudtømmelige emne "JavaScript in Browsers - WTF", som jeg skal holde på JSDay i Italien om halvanden uges tid. Den gode nyhed er dog, at det med de seneste udgave af de mest populære browsere trods alt må være muligt at holde sig indenfor tidsrammen på en halv time; hvis jeg havde skullet holde foredraget, da IE6 var på sit højeste, er jeg ikke sikker på, at tilhørerne havde nået at få frokosten med den dag.

En af mine favorit-mærkværdigheder i JavaScript er eval-funktionen. Der er flere ting, der er sjov ved den, bl.a. at navnet har en helt afgørende betydning:

Hvem får ret her?

  1. var mening = "Gnavensmølf: Jeg hader JavaScript";
  2.  
  3. function hvadSynesDu() {
  4.      var mening = "Pyntsmølf: JavaScript er så smukt";
  5.      eval("alert(mening);");
  6. }
  7. hvadSynesDu();

Eller her?

  1. var mening = "Gnavensmølf: Jeg hader JavaScript";
  2. var f = eval;
  3.  
  4. function hvadSynesDu() {
  5.      var mening = "Pyntsmølf: JavaScript er så smukt";
  6.      f("alert(mening);");
  7. }
  8. hvadSynesDu();

Overraskende nok får man forskelligt resultat i det første og andet eksempel, selvom eneste forskel er, at man i det andet eksempel giver eval-funktionen et alias (f). Når eval-funktionen tildeles et alias, ændrer det på hvilket scope, den evaluerer i. I første eksempel evalueres i local scope (og det bliver derfor pyntesmølfs mening, vi får at høre), mens det i andet eksempel evalueres i global scope (og det bliver derfor gnavensmølf, vi hører fra).

Artiklen fortsætter efter annoncen

Hvad så med setTimeout? Her kan man også nemt blive snydt af scope.

  1. var mening = "Gnavensmølf: Jeg hader JavaScript";
  2.  
  3. function hvadSynesDu() {
  4.      var mening = "Pyntsmølf: JavaScript er så smukt";
  5.      setTimeout("alert(mening);", 100);
  6. }
  7. hvadSynesDu();

er ikke helt det samme som

  1. var mening = "Gnavensmølf: Jeg hader JavaScript";
  2.  
  3. function hvadSynesDu() {
  4.      var mening = "Pyntsmølf: JavaScript er så smukt";
  5.      setTimeout(function () { alert(mening);}, 100);
  6. }
  7. hvadSynesDu();

I første tilfælde vil vi høre fra gnavensmølf, fordi den streng, der er givet som første argument til setTimeout, evalueres i global scope. I det andet tilfælde, hvor vi har givet en funktion som argument, vil "mening"-variablen referere til den lokalt definerede, og vi får derfor pyntesmølfs mening at høre.

Det er sådan noget, der gør JavaScript rigtig svært at læse nogle gange; små detaljer kan have stor betydning.

Hvad er det mærkeligste, du har oplevet med JavaScript?

Emner
16 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Køb abonnementFå prøveabonnement

Jobs

Dine job
Vis alle

Fortsæt din læsning

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
12
Allan Ebdrup
8. maj 2013 kl. 07:09

Sjovt eksempel du kommer med. Det er rimelige underlig opførsel fra JS-side.

Jeg har helt instinktivt holdt mig langs væk fra eval, og at kalde setTimeout med en streng, siden jeg begyndte med store JavaScript apps i 2002, altså lang tid før JavaScript: the good parts bogen kom i 2008 http://shop.oreilly.com/product/9780596517748.do og lang tid før JSLint og JSHint. Man roder bare ikke rundt med sin kode som en streng, og slet ikke noget kode der kalder ting fra det omkringliggende scope. Medmindre der virkelig ikke er andre måder at gøre det på. Og det er der som regel.

Der har været nogle få ting der har irriteret mig ved JS, den der bugger mig mest i praksis er nok den måde NaN fungerer. Der kan du finde nogle eksempler på mærkelighed, som folk rent faktisk vil støde på i deres hverdag med JS.

  • more_vert
    • insert_linkKopier link
14
Anne-Sofie Nielsen
8. maj 2013 kl. 09:30

Der har været nogle få ting der har irriteret mig ved JS, den der bugger mig mest i praksis er nok den måde NaN fungerer. Der kan du finde nogle eksempler på mærkelighed, som folk rent faktisk vil støde på i deres hverdag med JS.

Der er selvfølgelig de klassiske "WTF" med at

  1. typeof(NaN) == "number"
og
  1. NaN != NaN

og så at NaN dukker op på tidspunkter, hvor man mindst venter det, fordi JavaScript i mange tilfælde er "venligt" og ikke kaster exceptions:

  1. var d = new Date("vrøvl");
  2. alert(d.getMonth());
hvor det, man får ud af at kalde d.getMonth() på en date, der er konstrueret med en ugyldig værdi, bliver NaN.

  • more_vert
    • insert_linkKopier link
3
Slettet bruger
5. maj 2013 kl. 13:12

Jeg opdagede at det in ny version af Node.js er hurtigere at benytte capturing groups i regular expressions end at benytte non-capturing groups. Gennemgående virker det som at det er hastighedsoptimeringerne der virkelig kan rykke JavaScript på WTF fronten i øjeblikket. Sproget er så gennemgående ukompilerbart at der sker rigtigt mange sjove ting når man alligevel forsøger at kompilere det i en eller anden grad.

Ellers er jeg vist efterhånden så vant til JavaScript at sproget normalt virker ganske logisk.

Dit første eksempel virker i øvrigt ikke som det ser ud til, prøv at køre:

  1. var mening = "Gnavensmølf: Jeg hader JavaScript";
  2.  
  3. function hvadSynesDu() {
  4.      var mening = "Pyntsmølf: JavaScript er så smukt";
  5.      (1,eval)("alert(mening);");
  6. }
  7. hvadSynesDu();

Et meget grimt hack i ES5: http://perfectionkills.com/global-eval-what-are-the-options/

  • more_vert
    • insert_linkKopier link
5
Anne-Sofie Nielsen
5. maj 2013 kl. 14:59

Dit første eksempel virker i øvrigt ikke som det ser ud til

Hm, nu har jeg lige prøvet igen og det ser da ud til at virke fint - har prøvet i Chrome og IE, da jeg ikke lige har Firefox installeret på den computer, jeg sidder ved her.

Der er det pyntesmølfen, der får lov at sige noget, altså lokalt scope. I dit eksempel - som er en anden måde at lave indirekte kald af eval end at lave et alias - er det det globale scope, man rammer, som der jo også står i artiklen. Og det synes jeg godt nok er forvirrende!

  • more_vert
    • insert_linkKopier link
7
Slettet bruger
5. maj 2013 kl. 17:45

Virkningen er som du skriver, din kode kode ser blot ud til at være bygget på troen om en anden (og langt mere logisk) sammenhæng.

@Jesper Kristensen - Re: Andre mærkværdigheder Det memory leak har ikke så meget med eval at gøre, eval er blot det element som i dette tilfælde forhindrer garbage collectoren i at fjerne a i den ydre funktion. Du kunne også have skrevet:

  1. <div id="counter"></div>  
  2. <script>  
  3. var counter = document.getElementById("counter");  
  4. var count = 0;  
  5. var list = [];  
  6. setInterval(function() {  
  7.     var a = [];  
  8.     for (var i = 0; i < 1000000; i++)  
  9.         a.push(i);  
  10.     count++;  
  11.     counter.textContent = count;  
  12.     list.push(function() {  
  13.         var b = a;
  14.     });  
  15. }, 0);  
  16. </script>

Hvilken giver et tilsvarende møster helt uden brug af eval.

  • more_vert
    • insert_linkKopier link
10
Anne-Sofie Nielsen
5. maj 2013 kl. 20:18

Ifølge det link om JS memory leaks, som jeg skrev om lige før, så behøvede man ikke engang at referere "a" i Jacobs eksempel; der ville alligevel være et memory leak:

JavaScript interpreter has no idea which variables may be required by the inner function, so it keeps everything. In every outer LexicalEnvironment. I hope, newer interpreters try to optimize it, but not sure about their success.

Jeg har dog ikke efterprøvet det; det var måske værd at gøre, da siden er fra 2011.

  • more_vert
    • insert_linkKopier link
8
Anne-Sofie Nielsen
5. maj 2013 kl. 18:43

Jacob skrev:

Hvilken giver et tilsvarende møster helt uden brug af eval.

Ja, men jeg synes da nok, at det i Jespers eksempel er sværere at gennemskue, at man har et memory leak, fordi a ikke kan garbage collectes. I eksemplet uden eval er det lidt mere lige til at se, at man holder en reference til a.

IE8 og tidligere havde i øvrigt et endnu mere uigennemskueligt memory leak-problem i forbindelse med XMLHttpRequests, men det har de da heldigvis fikset i 9'eren.

Fald for resten over et interessant skriv om typiske memory leaks i JavaScript her: http://javascript.info/tutorial/memory-leaks

  • more_vert
    • insert_linkKopier link
2
Jesper Kristensen
5. maj 2013 kl. 12:58

Jeg synes faktisk ikke dit eksempel er så interessant. Eval er noget skidt (både funktionen og operatoren) og det eneste man skal vide om den er at man aldrig skal bruge den, og hvis man ser noget kode der bruger den skal man skrive den om. Hvis man skal eksekvere en tekststreng som JavaScript, kan man bruge Function-constructoren.

Hvis man bruger "eval" eller "with" stopper browseren al JIT-optiomering, så det er relativt nemt at huske, at man bare skal lade være med at bruge dem.

Det er langt "sjovere" når det kommer til mærkværdigheder, som man faktisk kan støde på i reel kode.

Her er et af mine yndlings-eksempler: [html]

<script>var open = "hello"</script>

A

<script>document.getElementById('x').onclick = function() { alert(open); };</script>

BC[/html]

Her overskriver vi browserens indbyggede window.open()-funktion, og prøver at læse værdien af den på tre forskellige måder. Hvis man klikker på A får man som forventet den overskrevne værdi, men hvis man klikker på B, får man på mystisk vis den oprindelige værdi. Et klik på C giver igen den overskrevne værdi. Det kan være en udfordring når en browser begynder at implementere en ny standard, som tilfældigvis bruger samme navn som en af dine globale variable.

http://wtfjs.com/ har også en lang række eksempler.

  • more_vert
    • insert_linkKopier link
13
Anne-Sofie Nielsen
8. maj 2013 kl. 09:27
  • more_vert
    • insert_linkKopier link
4
Slettet bruger
5. maj 2013 kl. 13:54

Hvis man bruger "eval" eller "with" stopper browseren al JIT-optiomering, så det er relativt nemt at huske, at man bare skal lade være med at bruge dem.

Gammel skrøne, jeg har lige prøvet med både Chrome og IE9 og ingen af dem giver bare en antydning af ændret performance ved at evale og withe et stykke ikke-performance-kritisk kode. Dertil er Chrome også fuldstændig ligeglad med at performance kritisk kode er defineret inde i en eval, jeg kan lave hele bunken af JavaScript om til en streng og evale den med et enkelt kald, det gør ikke nogen synlig forskel.

  • more_vert
    • insert_linkKopier link
6
Jesper Kristensen
5. maj 2013 kl. 16:00

Ok, jeg kan godt se det var upræcist hvad jeg skrev. Browseren kan stadig foretage mange optimeringer, men der er nogen den ikke kan bruge, når man bruger direct eval eller with. Her er en simpel kode med en memory leak. Men den er noget større med direct eval i forhold til indirect eval (testet i Firefox og Chrome).

[html]

<script> var counter = document.getElementById("counter"); var count = 0; var list = []; setInterval(function() { var a = []; for (var i = 0; i < 1000000; i++) a.push(i); count++; counter.textContent = count; list.push(function() { var b = eval("1+1"); //var b = (1,eval)("1+1"); }); }, 0); </script> [/html]
  • more_vert
    • insert_linkKopier link
15
Peter Mogensen
8. maj 2013 kl. 09:49

Hehe ... jae... Men uden at jeg på nogen måde er ekspert i hverken JS eller Node.js, så er mit indtryk at det primært skyldes at event-baseret eksekvering er default og alt kode inkl. libraries dermed er gennemsyret af det. Det giver det nogle fordele fremfor f.eks. Perl, hvor mange libraries slet ikke spiller sammen med en event-baseret model og du derfor afskriver dig en masse standard-libraries, hvis du ønsker det. De fleste script-sprog (inkl. Perl) har nu nogen gange nogle mærkværdigheder, der gør man får helt lyst til at kode tingene om i C.

  • more_vert
    • insert_linkKopier link