XML is better than YAML | Prime Reacts

Recorded live on twitch, GET IN
/ theprimeagen
Reviewed article: changelog.com/posts/xml-bette...
Author: Carl Johnson | / carlmjohnson
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts

[@diadetediotedio6918]

Personally, I find that XML is like the Java of markup languages. Understand this as you wish.

[@Rohinthas]

Agreed, and in my experience the Venn Diagram of people who like Java and those who like XML is nearly a circle and they tend to be in their 40s/50s. You can tell that Java and XML were both born in the mid to late 90s. No diss, different ways of thinking and working, just not my cup of tea.

[@zxcaaq]

what did you just call me?!

[@adambickford8720]

@@Rohinthas I feel personally attacked. Real talk: i was complaining about it back then: "we code in xml, bootstrapped in java, and its terrbile". Literally had a project that required writing java swing... in xml. Then at runtime having to xslt it into actual java, to be compiled and dynamically loaded at runtime. It was silly then and just plain offensive now.

[@ScrotoTBaggins]

​@@adambickford8720only the real OGs survived xslt

[@TheSulross]

both xml and yaml need to be taken out back like Old Yellow and put down - a person can only endure so much foaming-at-the-mouth technology stacks

[@tokiomutex4148]

We should actually use JDSL because Tom is a genius

[@renatocron]

a version control!

[@mikhailryzhov9419]

He also invented TOML

[@ravenecho2410]

jay Diesel, love it

[@asdkant]

I used one of those advanced YAML features *today* for a docker-compose file Also, my data interchange formats of choice are markdown and GIF

[@Exilum]

Of course, as any dev, the solution to hating json, yaml, xml and all the others must be to create your own that transpiles to json. You MUST spend 10 hours to gain satisfaction and a potential 1 second a month. That's a potential 12 seconds a year!

[@jayshartzer844]

"Caddy is just JSON behind the scenes" **Tom's breathing intensifies**

[@splytrz]

Didn't know about the float version problem, good to know. I'm thinking though, if you're writing a compiler that reads the version from yaml, you should be expecting a string, right? So if yaml["Go"] returns a float instead, you should panic or something, not just treat it the same way. It even seems like the person who was writing that compiler probably had to explicitly allow this to happen, in which case I would blame that on them Also, here's one thing yaml does well: localization. It's just the cleanest possible way to represent it. And multiline strings that account for indentation are a blessing.

[@sadsongs7731]

Indeed. This is stupid. Of course 1.20 would get transformed into the number 1.2. If you are expecting a string, write a string. YAML is full of trade off but they all make sense.

[@skeleton_craftGaming]

I actually don't even mind XML when it is used as a JSON precursor. It's not the most convenient file type to work with [There is virtually no reason to use it over JSON], but it's also more convenient than other types of files

[@njayman]

There is a js framework called owl, which is specifically used in odoo, an open source erp software. It works like react but instead of writing jsx, you write xml(qweb).

[@wolfeygamedev1688]

Imo, protobuf for servers that talk to each other, JSON for public facing / webapp apis, TOML for config.

[@archmad]

we used protobuf in FE, i want to die after

[@wolfeygamedev1688]

@@archmad protobuf in frontend? yikes

[@georgehelyar]

FWIW if you use a 3 digit version number, which you usually do for semantic versioning, yaml does not start treating it like a floating point number and drop the trailing 0s.

[@samhughes1747]

3:11, skill issue? Uhm, no; that's a tooling issue! We like syntax-aware highlighting in our programming languages, so when your markup language wants to be as flexible as YAML is, treat it like a programming language, and enable a linter!

[@MrMeltdown]

TOML I used that, but in the TOML library I was using I couldn't use spaces in the keys, which always kinda bugged me, but I found it a lot quicker to write a structure than in YAML or JSON, but then again I was used to writing deeply nested hashes (dictionaries) in perl.

[@Jabberwockybird]

For config, simple dot file with key value pairs. Anything more confusing can be done in code. For sending data, json is okay bc the lack of trailing commas isn't a problem at runtime

[@umka7536]

YAMLbrings me a headache, but it is readable and it supports comments. TOML is maybe better because it is using subsections, but it is less readable. JSON is the worst for configs and manifests: no comments, hard to edit. JSON is great for APIs.

[@putnam120]

Is it really better for apis than the others? Or is it what is currently mostly used

[@ninocraft1]

