JPKCom DB

Playground — Tipps & Tricks

Kniffe für den Playground: Live-Modus dosieren, Sandbox verstehen, SCSS- und PHP-Modus im Griff behalten, nichts verlieren und typische Stolperfallen umgehen.

Zurück zur Übersicht: Playground · Tool live öffnen: www.jpkc.com/tools/playground/

Das Manual erklärt jede Funktion, die Beispiele zeigen die Abläufe. Hier geht es um das, was beides voraussetzt, aber selten dabeisteht: wie du den Live-Modus dosierst, was die Sandbox wirklich bedeutet und welche Stolperfallen dich Zeit kosten. Die Oberfläche ist auf Englisch — die echten Button- und Label-Namen stehen deshalb im Original, bei Bedarf mit deutscher Erläuterung.

Den Live-Modus klug einsetzen

  • Bei „teurem" Code Live ausschalten. Der Live-Modus baut die Vorschau nach jeder Eingabe neu (leicht verzögert). Bei rechenintensivem JS, vielen Animationen oder ständigem Neurendern wird das hakelig. Schalt dann die Live-Checkbox aus und baue gezielt mit Run (Strg/Cmd+Enter) — du behältst die Kontrolle, wann gerendert wird.
  • Vorsicht mit Endlosschleifen. Dein JS läuft im Vorschau-<iframe> desselben Browsers. Eine while(true)-Schleife oder ein unbeabsichtigter Dauerlauf friert die Vorschau ein (im Extremfall den ganzen Tab). Schalt vor dem Testen verdächtiger Schleifen-Logik Live aus, damit nicht schon beim Tippen ein halbfertiger Endlos-Code startet — und führ ihn dann kontrolliert per Run aus.
  • HTML Source als Kontrollblick. Wenn die Vorschau nicht das zeigt, was du erwartest, schalt im Vorschau-Header auf HTML Source. Dort siehst du das vollständige Dokument, das der Playground baut — inklusive der Reihenfolge von Assets, <style> und deinem Skript am Body-Ende. Oft erklärt sich ein Problem schon hier.

Die Sandbox verstehen

Die Vorschau läuft in einem sandbox-<iframe> ohne allow-same-origin. Das hat Konsequenzen, die nichts mit deinem Code zu tun haben, sondern mit der Umgebung:

  • Kein gemeinsamer Speicher mit der Hauptseite. Der Vorschau-Code hat keinen Zugriff auf Cookies, LocalStorage oder das DOM des Playgrounds. Das ist Absicht (Sicherheit) — aber erklärt, warum manche „normalerweise funktionierenden" Browser-APIs in der Vorschau anders reagieren.
  • Fremde Skripte bleiben draußen, fetch kann an CORS scheitern. Die Vorschau erbt die Content Security Policy der Tool-Seite: Skripte und Stylesheets per <script src>/<link> von fremden Servern (etwa einem CDN) blockiert der Browser. Erlaubt sind die Bibliotheken aus dem Asset-Dropdown, Google Fonts und Bilder per https:; fremde <iframe>-Embeds, Audio und Video von fremden Servern bleiben ebenfalls draußen. fetch() auf https:-APIs ist zulässig — weil das Vorschau-Dokument aber einen undurchsichtigen (opaquen) Ursprung hat, schlägt der Aufruf fehl, wenn die API keine offenen CORS-Header schickt. Das ist kein Playground-Bug, sondern Browser-Sicherheit.
  • prompt/alert/Popups gehen. Die Sandbox erlaubt bewusst allow-modals und allow-popups — das Demo-Beispiel nutzt prompt(), und das funktioniert.
  • Der „neue Tab" ist die Ausnahme. Open preview in new tab öffnet dein Dokument als normale Seite ohne Sandbox — und zwar im Ursprung der Tool-Seite. Genau dann laufen Dinge, die nur die Sandbox des eingebetteten <iframe> blockiert. Die Content Security Policy der Tool-Seite gilt dort allerdings weiter, CDN-Skripte bleiben also auch im neuen Tab draußen. Praktisch zum vollwertigen Testen, aber der Code hätte dort auch Zugriff auf den LocalStorage der Tool-Seite, also etwa auf deine Snippets. Führ im neuen Tab deshalb nur Code aus, dem du vertraust.

