Anzeige
Anzeige
Ratgeber

Warum JSON und YAML keine guten Konfigurationssprachen sind

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.

Von Andreas Domin
5 Min.
Artikel merken
Anzeige
Anzeige

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

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

Anzeige
Anzeige

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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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?

Anzeige
Anzeige

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.

Das sind JSON- und YAML-Alternativen

HCL – Hashicorp Configuration Language

HCL scheint eine Mischung aus JSON und YAML zu sein. Die wichtigsten Features sind so verpackt, dass sie für den Menschen weiterhin gut lesbar und verständlich sind. Wohl einer der Gründe, warum auch die neuen GitHub Actions die Sprache zur Konfiguration benutzen. Es werden Kommentare, mehrzeilige Strings und verschiedene Zahlenformate wie Hexadezimal und Oktal unterstützt. Auch verringert HCL durch schlauere Syntax die Tiefe bei verschachtelten Objekten im Vergleich zu JSON.

Anzeige
Anzeige
number = 10
hexa = 0xFF
octal = 0123

// Das ist ein Kommentar
workflow "IDENTIFIER" {
  on = "EVENT"
  resolves = "ACTION2"
}
# Auch das ist ein Kommentar
action "EXAMPLE1" {
  uses = "docker://image1"
}
/*
Ein mehrzeiliger
Kommentar
*/
action "EXAMPLE2" {
  needs = "ACTION1"
  uses = "docker://image2"
}

HJSON und JSON5 – wie JSON, aber mit mehr Features

Passend dazu: So optimiert ihr mit HJSON euren JSON-Syntax

Wer mit der Grundstruktur von JSON zufrieden ist und lediglich mehr Features benötigt, sollte sich HJSON oder auch JSON5 anschauen. So könnt ihr nun Kommentare und mehrzeilige Strings nutzen. Anführungszeichen können bei Schlüsseln und Strings weggelassen werden – genauso wie Kommata zwischen Schlüssel-Wert-Paaren. Außerdem findet ihr im Internet einige Tools, die euch das jeweilige Format wieder zu einer JSON-Datei konvertieren können, falls ihr das benötigt.

Ein Beispiel in HJSON:

{
  // use #, // or /**/ comments,
  // omit quotes for keys
  key: 1
  // omit quotes for strings
  contains: everything on this line
  // omit commas at the end of a line
  cool: {
    foo: 1
    bar: 2
  }
  // allow trailing commas
  list: [
    1,
    2,
  ]
  // and use multiline strings
  realist:
    '''
    My half empty glass,
    I will fill your empty half.
    Now you are half full.
    '''
}

Weitere Alternativen zusammengefasst

Welche Konfigurationssprache ihr am Ende nutzen solltet, hängt stark von eurer Situation ab. Da es viele weitere Alternativen gibt und hier nicht genug Platz für eine ausführliche Vorstellung ist, findet ihr im Folgenden weitere Beispiele als kurze Liste:

Anzeige
Anzeige
  • TOML: Ähnlich zum INI-Format. Hat jedoch auch eine Syntax für verschachtelte Objekte. Habt ihr jedoch eine große Struktur mit vielen Ebenen, ist TOML nicht die beste Wahl.
  • HOCON: Verbreitet bei Scala-Projekten. Hat ebenfalls alle wichtigen Features an Bord und ist eine Obermenge von JSON, wodurch JSON-Dateien direkt verwendet werden können.
  • Protocol Buffers: Entwickelt von Google und wird mit den Wörtern „XML, aber kleiner, schneller und einfacher“ beschrieben.
  • AXON: Kombiniert die Einfachheit von JSON, Erweiterbarkeit von XML und Lesbarkeit von YAML.

Und noch viele viele weitere. Nutzt du eine ganz andere Konfigurationssprache? Dann schreib sie in die Kommentare und erkläre, warum du dich für sie entschieden hast.

Wer Programmieren lernen will, muss Informatik studieren. Ein Irrglaube, der immer noch weit verbreitet ist. Warum das eben genau nicht der Fall. Lies dazu: Warum ihr zum Programmieren lernen nicht studieren müsst.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Kommentare (7)

Community-Richtlinien

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.

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.

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

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“

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

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!

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

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

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

Kommentar abgeben

Melde dich an, um Kommentare schreiben und mit anderen Leser:innen und unseren Autor:innen diskutieren zu können.

Anmelden und kommentieren

Du hast noch keinen t3n-Account? Hier registrieren

Anzeige
Anzeige