JDSL is the best

[@_WindofChange]

Hi guys, I am starting to learn back end development and have no idea on where to start. I have experience with C and C++ and know nothing on what I am doing with all those pointers, calloc, malloc and what not and I want to make a switch on more usable language. So can you guys give me any idea on which language and frameworks should I consider keeping performance as a main target?

[@dpgwalter]

I am working on a terminal-based UI framework, and use XML for describing applications (much like HTML). Now trust me, I _did not_ want to use XML, but I genuinely could not find a language that better represents a UI tree. Sure, it's not the most pleasant to type, but when given the choice between 10 (semi-long) lines of XML or 40 lines of (concerningly indented, single word) YAML, I found most chose the prior. I do use YAML for styling however, as it represents hierarchy in a really readable way and allows me to insert my custom CSS-like query microlanguage into field names. I think both have valid uses, but using either for _everything_ is gonna lead to a certifiably miserable time.

[@catcatcatcatcatcatcatcatcatca]

I’d argue most config files should make an effort to use .ini instead of TOML, because it’s still more universal. By having multiple config files for exceptions (like you can map gitconfigs to read per-parent-directory git-configs), and having sensible subsections with (when necessary) verbose options, you can make your documentation and structure pedantic instead of the markup language. Assuming everything is a string works if the documentation is done properly, the options are all well thought out, and the user doesn’t try to brute-force a valid configuration or input whatever chatGPT hallucinated. Just throwing datatypes in there and a helpful middle layer of parsing adds complexity if all else is equal. Throwing this complexity in to sort out previous complexity is a good solution only if the existing complexity is already at minimum possible. Usually configs do a rather straightforward task, or a set of straightforward tasks. So most .toml files are just .ini with mandatory quotes everywhere.

[@catcatcatcatcatcatcatcatcatca]

CSV where every line has every attribute of every data structure need. Then you just set every value you didn’t use to nil, so you can use null, zero and false as a value. Reading this structure is pretty trivial, as long as you use lisp to do so.

[@IliaFeldgun]

YAML is a user interface. It's not fun to parse yaml, it's fun to write YAML. IMO no other serialization is more human writable, and this is for sys admins not for developers, just like GUI is not for developers.

[@skeleton_craftGaming]

7:31 as the C++ programmer I can't use either of those; I use mainly raw binary files. There's no real reason to have human readable serialized data IMO...

[@tychoides]

By the way, does somebody in the comments use EDN? I have always wondered about the experience with it. Some Clojure people around?

[@markuskonrad6049]

For configuration on the JVM (yes, yes, I know...), nothing beats lightbend/config (aka HOCON)

[@newtonvitas5633]

Anyone knows what font this article uses? It's really pretty

[@m4rt_]

0:10 I have no idea why he mentioned Norway, but yay, he mentioned my country! Edit: I just checked, lmfao, you can use yes/no instead of true/false, and the country code for Norway is no

[@darthcabs]

It's funny you should post this today, because just yesterday I was doing some WPF stuff and thought: Why does XAML still exist in 2023 and when are they switching it to YAML?

[@Kane0123]

Had to parse API documentation provided in YAML recently… kick me in the nuts.

[@brainsniffer]

No shit, when he mentioned the trailing commas for json, and I think about all the file merge issues I have with configs all because of the lack of a trailing comma in an array. I feel seen.

[@Oler-yx7xj]

3:43 At this exact point I googled "Norway YAML" and went "NO, NO, NO, NO", and then he goes 3:47

[@thefallenfool]

I hope some of yall had the wonderful experience of using edi.

[@RobHarrison]

Omg hell yeah😢

[@tychoides]

I use JSON and YAML as config files, because allow me to write a file representation of python dictionaries and list cleanly. I started using JSON, but I needed to edit manually a config file, and sometimes comment problematic entries. YAML end up being great for manual inputs: less typing because inference and line comments. However, I would not use for data transfer. JSON is OK if you need that dict list representation and readability. JSON is readable enough. I agree YAML is not reasonable for data transfer or transcription of the state. XML is ok, but more verbose. Like Java. But I have to use a Oracle database with XML entries. It is hell. We end up parsing all those fields into postgresql tables so we could actually use them. That is a bad use of XML. Finally TOML look ok, but making list in a readable way is not possible, so I went to YAML.

[@darthcabs]

Exactly! Python and Ruby make JSON a first class citizen

