JPKCom DB

Compiler — Tipps & Tricks

Kniffe für den Compiler: Output-Style klug wählen, Grenzen der regelbasierten Minifier, Abgrenzung zum Beautify-Tool und Kombination mit anderen JPKCom-Tools.

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 per Textregel zu erzwingen.
  • 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). Das macht den jeweiligen Tab zum Hin-und-Her-Werkzeug: zum Bearbeiten beautifien, zum Ausliefern minifizieren.
  • 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 LibSass, nicht auf Dart Sass. sass.js (englisch) bildet den klassischen Sass-Funktionsumfang ab: Variablen, Verschachtelung, Mixins, @import, Funktionen wie lighten(). Die modernen Modulfeatures (@use, @forward, sass:-Module) gehören nicht dazu. Schreibst du Code für dieses Tool, bleib bei klassischer @import-Syntax — sonst kompiliert er nicht.
  • Kein Dateisystem, kein @import von Dateien. Die Engine läuft im Browser ohne Dateizugriff. Externe Partials kann sie nicht auflösen; der gesamte SCSS-Code muss im Input-Editor stehen.
  • Die SASS-Engine lädt erst beim ersten Compile. Rund 4 MB werden einmalig nachgezogen — der erste Compile-Klick dauert daher spürbar länger als die folgenden. Das ist gewollt (die Seite lädt ohne dieses Modul schneller), kein Hänger.
  • HTML- und CSS-Minify sind regelbasiert, kein Parser. Sie arbeiten über Textregeln, nicht über einen vollständigen Syntaxbaum. Für normalen Code reicht das; bei Spezialfällen kann es danebengreifen (siehe Stolperfallen). Das JS-Minify ist dagegen mit Terser (englisch) ein echter, AST-basierter Minifier — entsprechend robust.

Stolperfallen aus der Praxis

  • Whitespace-empfindliches HTML beim Minify. <pre>, <textarea> oder Elemente mit white-space: pre können durch das regelbasierte HTML-Minify Leerraum verlieren. Prüf das Ergebnis, wenn solche Bereiche vorkommen, oder minifiziere nur die unkritischen Teile. (Beim Beautify sind <code> und <pre> ausgenommen — dort bleibt der Inhalt unangetastet.)
  • CSS-Minify entfernt Kommentare immer. Anders als beim HTML-Tab gibt es im CSS-Tab keine Option, Kommentare zu erhalten — auch ein Lizenz-Header /*! … */ fliegt raus. Brauchst du ihn, füg ihn nach dem Minify wieder an.
  • Exotisches CSS kann das regelbasierte Minify verwirren. Komplexe calc()-Ausdrücke mit bedeutungstragenden Leerzeichen oder Inhalte in content: "…" sind Kandidaten für ungewollte Veränderungen. Im Zweifel das Ergebnis gegenprüfen — oder den Weg über SCSS Compressed gehen, der einen echten Parser nutzt.
  • 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 Copy oder Download nutzen, oder die Ausgabe als neuen Input einfügen.
  • Persistenz ist pro Browser, nicht pro Gerät. Eingaben werden im LocalStorage gesichert (praktisch über Reloads hinweg), liegen aber nur in diesem Browser. Clear löscht den gespeicherten Stand eines Tabs bewusst mit.

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 Code deobfuskieren willst (zusammengezogenen, absichtlich unleserlich gemachten Code entwirren) oder feinere Formatier-Kontrolle brauchst. 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. 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.