JPKCom DB

Compiler — Tipps & Tricks

Kniffe für den Compiler: Output Style und Syntax klug wählen, modernes Sass mit @debug, vorsichtige Minifier, Abgrenzung zum Beautify-Tool.

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

Das Manual erklärt jede Funktion, die Beispiele zeigen die Abläufe. Hier geht es um das, was beides voraussetzt: wann welcher Modus der richtige ist, wo die Eigenheiten der Engines liegen und welche Aufgabe besser ein anderes Tool übernimmt.

Den richtigen Modus wählen

  • Minifiziertes CSS aus SCSS? Nimm Compressed, nicht den Umweg. Wenn dein CSS ohnehin aus SCSS entsteht, erzeug die komprimierte Form direkt im SASS/SCSS-Tab über den Output Style Compressed. Das ist sauberer als „erst Expanded kompilieren, dann in den CSS-Tab und minifizieren", weil die Sass-Engine die Kompression selbst übernimmt, statt sie hinterher aus fertigem CSS herauszurechnen.
  • Beautify und Minify sind zwei Richtungen desselben Tabs. In HTML, JavaScript und CSS arbeitest du am selben Input wahlweise vorwärts (lesbar) oder rückwärts (kompakt). Mit Use output as input wird daraus eine Kette ohne Kopieren: beautifien, Ausgabe übernehmen, links bearbeiten, minifizieren. Jede Übernahme ist ein einzelner Undo-Schritt.
  • Auto-detect als Syntax stehen lassen. Die Erkennung unterscheidet SCSS und eingerückte Sass-Syntax an Klammern und Semikola außerhalb von Strings und Kommentaren. Legst du die Syntax fest, gilt das auch für den nächsten Besuch — und SCSS-Code scheitert dann an der ersten {, wenn noch Indented (.sass) eingestellt ist. Die Fehlermeldung weist in diesem Fall auf Auto-detect hin.
  • Für Produktions-JavaScript: Drop console mitdenken. Mangle names ist standardmäßig an und verkleinert zuverlässig. Drop console ist standardmäßig aus — für echten Produktionscode willst du es meist anhaken, um Debug-Ausgaben zu tilgen.

Die Engines und ihre Eigenheiten

  • Sass läuft auf Dart Sass — schreib modernes Sass. Dart Sass (öffnet in neuem Tab) (englisch) versteht das Modulsystem mit @use, sass:math und sass:color. Nutz math.div() und color.adjust() wie im Beispiel-Snippet; meldet Dart Sass bei älterem Code Hinweise mit dem Präfix Deprecation:, zeigt dir die Meldungsliste unter den Editoren samt Zeilennummer, wo du ansetzen kannst.
  • @debug statt Raten. Zwischenwerte von Variablen oder Funktionen gibst du mit @debug aus — sie erscheinen in der Meldungsliste, nicht im CSS. So prüfst du eine Berechnung, ohne die Ausgabe zu verschmutzen.
  • Kein Dateisystem, kein @use oder @import eigener Dateien. Die Engine läuft im Browser ohne Dateizugriff. Eigene Partials kann sie nicht auflösen; der gesamte SCSS-Code muss im Input-Editor stehen. Die eingebauten sass:-Module sind davon nicht betroffen.
  • Die Sass-Engine lädt erst beim ersten Compile. Rund 0,9 MB (gzip-komprimiert) werden einmalig nachgezogen — der erste Compile-Klick dauert daher etwas länger als die folgenden. Das ist gewollt (die Seite lädt ohne dieses Modul schneller), kein Hänger.
  • HTML- und CSS-Minify sind bewusst vorsichtig. Sie entfernen nur Leerraum und Kommentare, wo das an der Darstellung nichts ändert, und lassen Strings (bis auf die Zeichenfolge ;}, siehe Manual), <pre>, <textarea> und <script> unangetastet. Werte kürzen oder Regeln zusammenfassen tun sie nicht. Das JS-Minify ist dagegen mit Terser (öffnet in neuem Tab) (englisch) ein echter, AST-basierter Minifier, der auch Code umschreibt.

