Hacker News Reader

Comment by hyperman1 | Hacker News Reader

Interesting to see the history here: XML was created and solved a lot of problems. So on the bandwagon everybody jumps. Then it became bloated and fragmented, so the world switches mostly to JSON.

But on the XML side, the baby was thrown out with the bath water, while JSON started developing its own abuses. TOML and YAML come in and muddy the waters a bit more.

This is only 1 article, but maybe the world is ready to discuss the possibility that the pendulum swung too far?

View on HN

The moment we added JSON schema (not to mention JSON transforms) and started to create a JSON version of XPath, we started down the same path that hurt XML.

Throw in parsers that all act differently (some parse comments, some don’t), and processing directives, and it becomes clear that yes, the pendulum has swung too far.

> The moment we added JSON schema

There is an amazing JSON schema syntax out there, 100% better than the official one. It is called TypeScript, and I am sad that the TS compiler can't be made to pop out JSON validators (their philosophy being nothing at all runtime).

There is a project (I forget its name) that will insert itself into your build steps and use TS type definitions to validate JSON.

Seriously the TS syntax is great, why is anything else being used to write a schema?

The only thing I'd add to the TS syntax is the proposals to add field validation using regexs, or some type of field name validation format. There are times when TS can't model my JS objects, e.g. I have a bunch of GUID field names that map to objects of a certain type, and I have some other field names that are 100% not GUIDs, I promise, mapping to some other stuff.

Imagine you're Amazon and you receive data from vendors. It's not enough to authenticate the sender, you still need to check that the payload is at least syntactically valid before starting to process it. You can write custom code, of course, but after writing lots of it you're likely to start naturally splitting it into a declarative part and a universal processor that checks incoming data against the declaration. It's harder to come up with a declarative way from the start, but it's a natural tendency, because declarative form is much simpler than procedural: declarations are data, and data are easier to understand than a process.

This is what schema, transforms, and paths are: they're a declarative way to address these tasks in XML. It's natural there will be attempts to reinvent them for JSON.

I’ve been around long enough to use them all. I’m pretty happy with JSON as a debuggable serialization format for machine-to-machine or light machine-to-human use cases. YAML works well for human-to-machine (JSON could fill this use case as well if it would support comments and multi line strings). I don’t use TOML much, and good riddance to XML.

TOML is simply the old INI format except with a single concrete specification instead of many adhoc ones. YAML is the "kitchen sink included" of serialization formats, so much so that most only use a small subset of its features. In that case I think TOML is usually the better choice unless you really do need some of the power and complexity offered by YAML.

I agree that less power is better, but I find TOML pretty cryptic. Like I said, JSON with comments and multi line strings is my ideal. :)

What do you feel is cryptic about TOML? I always felt it was pretty straightforward, especially if you're coming from INI (you could feed INI files into a TOML parser and most of the time end up with something somewhat sane, especially if you're using octothorpes instead of semicolons as comments).

That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. It's one of the things I really like with OpenBSD's various subprojects like PF¹ and OpenSMTPD² and relayd/httpd³, and I'm semi-actively working on a way to do similar things in Erlang/OTP applications⁴. The only alternative that matches that level of expressiveness (besides just doing all configuration directly in the host language) is s-expressions.

¹: https://man.openbsd.org/pf.conf

²: https://man.openbsd.org/smtpd.conf

³: https://man.openbsd.org/relayd.conf.5 / https://man.openbsd.org/httpd.conf.5

⁴: https://otpcl.github.io

I'm not coming from INI files. :) I actually always felt they did a poor job of representing anything more than key value pairs and they weren't standardized, so I always managed to avoid learning the grammar(s). I'm sure if I put much effort into it, I could figure out TOML, but I don't want to ask my users to figure out yet another configuration language.

