Aloha ;)

Bei der Ajax-Lösung hat man eine saubere Trennung zwischen Programmlogik (JavaScript) und dynmaischen Zuständen (JSON). Die Programmlogik wird sich hoffentlich nicht all zu oft ändern, die Zustände vermutlich schon. Bei der Ajax-Lösung ist es deshalb möglich die Programm-Logik sehr lange zu cachen und nur die Zustände regelmäßig neu anzufordern. Bei eurer Lösung, wird beides über einen Kamm gescherrt und infolgedessen muss das gesamte JavaScript-Teilprogramm neugeladen werden, wenn sich nur die Zustände ändern.

Nun, das stimmt. Das ist aber nur dann ein Vorteil, wenn die Zustände tatsächlich dynamisch sind oder sein können. Wenn du das Ursprungsproblem nachliest wird dir auffallen, dass der TO selbst keine dynamischen Zustandsänderungen vorgesehen hatte, sondern lediglich statische, nur vom User abhängige Variablen von PHP an JS übergeben wollte.

Selbstverständlich benötige ich AJAX, um dynamische Zustände zu verarbeiten. Das ist aber überhaupt nicht der Punkt, um den es afaik hier gerade geht. Auch in der loader.php-Lösung können dynamische Zustände zusätzlich durch AJAX angefordert werden, es ging aber im Grundsatz nur darum, mit welcher Methode man ein bestimmtes Set statischer Variablen möglichst effizient an JS weitergeben kann.

Was wunderbar ist, denn dein ursprüngliches Beispiel hat kein Problem mit Manipulierbarkeit ;)

Stimmt. Ich gebe zu, dass Manipulierbarkeitsdiskussionen meinerseits hier mehr Schattengefecht sind als tatsächlich substantiell.

Und ich habe wieder redundanten Code, weil ich den AJAX für jedes einzubindende Javascript einzeln ausführen muss, da diese ja optimalerweise auch unabhängig voneinander stattfinden sollen.

Ich sehe nicht, wieso das zu redundatem Code führen sollte? Kannst du ein Mini-Beispiel bauen? Ich bin mir sicher, dass sich auch dafür schnell eine Lösung finden ließe. In der Regel, kann man das DRY-Prinzip immer sehr einfach erreichen, indem man ein zustätzlichen Level an Abstraktion einfügt, häufig kann das bereits durch eine einfache Funktion erreicht werden.

Ja, kann ich. Sagen wir, ich habe ein System am laufen, das zentral unterschiedlichste Seiten zusammenbaut (wie die Frontend-Ausgabe eines CMS). Es gibt drei JS-Skripte namens a.js, b.js und c.js; diese werden vom System nur da verbaut, wo sie gebraucht werden. Alle drei benötigen aber Zugriff auf statische Variablen des CMS, beispielswiese den Namen des registrierten Users (wieso auch immer). Dann habe ich zwei Möglichkeiten - denn a.js, b.js und c.js sollen ja untereinander autark sein:

Möglichkeit 1: ich programmiere in jedes der Skripte Passagen, die das laden der statischen Variablen per AJAX anleiern. Das ist der redundante Code, von dem ich sprach.

Möglichkeit 2: Ich lade auf ALLEN Seiten ein zusätzliches Skript varload.js ein, welches das Laden der statischen Variablen per AJAX zentral übernimmt. Dann gibt es aber in der Funktionalität zwischen der AJAX-Methode und der von mir genannten inline-script Methode keinen Unterschied mehr - mit den Nachteilen in der AJAX-Methode, dass sie immer einen Request mehr braucht, nicht sofort einsatzfähig ist, ein zusätzliches PHP-Skript zum Beantworten des Request geschrieben haben will, in welchem ich die dem HTML-Konstruktor schon bekannten Daten noch einmal zusammensammeln muss...

Summa summarum (natürlich nur auf das Problem statisched Zustände bezogen, über alles andere müssen wir gar nicht diskutieren): Entweder haben wir redundanten Code, oder die Methode führt sich ad absurdum, da sie exakt und ausschließlich das gleiche leistet wie das inline-script, dabei aber deutlich höheren Programmieraufwand erfordert.

