type="text/html", Speicherverwaltung

[normal]

Hallo zusammen,

ich habe zwei Fragen zu JavaScript, und fasse diese mal in ein Posting zusammen (sorry).

1. Wenn man sich den Quellcode von www.amazon.de anschaut, findet man Abschnitte wie folgt:

<script type='text/html' id='nav-tpl-wishlist'>  
  <# jQuery.each(wishlist, function (i, item) { #>  
    <li class='nav_pop_li'>  
      <a href='<#=item.url #>' class='nav_a'>  
        <#=item.name #>  
      </a>  
      <div class='nav_tag'>  
        <# if(typeof item.count !='undefined') { #>  
          <#=  
            (item.count == 1 ? "{count} artikel" : "{count} Artikel")  
              .replace("{count}", item.count)  
          #>  
        <# } #>  
      </div>  
    </li>  
  <# }); #>  
</script>

Das erinnert mich an ASP & Co. Aber clientseitig verwundert mich sowas dann doch ein wenig. Weiß jemand zufällig was das bewirkt? Ist das "<# ... #>" Teil der JavaScript-Spezifikation?

2. Es geht um die Speicherverwaltung von JS-Objekte. Ist es sinnvoll nicht mehr verwendete Objekte aus dem Speicher zu werfen, indem man ihnen den Wert null zuweist oder vielleicht via delete?

var demo = new Date();  
...  
demo = null; // <--- sinnvoll, um Speicher frei zugeben?

Danke

[ChrisB]

Hi,

1. Wenn man sich den Quellcode von www.amazon.de anschaut, findet man Abschnitte wie folgt:

<script type='text/html' id='nav-tpl-wishlist'>

<# jQuery.each(wishlist, function (i, item) { #>
    <li class='nav_pop_li'>
…

>   
> Das erinnert mich an ASP & Co. Aber clientseitig verwundert mich sowas dann doch ein wenig. Weiß jemand zufällig was das bewirkt?  
  
<http://www.w3.org/TR/html5/scripting-1.html#the-script-element>:  
  

> The script element allows authors to include dynamic script and data blocks in their documents.  
  
“and data blocks” ist der wichtige Teil hier.  
Mit einer type-Angabe, die keinen ausführbaren Script-Code beschreibt, kann man „Daten” mittels script-Elementen einbinden.  
  

> Ist das "<# ... #>" Teil der JavaScript-Spezifikation?  
  
Nein. Das wird irgendein Parser, für den diese Daten bestimmt sind, auswerten.  
  
Wenn du genau hinschaust, siehst du das die <# … #> jQuery-Code und eine Art Platzhalter für Variablenausgabe enthalten; wohingegen der Rest, ohne #, reines HTML ist. Es wird sich also um irgendeine Art von Template-Sprache handeln.  
  
MfG ChrisB  
  

-- 
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

[molily]

Hallo,

1. Wenn man sich den Quellcode von www.amazon.de anschaut, findet man Abschnitte wie folgt:

<script type='text/html' id='nav-tpl-wishlist'>

<# jQuery.each(wishlist, function (i, item) { #>
    <li class='nav_pop_li'>
      <a href='<#=item.url #>' class='nav_a'>
        <#=item.name #>
      </a>
      <div class='nav_tag'>
        <# if(typeof item.count !='undefined') { #>
          <#=
            (item.count == 1 ? "{count} artikel" : "{count} Artikel")
              .replace("{count}", item.count)
          #>
        <# } #>
      </div>
    </li>
  <# }); #>
</script>

>   
> Das erinnert mich an ASP & Co. Aber clientseitig verwundert mich sowas dann doch ein wenig.  
  