[@NatoBoram]

btw, comments are in jsonc, not json

[@elzabethtatcher9570]

Tell me if I misunderstood: That person typed string 1.20 (which is not a number) in yaml in a number format, didn't denote it as string, got mad that engine interpreted number like a number and published an article about this? Damn. Xml has types too. I'm sure you can shoot yourself in the foot in xml too, if you want.

[@alexstone691]

Im confused as well

[@jasondoe2596]

I think his problem is YAML's annoying inconsistency when it comes to quoted strings: You don't need the quotes, until you do.

[@elzabethtatcher9570]

@@jasondoe2596 I can agree, that is frustrating at times. Json's trailing commas annoy me more, tho.

[@adambickford8720]

I feel like i should have stronger opinions on this; I just try to keep that serialization stuff in some dark corner as isolated as much as possible from my precious 'real code'.

[@NickSteffen]

Am I crazy or is interpreting 1.20 as 1.2 a parser problem not a YAML problem. I could easily concoct a similar scenario in xml or json.

[@davidbriggs8109]

I use YAML for configs and JSON, XML for data exchange

[@sofocused7767]

I dont understand the Norway joke 😅

[@DrewYoungThomas]

YAML parses NO/No as false, and YES/Yes as true. The country code for Norway is NO.

[@pesterenan]

Oh Norway bruv, that's mental

[@sofocused7767]

😂

[@HrHaakon]

The Joke is that YAML is smart, so you don't have to quote your strings, unless YAML is smart and understands that of course what you REALLY MEANT was FALSE. I Hate YAML. XML users at least understand that they can be annoying, and at least I have tooling for it. ini/properties, JSON, XML and if you really want more than that, TOML are all fine in their niches. But YAML is like configuring Emacs using VIMSCRIPT. Someone clearly missed the mark somewhere... :p

[@tokiomutex4148]

​@@HrHaakonELisp >>>>> Yaml

[@LusidDreaming]

JSON when it sees a trailing comma: "there's no going back now, there better be another item or else FU!"

[@cariyaputta]

I had the same "1.20" bug on a GitHub Actions YAML. What an atrocious language. TOML is somehow even worse with its weird nesting behavior. And why does JSON not support trailing comma?

[@Fiercesoulking]

Ah yeah protobuf I needed to compile it recently because I tried compiling Pytroch

[@Guergeiro]

I would rather use Vimscript to configure my editor than JSON. Can't we make the same analogy for configuration in general?

[@homelessrobot]

Well having a preference isn't an analogy. But yes, you can apply it wherever you like. No I don't think you would have a good time replacing configuration with bespoke programming languages absolutely everywhere. Scripting is a tolerable substitute for well defined/constrained configuration, but only if a new scripting language isn't introduced for every configurable piece of software. I want there to always be fewer programming languages than programs. But this is ultimately acknowledging that 'poorly designed configuration' is often worse than 'poorly designed scripting interface'; if you have scripting you can basically get access to any data in the system that you want, and this gets easier the worse the scripting interface's design is. So you won't paint yourself into a corner with prematurely good code. You can make whatever it is work with bad scripting, not that anybody else will understand how.

[@Guergeiro]

@@homelessrobot the analogy is not Vimscript, is the fact that using config files will always be a limiting factor to any configuration since you're bound by the specification. Change Vimscript for Lua and now you don't have a "new" scripting language. Or Golang, or C, etc.

[@homelessrobot]

@@Guergeiro its a tradeoff. You are trading predictability for flexibility. Even if the count of scripting languages used is 1, thats still a space larger than the space of all non-executable configuration specifications combined. Imagine if you had a project with literally every configuration language represented in it somewhere. It would be unmaintainable. This is about on par with taking on a single addition executable specification language. Its like cubing the complexity of your project in one go. All of this wiggle room means bugs and instability.

[@FIIRdesu]

Getting surprised by things you want to be strings being interpreted as numbers is pretty much a non issue if you use an editor with syntax highlighting. Complaing that you have to quote strings is weird considering you have to quote everything in JSON, and XML is also way more noisy. I was spending some time comparing configuration languages for our web frontend when deciding what to use as a replacement for XML (hard agree that XML is not the choice for configurations). TOML (or INI) was not much of consideration, because we need a lot of nesting, which TOML doesn't handle well. The tougher choice was between sticking with XML (no refactoring work), JSON (supported natively by the TypeScript compiler) and YAML (which we ultimately chose and am still ok with after 3 years).

