Ratgeber

Warum JSON und YAML keine guten Konfigurationssprachen sind

Warum JSON und YAML keine guten Konfigurationssprachen sind. (Bild: Shutterstock/Dominik Bruhn)

JSON zur Datenübertragung? Meistens eine gute Idee. JSON als Konfigurationssprache? In vielen Fällen ungeeignet! Auch YAML ist nicht das beste Format dafür. Diese Alternativen gibt es außerdem.

Datenübertragung, -speicherung und Konfiguration. Das sind die häufigsten Einsatzzwecke von JSON und YAML. Ja, es gibt gute Gründe, warum beide Sprachen derart weitverbreitet sind. Vor allem JSON ist nicht nur sehr flexibel und vielseitig einsetzbar, sondern wird von den meisten Programmiersprachen und Tools teilweise sogar nativ unterstützt. Auch kommen viele Entwickler bereits sehr früh mit JSON in Kontakt und wissen dann bereits, wie damit umzugehen ist. Dennoch sollte JSON hauptsächlich zur Datenübertragung verwendet werden. Doch auch YAML ist nicht die beste Alternative wenn es um Konfigurationssprachen geht.

Warum JSON als Konfigurationssprache nicht immer geeignet ist

JSON wurde hauptsächlich für die Datenübertragung entwickelt. Das Format ist für die Maschine leicht zu interpretieren und auch der Mensch kann die Datei gut lesen. Als Konfigurationssprache fällt JSON jedoch für viele Projekte aus mehreren Gründen durch. Für diesen Einsatzzweck wurde das Format auch nicht geschaffen. Dennoch kommt es dafür immer häufiger zum Einsatz. Die Gründe dafür stehen im ersten Absatz: Die native Unterstützung bei vielen Programmiersprachen und die weite Verbreitung von JSON sorgen für eine schnelle und einfache Implementierung. Das sind durchaus berechtigte Argumente und deswegen macht JSON als Konfigurationssprache für einige Entwickler und Projekte Sinn.

Jedoch gibt es auch Gründe, warum JSON als Konfigurationssprache weniger gut geeignet ist und das sollte Entwicklern bewusst sein, wenn sie sich für JSON entscheiden. Eins der größeren Probleme bei JSON ist eine fehlende Kommentar-Funktion. Bei Konfigurationssprachen sind Kommentare ein wichtiger Bestandteil, um gewisse Teile der Konfiguration näher zu erläutern oder eine gewählte Einstellung zu begründen. Es gibt zwar durchaus einige Workarounds oder Libraries für Kommentare, jedoch existiert keine native Lösung, weswegen derartige Alternativen schnell an anderer Stelle Probleme auslösen könnten.

Weitere Gründe gegen JSON stecken im Detail. Ja, JSON ist zwar relativ gut lesbar, aber auch nicht so gut, dass man das Format für Konfigurationszwecke nutzen sollte. So müssen Schlüssel immer in Anführungszeichen gesetzt werden. Außerdem helfen die geschweiften Klammern, die das gesamte Dokument einschließen, JavaScript die Datei einzulesen. Das sorgt jedoch für ein Klammer-Wirrwarr und ist für den Entwickler eher nervig. Ähnlich bei den durch Kommata abgetrennten Schlüssel-Wert-Paaren. Dort wäre ein einfacher Zeilenumbruch ausreichend. Eine JSON-Datei in einer Zeile zu lesen oder gar zu konfigurieren, ist sowieso alles andere als eine gute Idee. Apropos eine Zeile: Mit langen Strings hat JSON ebenfalls so seine Probleme. Wollt ihr in einem langen Text Zeilenumbrüche einbauen, muss explizit „\n“ eingesetzt werden.

Deswegen ist YAML eine bessere, aber nicht die beste Alternative