Das ist ein Template, das von clientseitigem JavaScript verarbeitet wird. Es gibt dutzende [Templating-Engines in JavaScript](http://garann.github.io/template-chooser/).  
  

> Weiß jemand zufällig was das bewirkt?  
  
Es bewirkt erst einmal nichts. Der Browser ignoriert script-Elemente mit type="text/html". Es hätte auch type="husseldiguggeldidu" dort stehen können.  
  
Ein JavaScript liest den Inhalt des Elements aus und kompiliert das Template zu einer JavaScript-Funktion. Die wird mit gewissen Daten aufgerufen (Rendern des Templates). Es kommt HTML mit den eingebetteten Daten heraus, das ins Dokument eingebunden wird.  
  
Viele clientseitige JavaScript-Anwendungen arbeiten mittlerweile so: Sie laden Rohdaten als JSON vom Server und rendern das letztlich angezeigte HTML mithilfe von Templates im Browser.  
  

> Ist das "<# ... #>" Teil der JavaScript-Spezifikation?  
  
Nein, das ist einfach die Syntax der Templating-Engine, um JavaScript-Code ins Template einzubetten. Andere Templating-Engines verwenden eine andere Syntax, und viele sind konfigurierbar.  
  
Ich persönlich nutze meist [HAML Coffee](https://github.com/netzpirat/haml-coffee). Das erlaubt HTML im [HAML](http://haml.info/)-Stil mit eingebettetem [CoffeeScript](http://coffeescript.org/).  
  

> 2. Es geht um die Speicherverwaltung von JS-Objekte. Ist es sinnvoll nicht mehr verwendete Objekte aus dem Speicher zu werfen, indem man ihnen den Wert null zuweist oder vielleicht via delete?  
>   
> ~~~javascript

var demo = new Date();  

> ...  
> demo = null; // <--- sinnvoll, um Speicher frei zugeben?

Das kann man so pauschal nicht sagen. Im Allgemeinen ist das nicht nötig.

JavaScript ist keine Sprache, bei der man Speicher händisch kontrollieren kann und Objekte explizit freigeben muss. JavaScript-Engines verfügen über sogenannte Garbage Collection (Speicherbereinigung). Dabei werden nicht mehr erreichbare Objekte automatisch aus dem Speicher gelöscht. Das betrifft z.B. lokale Variablen, die nicht von außen zugänglich sind.

Solange man dafür sorgt, dass die meisten Objekte, die man anlegt, beim nächsten Lauf des Garbage Collectors weggeworfen werden können, braucht man nicht explizit Referenzen auf null zu setzen.

Allerdings kann es vorkommen, dass Referenzen auf Objekte überleben und die Objekte damit nicht weggeräumt werden können. Wenn immer mehr von diesen Objekten erzeugt werden, kann es zu Speicherlecks (Memory Leaks) kommen. In solchen Fällen kann es sinnvoll sein, Variablen und Objekteigenschaften auf null zu setzen bzw. Objekteigenschaften mit dem delete-Operator zu entfernen.

Closures sind eine Technik, mit der absichtlich, aber auch unabsichtlich Referenzen auf Objekte angelegt werden, die sie vor der Garbage Collection schützen.

Solche Probleme hat man eigentlich erst in komplexen JavaScript-Webanwendungen, bei denen Objekte durch Referenzen wild verknüpft werden und Closures Objekte konservieren können, die später restlos entfernt werden sollen. Ich habe ein MVC-Framework für JavaScript-Apps mitentwickelt, das einen starken Wert auf Memory-Management legt.

Grüße,
Mathias

[normal]

Hallo,

erstmal Danke Mathias und ChrisB. Bislang dachte ich immer, dass beim Script-Tag JavaScript so als Voreinstellung angenommen wird, sofern man kein type=".." oder language=".." gesetzt hat. Wenn ich mir hier in der Firma so den Quelltext (im Browser) von MS-CRM anschaue, dann taucht da öfters einfach ein <script>..</script> auf. Da habe ich wohl 1 und 1 zusammengezählt und bin auf 0 gekommen ^^.

Closures sind eine Technik, mit der absichtlich, aber auch unabsichtlich Referenzen auf Objekte angelegt werden, die sie vor der Garbage Collection schützen.

Und das ist wohl auch der Punkt, der mich so plagt. Diese Technik wir ja öfters ganz unbewußt eingesetzt, jedenfalls von mir. Kann man das irgendwie "überwachen" oder prüfen, ob es zu Speicherleaks kommt? Ok, ich kann mir den Taskmanager anschauen, aber dann weiß man ja nicht, wo genau die Ursache liegt.

Gruß normal

[ChrisB]

Hi,

Bislang dachte ich immer, dass beim Script-Tag JavaScript so als Voreinstellung angenommen wird, sofern man kein type=".." oder language=".." gesetzt hat. Wenn ich mir hier in der Firma so den Quelltext (im Browser) von MS-CRM anschaue, dann taucht da öfters einfach ein <script>..</script> auf.

http://www.w3.org/TR/html5/scripting-1.html#attr-script-type:

“The type attribute gives the language of the script or format of the data. […] The default, which is used if the attribute is absent, is "text/javascript".”

Das ist mit HTML5 so spezifiziert worden.

Aber da Browser selten überhaupt andere Arten von clientseitigem Scripting unterstützen, sind sie auch vor HTML5 idR. schon von JavaScript ausgegangen, wenn keine Angabe gemacht wurde. Und die paar anderen Arten von client-seitigem Scripting, die manch ein Browser unterstützt haben mag, mussten dann explizit als solche angegeben werden.

MfG ChrisB