[@jaysistar2711]

5:00 At least with JSON, you know what needs to be fixed to make it something that you like.

[@9SMTM6]

I mean... I don't often want an extensible markup language. Markup language? Yeah, gimme, love it. Extensible? Not for the price of the plain text being unparsable for a human being, AKA the way XML does it. Someone said it when C# came up. Documentation in XML might actually be my main issue with C#. Sure, they also threw the fridge at features, so they have a lot, but I prefer that over the Java approach of adding stuff a decade or two late. But Comments in XML? Get these unreadable lists out of my face, what the fuck.

[@CobaltSpace]

I think I will just default to ini. I’ll look into more complex options ini is no longer enough.

[@maddsua]

Literally me setting up Filezilla in CLI mode. It's doing a lot of XML in nano 💀💀💀

[@Turalcar]

I had to recently refactor an EDIFACT parser so there's that

[@brainsniffer]

I’m encoding all my data as image to upload. I’m onto you, govmint, trying to take away my ssl and read my datas.

[@KvapuJanjalia]

I use PowerShell as my configuration DSL.

[@br3nto]

3:26 a version number isn’t actually a number. It’s a complex object represented as a string of numbers separated by .’s. So yes, dropping the 0 from 1.20 is fine because it is actually the same number.

[@SimonBuchanNz]

"a version number isn't a number [... so] it's fine because it is actually the same number" Uh...

[@br3nto]

The doofus making the complaint is most likely using YAML syntax that looks like this: ‘version: 1.20’. As per 2.4 of the YAML spec, this will be interpreted by the parsing language, and in most instances will be interpreted as a numeric type rather than a string. In the blog post, however, they make it look like they used the syntax ‘version: Go 1.20’. However, applications would always interpret this as a string and therefore not drop the 0. This is PEBKAC plain and simple. If the person wanted the version number to be interpreted as a string, they should have used either ‘version: !!str 1.20’ or ‘version: “1.20”’. It’s as simple as that.

[@TechnicJelle]

I've been really liking HOCON recently! :)

[@adrianspikes6454]

Never understood the hate thrown at XML. It worked create when using Adobe Lifecycle.

[@Yous0147]

Lol, that article was literally just "YAML is useless because you have to quote your strings", which I mean sure it sucks, but what does that have anything to do with it being worse or better than XML? Are you saying XML is more verbose, hence it's better? I don't get the premise of that article when you read what is actually being written

[@kuhluhOG]

3:48 Yep, not skill issue. It's just that English decided to use a period instead of a comma as decimal separator. The only countries which use a period as decimal separator are: Britain and its former colonies (minus a few), Mexico, the Dominican Republic, China, Thailand, the Philippines (tbf, it was for some time a US colony), Ethiopia, Switzerland and Croatia. Most Arabian countries use the Momayyez () as decimal separator. The rest of the world uses the comma. And I am not going to start listing all these countries because these would be too many. And then there are South Africa which uses mostly the comma except some news papers and Canada where it depends if you are using French (comma) or English (period). Fun fact: English speaking countries used the · as decimal separator until the SI came along (reasoning: a lot of countries use the · as sign for multiplication). Fun fact 2: Britain chose the period as decimal separator because the Decimal Currency Board wanted it. The British Standards Institution and the industry wanted the comma. Fun fact 3: ISO made the *comma* the standard for decimal separators for international blueprints.

[@VACatholic]

Period makes more sense. Comma makes no sense. Comma as thousands separator, period as decimal separator is just obviously better to period as thousands separator and comma as decimal separator.

[@Yotanido]

@@VACatholic Not obvious to me. As far as I can tell, they are exactly the same. How is one better than the other?

[@splytrz]

@@VACatholic they make equal sense, it's just arbitrary.

[@VACatholic]