Stolperfallen aus der Praxis

  • white-space: pre per CSS kennt das HTML-Minify nicht. <pre>, <textarea> und <script> bleiben beim Minify Zeichen für Zeichen erhalten. Ein normales Element, dem erst dein Stylesheet white-space: pre gibt, sieht die Routine dagegen nicht — dessen Leerraum wird wie überall auf ein Leerzeichen zusammengefasst. Setz solche Inhalte in <pre> oder prüf das Ergebnis. (Beim Beautify sind <code> und <pre> ausgenommen — dort bleibt der Inhalt unangetastet.)
  • Lizenzkommentare mit /*! schreiben. CSS-Kommentare der Form /*! … */ überstehen das CSS-Minify immer, auch bei gesetztem Remove comments (minify) — und ebenso in <style>-Blöcken beim HTML-Minify. Willst du alle Kommentare behalten, nimm im CSS-Tab den Haken bei Remove comments (minify) heraus.
  • <style>-Kommentare beim HTML-Minify. Eingebettete <style>-Blöcke laufen beim HTML-Minify durch den CSS-Minifier und verlieren dabei ihre normalen Kommentare — unabhängig davon, ob Remove comments im HTML-Tab gesetzt ist. Brauchst du einen Kommentar dort, schreib ihn als /*! … */.
  • Mangle names benennt nur lokale Namen um. Globale APIs und Exporte bleiben unverändert — du musst also nichts „retten", aber wundere dich nicht, wenn nicht jeder Name kurz wird.
  • Output ist schreibgeschützt. Den rechten Editor kannst du nicht bearbeiten — er zeigt nur das Ergebnis. Zum Weiterarbeiten Use output as input, Copy oder Download nutzen.
  • Download-Namen planen. Lädst du deine Datei per Upload file statt per Einfügen, übernimmt der Download ihren Namen (theme.scss → theme.css, nach Minify theme.min.css). Den Namen vergisst das Tool beim Neuladen der Seite; danach heißt der Download wieder styles, index oder script.
  • Persistenz ist pro Browser, nicht pro Gerät. Eingaben und Optionen werden im LocalStorage gesichert (praktisch über Reloads hinweg), liegen aber nur in diesem Browser. Clear löscht den gespeicherten Stand eines Tabs bewusst mit und fragt bei eigenem Code vorher nach; ein versehentliches Clear machst du mit Strg+Z im Eingabe-Editor rückgängig, solange die Seite offen ist.

Abgrenzung: wann lieber das Beautify-Tool?

Der Compiler beautifiet HTML, JavaScript und CSS mit derselben Bibliothek wie das eigenständige Beautify-Tool — die reine Einrück-Funktion ist also vergleichbar. Greif zum Beautify-Tool, wenn du P.A.C.K.E.R.-gepackten oder URL-encodierten JavaScript-Code entpacken willst oder feinere Formatier-Kontrolle brauchst — die Hinweistexte in den Tabs HTML, JavaScript und CSS verlinken direkt dorthin. Bleib beim Compiler, wenn das Beautify nur ein Schritt neben Compile und Minify ist — dann hast du alles in einer Oberfläche.

Mit anderen JPKCom-Tools kombinieren

  • Playground — kompiliertes CSS direkt im Zusammenspiel mit HTML und JavaScript testen, mit Live-Vorschau und derselben Dart-Sass-Engine. Guter nächster Schritt nach einem SASS/SCSS-Compile.
  • Source Viewer — längeren Quellcode (über 100 Sprachen) hervorgehoben ansehen, wenn du Ergebnis und Original nebeneinander vergleichen willst.
  • Farben-Tools — Farbwerte und -formate erzeugen, die du als Variablen in dein SCSS oder direkt ins CSS übernimmst.
  • Schriften-Tools — Typografie-Werte ermitteln, die du dann in dein Stylesheet einpflegst.

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