Einige Entwickler setzen stattdessen auf YAML als Konfigurationssprache. Die Sprache merzt einige der JSON-Probleme aus. So unterstützt das Format nicht nur komplett leere und mehrzeilige Strings, sondern auch Kommentare sowie weitere Variablentypen. Auch kann auf vorherige Werte in der YAML-Datei verwiesen werden. Klingt alles super, doch ein Aspekt kann schnell zu Problemen führen: Es wird jeweils mit Leerzeichen statt einem Tab eingerückt und die sind an entsprechenden Stellen auch verpflichtend. Passt ihr die Konfigurationsdatei nun per Hand an, kann euch das schnell zur Weißglut bringen. Vor allem bei größeren Konfigurationen, die in viele Ebenen unterteilt sind und mehrere 100 Zeilen lang sind. Denn wenn du ein Leerzeichen vergisst oder zu viel eingebaut hast, macht das die komplette Datei unlesbar. Solche Fehler sind zudem nicht leicht zu finden. Entsprechende Entwicklungsumgebungen können dabei jedoch eine große Hilfe sein, wenn sie bei der Verwendung der Tab-Taste Leerzeichen einfügen.

Außerdem ist die Spezifikation von YAML sehr komplex. Sie umfasst über 80 Seiten. Zum Vergleich: Bei JSON sind es, wenn man leere Seiten außen vor lässt, nicht mehr als zehn Seiten. Für mehr Features wird auch eine längere Spezifikation benötigt. Ist sie jedoch acht Mal so lang, spricht das eher für eine zu hohe Komplexität der Sprache. So gibt es beispielsweise ganze neun verschiedene Möglichkeiten, einen mehrzeiligen String zu verfassen. Und jede der Möglichkeiten hat eine minimal andere Funktion. Wer soll sich das alles vollständig merken können?

Kurz zusammengefasst

Das sind die Probleme mit JSON:

  • Zur Datenübertragung ist JSON ein solides Format
  • Als Konfigurationssprache ist von JSON in vielen Fällen abzuraten: nicht so gut lesbar, fehlende Features wie mehrzeilige Strings, Anführungszeichen bei Schlüsseln und Kommata nach jedem Schlüssel-Wert-Paar.

YAML kann eine bessere Alternative sein, hat jedoch auch ein paar Tücken:

  • Hat viele Features die JSON fehlen: Kommentare, mehrzeilige oder leere Strings, viele Variablentypen.
  • Hauptproblem: Einrückung per Leerzeichen statt Tab. Vor allem bei langen Konfigurationen ein Problem.
  • Sehr Komplex: Konfiguration umfasst acht Mal mehr Seiten als die von JSON.
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

7 Kommentare
M.S.
M.S.

Die Überschrift „Warum JSON und YAML keine guten Konfigurationssprachen sind“ alleine beinhaltet schon ein Wertung und stellt JSON, YAML grundsätzlich als schlechte Wahl dar. Der Artikel ist entsprechend weiter so formuliert.

Wenn jemand JSON oder YAML für sich als Konfigurationsformat gefunden hat ist dieses in meinen Augen nicht grundsätzlich schlecht. Zudem ist der auch benannte Vorteil – Unterstützung in diversen Sprachen – nicht zu unterschätzen.

Der Aufbau von JSON kann auch verständlich lesbar erfolgen, hierzu müssen z.B. die Keys sprechend formuliert werden.

Am Ende muss jeder für sich entscheiden welches Konfigurationsformat für Ihn in Frage kommt.

Ich hatte mir von dem Artikel mehr Sachlichkeit und eine bessere Gegenüberstellung der Alternativen erhofft. So aber bleibt bei mir der Eindruck das dieser Artikel nur einer Meinungäußerung dient.

Antworten
Jarek Sarbiewski
Jarek Sarbiewski

Den Eindruck hatte ich auch.

Ich persoenlich nutze XML fuer eigene Datenformate und als Konfigurationssprache. Falls es auf die Datenmenge ankommt, nutze ich stattdessen JSON. Mit beiden hatte ich nie Probleme. Naturlich benoetigt man evtl. die anderen Features falls die Konfigurationsdaten sehr gross werden um den Ueberblick nicht zu verlieren. Trotzdem wurden in diesem Artikel JSON und YAML als Konfigurationssprache pauschal fuer ungeeignet deklariert.