@@Yotanido "Making more sense" doesn't mean it's "better". They're both arbitrary. However the point of a full stop is to separate two concerns. The most natural break in a number is not between 1000 and 999, but between 2 and 1/2. That is, the decimal is a "hard stop" between the integral part and the decimal part of the number, like the "hard stop" between one sentence describing the integral part, and one sentence describing the decimal part. Contrast this to the comma, where you are joining multiple parts of the same sentence together. This is what you're doing when you talking about 1,000,000 (i.e., you're joining together an integral concept as a coherent unit, which is basically what a sentence does). Hence it makes more sense to talk about the integral part as one sentence, and the decimal part as another sentence, joined together with a period as two sentences, rather than an arbitrary number of "sentences" describing the integral part, followed by a comma, and then an arbitrary number of "sentences" describing the decimal part.

[@reddixskrull2451]

You sir are a man of culture and I really liked your comment.

[@ARitzCracker]

tsx is basically just ActionScript with inline XML

[@AceofSpades5757]

Of course you need to quote it if it's a string and not a number.

[@SimonBuchanNz]

The "Norway problem" and parsing 1.20 as a float isn't actually a YAML problem, strictly: YAML defines several "schemas" (an unfortunate name, as they're not really the same as an xml or json schema) that defines how the raw scalar, seq and map values get converted to language values. YAML 1.2 defines three: failsafe, json, and core. None of these parse "no" as a boolean, and failsafe doesn't parse anything as anything: every scalar is a string. None of these really matter if you're parsing in a typed language, if it's any good at all.

[@MrDejvidkit]

Well not in HOCON you can do a = [1,] and it works ;-)

[@TagetesAlkesta]

Clearly the true solution is to roll your own cryptic, proprietary, poorly documented interchange format.

[@H4KnSL4K]

Thanks!

[@dixztube]

I missed the pun what was it

[@chikinrasshu]

I think the author was describing EPUB in the Bible example bit idk

[@M4Dbrat]

What about StrictYAML?

[@ulrich-tonmoy]

Theres ZON Zig Object Notation

[@NickSteffen]

Could go back to the dark days of configuring your server with an ini file…

[@gentlemanbirdlake]

comments in json? wha? that’s unposssible!

[@thegittubaba]

I love yaml. Those hate it, obviously skill issue :D

[@BosonCollider]

S-expressions are the one true way. 90% of the power of lisps is just to have an embedded extensible config language that is not excessively verbose

[@CottidaeSEA]

I'd much rather use XML for configs than anything else for a very simple reason. XSD files. As long as they exist and don't have strange conditional stuff, my mind will mostly stay sane. That way you can have versioning and also know exactly what you need. I don't at all like XML, but for configs? Absolutely.

[@HrHaakon]

Until he said he wrote Go, I suspected this to be written by me, and that I was a schizo. PREACH YAML-HATING BROTHER!

[@archmad]

tell that to devops

[@zeocamo]

all of the points about YAML is true for XML too, XML you need to include files, the diff. here is you don't write as much with YAML then XML, both is NOT usable at all.

[@jagagemo8141]

Work has a critical service, only uses SAML. Everything has (one and only one) SAML service just to talk to it.

[@uuu12343]

Honestly, I hated YAML initially, but after using it in docker, I feel like I might be digging in

[@uuu12343]

I hate that I just wrote that

[@yazalulloa]

The "tes this against Go 1.20" is a skill issue, a Go skill issue, the parser is wrong

[@Redlabel0]

guy knows not the quotation marks, abhors using his pinky for shift ;p

[@asandax6]

I've hated YAML ever since my first time seeing it in Flutter. I've loved TOML ever since my first time seeing it in Rust.

[@SimonBuchanNz]

Real question, why?

[@robertharris4129]

YAML is also really slow for serialization in Python. If you use YAML on Python, there's a very real chance that you are parsing data much slower than the equivalent in something like JSON. YAML is just an objectively bad format.

[@thegod3500]

Json is masterprise, we need replace html with it

[@mintx1720]

I think xml still has one niche: it is somewhat pleasing to the eye when you want to embed some other scripting language in it, unlike every other format out there. I'm still using XML as some part of my game's config files, well before the game even builds I serde it out, covert it to binary and forget about it.

[@jasondoe2596]

The article is so fucking *BASED* LOL! (I, too, hate YAML with the burning passion of a million suns.)

[@calebpena3729]

I like to send my data in CSS

[@Arnazisti]

I use yaml daily for pipelines, it genuinely upsets me. Good use case, poor tooling

[@RenderingUser]

But can we all agree, that the real hero, is TOML?

[@alexandersuvorov2002]

JSON

[@RenderingUser]

@@alexandersuvorov2002 TOML is more readable for config files tho

[@SimonBuchanNz]

TOML is absolutely awful. It's all the worst parts of JSON and INI combined.

[@samgould8567]

