nicht angemeldet
Hallo,
- 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