Persistenz: nichts verlieren

  • Auto-Save ist browser- und gerätegebunden. Dein Stand liegt im LocalStorage dieses Browsers. Anderer Rechner, anderer Browser, privater/Inkognito-Modus oder geleerte Browserdaten bedeuten: Der Stand ist dort nicht da bzw. weg. Verlass dich für nichts Wichtiges allein auf das automatische Speichern.
  • Für Dauerhaftes: Export HTML. Was du behalten willst, exportierst du als eigenständige .html-Datei — die liegt dann außerhalb des Browsers und lässt sich per Import HTML zurückholen (siehe Beispiel 6).
  • Snippets sind begrenzt und lokal. Maximal acht benannte Snippets, ebenfalls nur im LocalStorage. Ein gleicher Name überschreibt ohne weitere Nachfrage — vergib also eindeutige Namen, wenn du Varianten nebeneinander halten willst.
  • Load und Del fragen nicht nach. Load ersetzt deinen aktuellen Arbeitsstand sofort, Del löscht ein Snippet sofort. Willst du den aktuellen Stand behalten, speicher ihn vor dem Laden selbst als Snippet.
  • SCSS-Quelltext gehört ins Snippet, nicht in den Export. Export HTML schreibt das kompilierte CSS in die Datei; deinen SCSS-Code und den SCSS-Modus enthält sie nicht. Ein Snippet speichert dagegen den Quelltext samt Modus, und der Download im CSS-Panel liefert ihn als playground.scss.
  • Reset löscht keine Snippets. Der Reset-Button räumt nur den aktuellen Arbeitsstand auf und lädt das Demo-Beispiel; gespeicherte Snippets bleiben. Umgekehrt heißt das: Ein versehentlicher Reset ist kein Drama, solange du Wichtiges vorher als Snippet oder Datei gesichert hast.

Typische Stolperfallen

  • Das HTML-Panel ist nur der Body. Schreib hier keinen <!DOCTYPE>, kein <html> und kein <head> — das Gerüst setzt der Playground. Was du brauchst (Meta-Tags, eigene Inline-<style>- und -<script>-Blöcke), kannst du trotzdem einsetzen; es landet im generierten Dokument. Skripte und Stylesheets von fremden Servern blockiert dagegen die Content Security Policy (siehe oben).
  • Inline-Handler brauchen Funktionsdeklarationen. Der Playground steckt dein JS in einen try { … }-Block am Ende des <body>. Eine function meineFn() {}-Deklaration wird trotzdem global und ist für onclick="meineFn()" aus dem HTML erreichbar. Definierst du dieselbe Logik dagegen als const meineFn = () => …, gilt sie nur innerhalb dieses Blocks — der Inline-Handler findet sie nicht. Für Inline-Handler also Funktionsdeklarationen verwenden (oder Events im JS per addEventListener binden).
  • Kein import im JS-Panel. Aus demselben Grund sind import, export und await auf oberster Ebene im JS-Panel Syntaxfehler. Für Modul-Code schreibst du ein eigenes <script type="module"> ins HTML-Panel — Importe von fremden Servern blockiert allerdings auch dort die Content Security Policy.
  • Nicht jeder Fehler trägt das Präfix. [Playground JS] steht nur vor Fehlern, die beim ersten Durchlauf deines Skripts passieren. Fehler in Klick-Handlern oder Timern und Syntaxfehler landen als gewöhnliche Meldungen in der Konsole — such also nicht nur nach dem Präfix.
  • Bootstrap-Komponenten brauchen Bootstrap JS. Reines Bootstrap CSS macht Layout und Optik, aber Modals, Dropdowns oder Tooltips bleiben tot. Aktiviere im Assets-Dropdown zusätzlich Bootstrap JS (enthält Popper). Dark Mode wiederum lässt sich nur einschalten, wenn Bootstrap CSS aktiv ist.
  • Schließende Tags im Code sind sicher. Schreibst du im JS einen String mit </script> oder im CSS ein </style>, maskiert der Playground das beim Bauen der Vorschau — dein Code bricht das generierte Dokument also nicht auf. Beim Export bleibt diese Maskierung im Sinne eines lauffähigen Dokuments erhalten und wird beim Import wieder zurückgedreht.
  • SCSS-Compiler lädt erst beim ersten Mal. Der allererste SCSS-Lauf zeigt kurz „Loading SCSS compiler…", weil Dart Sass nachgeladen wird. Danach ist es da. Ein SCSS-Syntaxfehler bricht nichts ab, sondern landet als Fehlermeldung (mit Zeilennummer) und als CSS-Kommentar in der Vorschau.