TOML for small, human-authored config files is pretty nice. Otherwise I hate it.

[@megaing1322]

XML and JSON are interchange languages that are both ... _usable_ as configuration languages, but have massive drawbacks. If you use them for configuration, you are just being annoying. YAML and TOML and ini and quite a few others are configuration languages. If you use them for information interchange, you are just making it harder for yourself than it needs to be. Use a proper language for that. And YAML is bad for configuration since it has too many opinions to be consistent.

[@tychoides]

I cannot make long lists within a dict in TOML. I can create a YAML and read that in python as dictionary with lists in a one to one relation. I don't know how to do it in TOML as everything needs key values pairs

[@megaing1322]

@@tychoides You cannot make that, but it's definitely possible. Check the TOML spec.

[@CottidaeSEA]

For configurations I'd honestly say XML is the best option, because XSD files exist. Validating XML becomes possible and it's also possible to use XSD in an IDE in order to create your configurations. With JSON and other formats it's really not as easy. There are ways to do it, but they don't have a dedicated way of doing it which means the end result can vary greatly in quality.

[@megaing1322]

@@CottidaeSEA Ofcourse there are dedicated ways to this for other formats, for example JSON schema. And typing an XML file from nothing like you sometimes want to do for configuration files, or have them look after by a non-programmar is annoying to terrible. Yes, IDE integration is nice... But that's not a pro for any format. All formats can have nice IDE integration.

[@CottidaeSEA]

@@megaing1322 Yeah, but it's still a format I'd much rather use. My main issue with XML comes from needing to escape characters like & which is just stupid.

[@__Curiosus]

⭐️ JSON5 ⭐️

[@rasalas91]

3:14 It's literally a string. It can't be a float. If it was a float, it would be 1.2, so yaml is correct. It's not an integer either. Why would you write a string as a float?

[@nctrn07]

AADB2C custom policies in XML give me a stroke.

[@crackerjackmack]

avro for life! Kidding. XML is super powerful only because of XSD (fuck DTD) and XPath. If people like jq or jsonquery, XPath puts those things to dust in terms of power and simplified syntax. It compresses well, but it's still text instead of binary. For complete, highly nested documents it is the most powerful -- But you'd never want to write it by hand.

[@jamesnicolas5323]

no one likes HCL? personally my favourite config language. also I feel like most people are missing the point of the article. xml and yaml are both bad for config, but at least xml is good for markup (JSX).

[@woolfel]

I've experienced that kind of Yaml BS. Sadly too many frameworks use yaml, especially cloud automation. I won't name the culprits, we all know which frameworks use yaml. the issue I have with binary formats, it's a bitch to debug. Sometimes it is nice to have human reading format. If someone third party service is sending you AVRO data and it barfs, trying to debug that is far more painful than it needs to be. Same with protobuf. If someone is using a newer schema to generate the data and your code doesn't use the same version you're F-ed. Same thing with Thrift and every other binary format. Ideally, during dev/test you can use non-binary format. When you deploy, flip a switch and have it use binary to be efficient.

[@putnam120]

Protobuff is forward and backward compatible. So one side didn't follow document practices.

[@TheyCallMeHacked]

I just send packed C structs for the data 😎

[@user-yb4hd9wg6x]

use AI! AI as API is the future. Is it slow? Yes. Is it not 100% guaranteed to be right? Yes. But it is dynamic, and I do not have to deal with it!

[@SeanCallahan52]

I fucking hate the trailing comma thing with json. The WORST.

[@thedelanyo]

The real reason it got a bad reputation, I guess is, XML have more than 101 rules. She's not liberal (or generous) enough 😅😅

[@doxologist]

I dont like YAML but god do I despise XML. Just the worst way to configure stuff. And the parsing is ridiculously expensive. The fact YAML allows comments justifies its exsistence to me.

[@rstewart2702]

“XML is better than YAML.” That is damnation by faint praise.

[@Marxone]

I refuse to use anything that assigns significance to indenting.

[@DryBones111]

This article triggers me so much. The problem with YAML comes down to shitty parsers and a skill issue. I've never hated writing YAML and JSON should never be rolled by hand.

[@GreyDeathVaccine]

php arrays :P, ini files, csv ;p

[@gotoastal]

Nickel & Dhall are the best alternatives

[@wojciechorzechowski2211]

JSON is not the only way, just the ONLY SANE way xD