If I'm going to make them learn another configuration language, it's going to have something more to offer than just 'simpler than YAML'. Maybe Starlark for more powerful configuration applications (think infra-as-code where YAML/JSON/etc clearly isn't powerful enough) or if someone ever builds it, "JSON with comments and multiline strings" which offers simplicity without compromising familiarity. Actually, it would be really interesting to hear what people's ideal configuration languages would look like.

> That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this.

I'm not really familiar with this. I'll have to read up.

TOML is what I'd naturally write as notes if I wanted to document how something is working.

YAML is all sorts of strange.

JSON needs comments and support for trailing commas. Since that isn't going to happen.... TOML!

"Good riddance to XML" is a bit much. Did you read the article? XML is ideal for representing tree structures. Pick the tool for the job.

For example, XAML does an excellent job in declaring your UI. Its use of namespacing, and how you can use child nodes to declare properties of an object, makes it highly flexible albeit slightly verbose.

Years of experience > "the article"

JSON is a tree structure. It is dictionaries and arrays mixed together in a hierarchy.

Your opinion != Everyone's opinion

Don't get me wrong, I prefer JSON in most cases. But XML does have many valid use cases. Perhaps you haven't had an opportunity to see its beauty. You can't blindly say JSON > XML or JSON < XML, or "XML sucks" -- this shows ignorance.

I didn't say any of that. JSON is a tree structure, that isn't an opinion.

My bad, I think I was responding to another comment.

Using child nodes to declare properties of an object is the main reason I dislike XML. Because some people use children, and some use attributes, and some use both. Granted, that isn't XMLs fault, but every time I to have get XML data into a usable format it feels like a struggle.

You’re welcome to your opinion. I disagree that XML is ideal for representing tree structures or anything else for that matter. I’ve used XML a lot (including for UIs and other tree-like data structures), but ever since JSON became popular I haven’t found myself missing it.

> For example, XAML does an excellent job in declaring your UI.

JSX does a better job.

I hate XAML, it doesn't add anything except verbosity over just using C#. The original goal of XAML was to allow bindings to multiple programming languages and to allow designers to use a suite of amazing tools to finished designs off to developers for implementation.

What ends up happening is developers write XAML, then they write C# to back up what XAML can't do, then they have a complex build stage to shove all this crap together, but instead of XAML just being transpiled to C# it has its own run time thing that hosts compiled XAML files.

JSX by comparison is a trivial transformation to JavaScript. It is easy to read, and it does not try to replace JS control structures.

In fact you could probably trivially transform a JSX syntax to ANY C type of language, I know there is a proposal (implementation?) for a JSX-like to Dart.

The sheer awesomeness of JSX is hard to describe if you haven't used it. It is like something asked "what is the simplest, easiest to understand templating language we can possibly create?" and out popped JSX.

My favorite part of JSX is how it doesn't try to have control structures in it. Everyone else gets this wrong and adds some sort of string types DSL to their templating language.

JSX doesn't do that. If you want to map over an array and spit out a bunch of elements, you just do so in JavaScript/TypeScript.

Interesting, I'll have to take a second look at JSX. So far I feel like in certain cases XML is better at declaring objects and their properties (along with their Types). XAML can declare any type and configure it as needed, it is a way of declaring components in a logical fashion. I wonder if JSX/alternatives are a true superset of XML-derived formats. FYI, XAML generates a binary format at compile-time. From my many experiences with desktop applications, the additional code for XAML/UI is required regardless of the languages/frameworks, to control things like animations, behaviors, markup extensions.

> XAML can declare any type and configure it as needed, it is a way of declaring components in a logical fashion.

XAML is a lot like Python object constructor syntax with all named parameters except one positional parameter that is a list of child objects (obviously, explicit closing tags rather than a closing square bracket and paren is a difference, but structurally it's m almost identical.) It's certainly a convenience for declaring certain kinds of object trees, especially if your main programming language doesn't have a similarly succinct object construction syntax. JSX is effectively a way of adding an equivalent object constructions syntax to the host (JS) language, rather than requiring it to be in separate code files.

YAML predated / was concurrent with JSON. Both were in reaction to the bloat of XML.

It's funny that YAML spec is three times as long as XML 1.0.

The XML bloat is on the processing side.

Or rather, was. At the time one could either:

- write a sax event based parser that scaled but was low level

- use a DOM parser with a fairly convoluted API. The combination of attributes and children makes for wordy accessors.

Both YAML and JSON provide formats that more readily deserialize into native map / list / string / number types which at the time was quite convenient.

Reply on news.ycombinator.com