SCSS mit Dart Sass

  • Modernes Sass schreiben. Der Playground kompiliert mit Dart Sass. Statt der alten globalen Funktionen nutzt du die eingebauten Module: @use 'sass:math'; für math.div() statt / als Division, @use 'sass:color'; für color.adjust() oder color.scale(). Die @use-Zeilen gehören an den Anfang des Panels, vor alle anderen Regeln.
  • Warnungen siehst du hier nicht. Damit beim Tippen nicht jede Fassung Deprecation-Warnungen ausspuckt, läuft Dart Sass im Playground stumm — auch @warn und @debug bleiben ohne Ausgabe. Willst du wissen, ob dein Code veraltete Syntax nutzt, kopier ihn in den Compiler; der zeigt Warnungen und @debug-Ausgaben an.
  • Alles in ein Panel. Eigene Partials per @use 'datei' oder @import gibt es nicht — es fehlt ein Dateisystem. Variablen, Mixins und Funktionen, die du sonst auslagerst, schreibst du einfach oben ins SCSS-Panel.
  • Farben sehen im Ergebnis anders aus als erwartet. Berechnete Farben gibt Dart Sass teils als rgb() mit Prozentwerten aus statt als Hex-Wert. Das ist gültiges CSS und kein Fehler.

Den PHP-Modus im Griff behalten

  • Keine Live-Vorschau — und das ist gut so. Im PHP-Modus läuft PHP per WebAssembly auf dem Haupt-Thread. Eine Endlosschleife ließe sich nicht von außen abbrechen und würde den Tab einfrieren. Deshalb gibt es bewusst kein Auto-Run beim Tippen: Du baust immer kontrolliert per Run PHP (Strg/Cmd+Enter). Bei verdächtiger Schleifen-Logik also erst fertig schreiben, dann ausführen.
  • Auch ohne Run PHP kann Code laufen. Das Einschalten des PHP-Modus, ein Reload mit aktivem PHP-Modus, das Laden eines PHP-Snippets, der Import einer PHP-Datei, jede Änderung im Assets-Dropdown und der SCSS-Schalter führen deinen Code einmal aus. Hast du gerade eine riskante Schleife im Panel, lass diese Schalter in Ruhe, bis sie entschärft ist.
  • Jeder Lauf beginnt bei null. Vor jeder Ausführung setzt der Playground Interpreter und virtuelles Dateisystem zurück. Was ein Lauf per file_put_contents() schreibt oder in Variablen hält, ist beim nächsten Lauf weg — das macht Ergebnisse reproduzierbar.
  • Fehler stehen im PHP Log, nicht in der Ausgabe. PHP ist so eingestellt, dass Warnungen, Notices und Fehler nicht die Vorschau verschmutzen, sondern im PHP Log landen (mit Zeilennummer). Bleibt die Vorschau leer oder zeigt nicht das Erwartete, ist das Log die erste Anlaufstelle — der rote Badge am Button verrät schon, ob etwas anliegt. Auch dein eigenes error_log(...) landet dort.
  • Der erste Start dauert. Beim Aktivieren werden rund 13 MB PHP-Engine geladen — einmalig und nur online. Danach liegt sie im Browser-Cache. Schaltest du PHP wieder aus, gibt der Playground den Speicher frei.
  • PHP-Export ist nicht standalone. Ein Export HTML im PHP-Modus enthält den rohen HTML+PHP-Quelltext (playground.php.html) — re-importierbar, aber im Browser allein nicht lauffähig, weil das PHP unausgeführt ist. Für ein fertig laufendes Dokument erst per Run PHP rendern: Die Ansicht HTML Source zeigt dann das komplette gerenderte Dokument zum Kopieren, und Open preview in new tab öffnet im PHP-Modus genau diese zuletzt gerenderte Ausgabe. Oder du schaltest den Modus für reines Front-End wieder aus.
  • Kein Server, keine Datenbank. Der Modus führt PHP-Logik aus, aber ohne Webserver, DB oder Dateisystem deines Rechners. Ideal für Snippets, Funktionen und Sprach-Features — kein Ersatz für eine echte PHP-Umgebung.

Mit anderen JPKCom-Tools kombinieren

Der Playground ist zum Ausprobieren da — für das Drumherum gibt es spezialisiertere Tools:

  • Compiler — wenn aus dem Schnipsel Produktionscode wird: SCSS mit demselben Dart Sass endgültig zu CSS kompilieren (dort mit sichtbaren Warnungen) und HTML/JS/CSS minifizieren oder beautifyen. Sinnvoll, sobald du den Playground-Stand ausliefern willst.
  • Beautify — fremden, minifizierten oder verschachtelten Code erst sauber formatieren (und deobfuskieren), bevor du ihn zum Verstehen in den Playground kippst.
  • Source Viewer — wenn du Code nur lesen und hervorheben willst, statt ihn auszuführen — für über 100 Sprachen.

Noch mehr Kontext: die Übersicht zum großen Bild, das Manual für jede Funktion und die Beispiele für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im Tool.