Antworten
Andreas Domin

Hallo M.S.,

die Überschrift für sich stellt noch keine Wertung dar. Die Gründe dafür stehen im Artikel. Jedoch muss ich dir in den weiteren Punkten recht geben, weswegen die Argumentation im Artikel durchaus fehlende sachliche Aspekte hatte. Ich habe mir den Artikel noch einmal genauer vorgenommen und entsprechend überarbeitet.

Viele Grüße aus Hannover
Andreas

Antworten
Robert W.
Robert W.

und wo sind jetzt die Argumente gegen JSON und YML?

so im Produktiveinsatz hab ich die genannten Probleme nicht gehabt. Eine Konfiguration mit mehrzeiligen Strings ist schlecht aufgebaut bzw. der Autor sollte überlegen, ob es Sinn macht Zeilenumbrüche in eine Konfiguration zu schreiben.

Kommentare können btw. auch der Ausdruck von schlecht verständlichem Code sein.

Schlussendlich ist es wie mit aller Technologie: es gibt kein richtig oder falsch, denn „it (always) depends“

Antworten
Andreas Domin

Hallo Robert,

ich habe mir den Artikel noch einmal genauer vorgenommen und überarbeitet. Die Argumente gegen JSON und YAML stehen im Text.

Kommentare sind aber meiner Meinung nach auf keinen Fall ein Ausdruck von schlecht verständlichem Code. Im Gegenteil. Fehlende Kommentare sind ein Ausdruck davon. Warum hat beispielsweise ein Entwickler-Kollege in einer Konfiguration eine gewisse Einstellung getroffen? Solche Dinge können Monate oder gar Jahre nach der Bearbeitung nicht immer nachvollzogen werden. Kommentare sind ein extrem wichtiger Bestandteil eines guten Codes – auch bei den allermeisten Konfigurationen.

Deinem letzten Satz muss ich jedoch zustimmen. Ich habe den Artikel dahingehend auch angepasst.

Viele Grüße
Andreas

Antworten
Dominic Karasch
Dominic Karasch

Ich sehe das recht ähnlich – jeder muss das richtige Format für sich selbst finden. Ich persönlich arbeite seit knapp über 4 Jahren mit YAML als Konfigurationssprache und bin durchaus zufrieden.

Für mich liest sich der Part über YAML so, als wenn der Autor die Sprache nicht selbst probiert hat und die Dokumentation dazu auch nicht genau gelesen hat. Tabs können bei YAML genau so wie Spaces genutzt werden. Ich selbst nutze sogar 4 Spaces anstatt von 2. Als Entwickler hat man ja in der Regel auch eine IDE im Einsatz, bei der man z.B. die Nutzung der Tabs speziell für YAML auch einstellen kann und diese zu Spaces gewandelt werden.

Es fehlen hier auch einfach wichtige Punkte die für YAML widerrum sprechen würden, wie zum Beispiel die Möglichkeit der Importierung in eine andere Datei oder das überschreiben von Werten, die Nutzung einer verschlüsselten Form (eYAML), und vieles mehr.

Die Objektivität in diesem Artikel ist komplett untergegangen und wirkt eher wie ein eingesendeter Brief, einer Person die YAML und JSON einfach nicht mag bzw. bevorzugt. Ich hätte mir deutlich mehr erhofft!

Antworten
Andreas Domin

Hallo Dominic,

ich muss dir in einigen Aspekten zustimmen und ich habe den Artikel entsprechend ein wenig überarbeitet.

Und ich habe bereits längere Zeit mit YAML gearbeitet und habe leider schlechte Erfahrung für diesen Einsatzzweck gemacht. Aber wie in anderen Kommentaren bereits stand: Es kommt auf den Einsatz und den Entwickler an. Von daher habe ich mehr Objektivität eingebracht.

Viele Grüße aus Hannover
Andreas

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.