Selbst wenn ich zusätzlich dynamische Zustände habe, würde ich mich wohl dafür entscheiden, die statischen Zustände über eine der beiden anderen Methoden (wahrscheinlich am ehesten inline-script) zu besorgen und ausschließlich die dynamischen Zustände bei Bedarf je per AJAX anfordern (Man bedenke: richtig dynamische Zustände sollten gar nicht länger zwischengespeichert werden, sondern bei Bedarf angefordert - sie könnten sich sonst dynamisch geändert haben). Das ist in meinen Augen nach allen Aspekten (Overhead, schnelle Verfügbarkeit, Programmieraufwand, ...) die effizienteste Lösung. (Das Ersetzen von Platzhaltern statt dem inline-script macht nur dann Sinn, wenn ich die einzusetzenden Variablen ohne (größeren) programmiertechnischen Neuaufwand ermitteln kann).

Grüße,

RIDER

Hakuna matata!

Aloha ;)

Einverstanden, aber Platzhalter in JavaScript-Code sind nicht sinnvoll. Es fängt damit an, dass man keine Modultests für solche generischen Skript-Bausteine entwickeln kann. [...] Syntax-Highlighting, Precompiler (minfiy, browserify) und Dependency-Injectors. Und auch andere Werkzeuge, wie Modul-Loader (require.js) arbeiten nicht nahtlos mit JS-Templates zusammen. Kurz und bündig: das gesamte JavaScript-Ökosystem wird dir überm' Kopf zusammenbrechen.

Tatsächlich?

Syntax-Highlighting und Precompiler sollten mit Platzhaltern genauso arbeiten, da valides JS erzeugt wird […]

Wird es nicht. Gehen wir von folgendem Template aus:
var foo = '<?= $foo ?>';
Und im PHP:
$foo = "arrr'rrrk";
Das fertig gerenderte Template, sähe dann so aus:
var foo = 'arrr'rrrk';

Man könnte jetzt hingehen und das Anführungszeichen maskieren, die korrekte Ausgabe wäre dann:
var foo = 'arrr\'rrrk';

So, aber was wenn nun die Template-Variable nicht von einfachen, sondern von doppelten Anführungszeichen umschlossen wird? Das Ergebnis nach unserer Anpassung von gerade, wäre diesmal zwar kein Syntax-Fehler, aber auch nicht die Zeichenkette, die wir erwarten würden:

var foo = "arrr\'rrrk";

Für diese konstruierten Fall, ließe sich wieder ein Lösung finden, aber um es kurz zu machen: eine allgemine Lösung für die Problemklasse erhält man nur, wenn man der Template-Engine gestattet die umschließenden String-Begrenzer selbst zu generieren. Also in etwa so:

var foo = <?= json_encode( $foo ); ?>

json_encode eignet sich zum Glück hervorragend, um JavaScript-Strings zu maskieren. Das Problem an dieser Stelle ist aber eben, dass der Platzhalter nun nicht mehr von JavaScript-String-Begrenzern umgeben wird, ein JavaScript-Parser (1) würde hier also auf die öffnende Spitze Klammer stoßen und sich dann verabschieden. Eben habe ich von static Analysis gesprochen, das ist beschreibt die Fähigkeit Aussagen über Code zu treffen, ohne ihn ausführen zu müssen. Das erfordert aber Syntax-Parsing, und eine ganze Reihe Werkzeuge, die ich eben auch schon genannt habe, hängt davon ab und wie wir gerade gesehen haben können wir kontextgerechte Maskierung und Syntax-Parsing nicht gleichzeitig haben. hottis etwas andere Syntax für Platzhaler, kann das übrigens auch nicht, sie hat mit genau dem gleichen Problem zu kämpfen.

1. Ein JavaScript-Parser ist kein Interpreter, der Parser sorgt erstmal nur dafür den JavaScript-Code in einen abstrakten Syntaxbaum zu übersetzen. Das habe ich in meinen Anfangstagen als Programmierer noch nicht gewusst, und konnte mich sehr verwirren. Aus diesem Grund die Fußnote für Entwickler, denen es vielleicht so ähnlich geht.