No one should really be writing UI code by modifying a file by hand because UIs are often complex and deep, so the file structure used to store the UI data doesn't need to be human-readable.
This is true for any data - once you hit a moderate level of complexity neither JSON or XML really work - you need to build a tool to manipulate the underlying data rather than changing it directly. If you do that then it doesn't matter how readable or 'ugly' the data is because a human being shouldn't need to access it directly. This leads to other benefits you can optimize for like size or parsing speed or redundancy instead.
HTML isn't a UI description. It's a document description. HTML + CSS + [browser behavior|Javascript] is the UI description, and arguably some more complex web apps are getting to the point were they've gone past the point where HTML, CSS, and JS are the best formats for describing the way they work.
They never were the best way. Other application GUI systems are less painful because they were designed for that from the beginning. HTML remains OK for documents, though.
One of the biggest issues with the most popular 'tool-only language' (Excel) is that there is no reasonable way to audit changes. Same goes for UIs that are backed by inscrutable file formats.
Readable and understandable diffs is not a property of text files. It is very easy to design tools and formats that use text files, yet do not give you diffs that are readable or understandable.
Readability and understandability depend on more strict requirements that a text file format may or may not have. Many do, but far from all do.
For instance, JSON files do not have requirements on the ordering of keys. When making a small change to a JSON file, it is entirely legal to reorder every single key, completely destroying the diff, and an automatic tool may very well do this.
And as a counter-example, we could easily use a binary representation of JSON data, but use a diffing tool that normalises key ordering to provide diffs that are more readable and understandable than a text diff of a JSON file, even without malicious reordering of lines.
But this means you need diff tools, version control systems and editors (edit: and merge tools) for every single format, which while nice in theory (hey plugins!), in practice doesn't work well. Text is nice because it sort of a minimum common denominator.
Of course semantic diffs would be nice; even, or especially, for code for example but while they do exist they haven't seen much uptake because they do not integrate well with existing tooling.
And it's also easier to debug human readable text then it is to debug raw binary. Text is such a good abstraction layer that we almost never have to deal with character encodings, etc. Only problem is that it has to be parsed twice, first from binary to text, then from text to whatever. But computers are good at such tasks, while humans are not.
Yeah I had to hand edit some IOS ui stuff when a version diff caused problems. human readibility even if difficult is beneficial. Useful for generating diffs as well
This reminds me of the line of thought from the React community. Make everything as complex as possible (vdoms, etc.). But there are other ways, frameworks, styles to achieve what people want without that level of complexity. A "moderate" level of complexity absolutely does not require special tooling to manipulate underlying data.
> No one should really be writing UI code by modifying a file by hand because UIs are often complex and deep, so the file structure used to store the UI data doesn't need to be human-readable.
Even with your other comment about "until you hit a moderate level of complexity." People are already creating some complex things with it. In fact, they can be more complex than what you can achieve with traditional frameworks when you consider the time it takes; what takes me a day in UIKit etc. takes me a minute in SwiftUI, so I can quickly move on to the next bit.
With declarative UI code I could literally have a usable app in the same time it takes me to struggle with getting separate visual designers + logic editors to agree over a single moderately complex component.
Though, it is several layers of abstraction over what really happens behind the scenes, so I guess a part of your point stands.
The other replies cover most of my reaction, but there’s one more thing I want to add:
If you have a binary format for a tree structure, you almost always end up accruing garbage as you edit it. That always happens in rich HTML editors, for example.
For something like an image editor, the bitmap is OK because it’s not a tree structure and doesn’t balloon out of control as you edit.
Where your image is tree-structured, eg Photoshop layers, the editing tool will generally show you the exact layer tree in a sidebar, so you can make sure it stays clean and tidy.
It’s easiest to keep it tidy when the canonical source is human-readable text. (Although it’s worth watching out for formatting differences. Something like gofmt helps there.)
I LOATHE XML Schema. I have used it for years, and have never memorized it. I still need to look it up like a n00b, every time I use it.
But the simple fact of the matter is, is that so many people and projects have inculcated it into hundreds (if not thousands) of toolsets and specs (Like -Ick- WSDL), that it really is the only viable game.
People tend to like JSON precisely because it eschews the kind of overhead that is the definition of XML Schema.
I don't know JSON schema really well; Can you say you want a `price` value to be a non-negative decimal value with at most two digits after the comma, and you want the `currency` value be exactly one of the following : "EUR", "USD", "GBP", the default if not specified being "EUR"?
The thing about XML Schema, is that it is completely "baked into" pretty much every tool and library out there, so you can do "on-the-fly" runtime validation.
JSON is really about minimizing text. It works really well for this.
Another issue, is that JSON doesn't have comments, so it can be difficult to annotate a JSON file.
This doesn't seem to solve any problem related to UI. Because tree can be converted to a list and vice versa. The added advantage is tree structure is natural.
But the way article is put forward is as if using json we cannot achieve tree structure
Consider a comparison of examples using JSON schema:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"description": "Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'",
"definitions": {
"schemaArray": {
"type": "array",
"minItems": 1,
"items": { "$ref": "#" }
}
}
...
<schema schema="http://json-schema.org/draft-04/schema#">
<description>Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'</description>
<definitions>
<schemaArray>
<type>array</type>
<minItems>1</minItem>
<items ref="#" />
</schemaArray>
...
$schema and $ref are differentiated by convention in JSON, and require repeated consideration in every parsing scenario to treat them as exceptions relative to actual values within the JSON document. In the XML representation, the distinction is implicit and handled automatically for you by every parser.
>$schema and $ref are differentiated by convention in JSON, and require repeated consideration in every parsing scenario to treat them as exceptions relative to actual values within the JSON document.
This is a good thing. The main issue with XML is how ridiculously overcomplicated and overengineered its design was. This isn't just a matter of usability, it has security implications because it increases the attack surface of anything that uses it (e.g. the XML billion laughs attack).
> This is a good thing. The main issue with XML is how ridiculously overcomplicated and overengineered its design was.
Citing element attributes as an example of such complexity is hardly reasonable. The JSON example above contains the same complexity, just moved to the application/implementation space, instead of the parser (so your app is more complex to handle it).
> e.g. the XML billion laughs attack
Also not a great example. This is a simple DOS attack, of which there are many other examples: zip bombs, yaml bombs, etc. None of these invalidate yaml nor zip themselves.
There are also far worse attacks on XML than the billion laughs attack (XXE attacks are an entire category in the OWASP top 10).
What these attacks have in common is that they use references. They aren't unique to XML because any format wanting to handle references (like JSON schema!) will have to account for them.
The difference is, since references aren't built into the JSON spec, you have to do it yourself (and protect against attack like this in your own code). Since XML handles this at spec. level, common XML parsers can account for & mitigate for this for you (which fyi, modern ones do).
---
Side note (and a vote in favour of JSON):
By your own metric, JSON is actually "more complex" (in a good way) than XML in one area: value types. XML values are strings. Having value types is one massive advantage of JSON imo.
In that sense, it would be nice to see a language that combines both of these "complexities", to form something better.
I would disagree about having more value types. JSON has more syntax for value types, but it only has four: string, integer, float, and boolean. XML has less syntax for value types (everything is serialized as a string), but it has a way to define types of attributes with XML Schema and there you get much more primitive types already (decimal, date & time, binary). XML approach is more uniform: it uses schema to look up all the parsing rules. JSON uses syntax for some types and (ad-hoc) schema-like logic for others.
>Citing element attributes as an example of such complexity is hardly reasonable. The JSON example above contains the same complexity, just moved to the application/implementation space
Where it belongs...
>so your app is more complex to handle it
There is a trade off between more simple markup and more complex code and vice versa. I would argue it is almost always better that way around because it helps enforce clear separation of concerns. I'm similarly allergic to putting complex logic in template code because that also violates a clear separation of concerns.
>Also not a great example. This is a simple DOS attack, of which there are many other examples: zip bombs, yaml bombs, etc.
This is precisely why it's a great example. YAML has the same problem with overcomplexity XML does. JSON has no such issues.
>There are also far worse attacks on XML than the billion laughs attack (XXE attacks are an entire category in the OWASP top 10).
Right, billion laughs is part of a class of security vulnerabilities that are enabled by XML's bloated design.
>The difference is, since references aren't built into the JSON spec, you have to do it yourself
Except you don't. I'm not sure if I've ever implemented references in any JSON schema I've ever used. It's an entirely pointless feature as far as I'm concerned. I've seen them used in YAML (where it's equally yucky) and every time it's been used it's been as a band aid over deficient schema design that also inadvertently made the markup harder to understand.
>By your own metric, JSON is actually "more complex" (in a good way) than XML in one area: value types. XML values are strings. Having value types is one massive advantage of JSON imo.
I hardly think having 4/5 scalar types counts as spec overcomplication. If you want a measure of how complex each markup language is simply look at the length of the respective specifications. XML is ridiculous.
Representing is easy task. You need to parse that representation. And XML here is worse than JSON for typical programming graphs. You can't express number or array with XML. XML Schema helps to add more structure, but JSON does not need that, array and numbers are built-in. And I would say, that XML Schema is too powerful and that's usually not needed by developers. JSON is just a fine medium, simple enough and powerful enough.
But when you deal with inherently hierarchical data, trees, XML is good.
> Numbers can be expressed, they just have to be parsed on the client.
But client has to know that they're numbers. So you can't just parse XML into JavaScript object without any knowledge about its structure.
> For array, child elements are ordered and form an array naturally.
But you can't express array of 0-length this way without explicit knowledge about structure. And you can't distinguish array of 1-length from an ordinary value without explicit knowledge about structure.
This is tag with name Number and with two attributes. Are you trying to invent XML sublanguage? It's possible. But with JSON it's already invented and there are multiple libraries for every programming language. What should I use to parse your format?
It's inventory and optimized for certain language types, specifically those that are loose with their numeric types. This includes most scripting languages.
In languages that require specific intrinsic types to be defined for a number, there are usually a lot to choose from and using the wrong one can be a real problem when converting from XML or JSON to a native format.
On a very simple level, what container do we use to encode the following data structures:
In most dynamic languages, hut number type used is just the included numeric container, which generally includes some sort of complex decision between floating point and bignums. For something like C, Java or Rust, generally we would want to choose an appropriate type. In this case, it looks like an unsigned 8-bit integer will suffice for most, and a 16 bit signed value for Java (which doesn't support unsigned values).
But what if the next number is much larger? Should we really need to parse all the values to determine the correct data type to use? That seems very inefficient, and we can't even be sure that we'll encounter values that accurately illustrate the range of values in one parsing. What if the next message or file we parse has large values?
For these languages the inherent data type definition of JSON is a poor match, since its looseness does not transfer easily to a language which does not inherently support it. If your target languages supports dynamicaly resizing untyped arrays, untyped key-value maps, and generic number types that support both very big and floating number types automatically, then JSON is an almost perfect representation format for you. If your target language works best when those items are broken into smaller more explicit components, there's a lot of extra work in parsing JSON, and I can see how that makes XML not look much worse in comparison (especially since your parsed data structure will likely be leaner because there isn't the overhead inherent in those convenient magical types, references are rarely as efficient as pointers).
Yes. And that's my point: you don't need schemas to work with JSON. JSON Schema exists, of course, it would be strange if someone did not invent it, as it's an obvious idea. But I've yet to see anyone using it.
I was going to make the same post, upvoted you instead!
What's nice about JSON is that there's very little ambiguity in how to serialize / deserialize data structures. That's what's so powerful about it. As a result, using "magic" serializers with language-native data structures often works well and has little gotchas.
In general, I think a lot of people hopped onto the XML bandwagon assuming that it would always sanely translate back and forth between XML and native data structures. This is not the case. When XML is the (cough) "best" format, the underlying data structures of different programs operating on the XML will look extremely different. Furthermore, XML terminology will end up leaking into business logic, because the semantics of the document are inseparable from handling it.
In general, I think the biggest sign that XML is the wrong choice is when someone's using a "magic" serializer, or when the data structures very closely follow the document structure. In those cases, JSON was probably a better choice.
I have yet to read anything that convinces me that XML is good for anything. Just because XML in certain cases is less bad than some other cherry-picked technology, doesn't mean that there aren't other better options.
Well, for instance, let's take the HTML code of your comment (which happens to be a valid XML document):
<span class="commtext c00">I have yet to read anything that convinces me that XML is good for <i>anything</i>. Just because XML in certain cases is less bad than some other cherry-picked technology, doesn't mean that there aren't other better options.<p>See also Erik Naggum's legendary rant: <a href="https://www.schnada.de/grapt/eriknaggum-xmlrant.html" rel="nofollow">https://www.schnada.de/grapt/eriknaggum-xmlrant.html</a></span>
In order for me to answer that, you must be more specific about the purpose of the representation.
For the purpose of authoring comments on Hacker News (HN), I for one am grateful= that HN doesn't make us type out HTML. I also doubt very much that HN stores our comments in a different representation (e.g. HTML) than the one they were authored in.
That's a very good point. Thing is, markdown (or a subset of it, as on HN) is very limited. Great for short comments, bad when you want to do something a little more complex, like a blog post (I always end up addding some HTML here and there in my markdown blog posts, when I want to include a video for instance).
The other problem is that HN comments and all those markdown-like formats are very ad hoc. If I copy/paste my reddit comments on HN, or the other way around, it won't always work as expected. In both cases, it has to be translated to HTML to be displayed by the browser, too.
So, the context would be: an export format for complex, multi-paragraphs textual documents with meta-information.
So, the context would be: an export format for complex, multi-paragraphs textual documents with meta-information.
If you add the condition that it be human-readable, I admit I am not able to point to an existing format that is obviously better suited for this than XML.
Before reading this please note that I am not advocating for or against XML.
A well reasoned XML instance can replace HTML for most things from presentation, accessibility, interaction, content negotiation, and so forth. You can apply JavaScript and CSS immediately to an XML instance. You don't get any of that capability with JSON, YAML, or anything similar.
I really think the people who hate XML the most are those are those who lack the imagination to move beyond raw data and query relationships. I agree XML isn't good at this, which is why it completely offloads that capability to a sibling technology: DOM.
I have also never seen anybody with a comfortable understanding of the DOM believe JSON, YAML, and the like fill that void, but then these other technologies do not primarily exist to structure human consumable content directly for human consumption. The most important part of the article you linked to describes markup relevance as a percentage of syntax overhead. The more the described content becomes an extraction of computer oriented data the more that percentage goes up thus making XML progressively a bad decision, but the opposite is also true.
The article really nails its bias in this regard by fixating on data as a facet opposed to information as a structure. When the goal is to provide primarily a structure, as opposed to fundamentally offering a syntax, the cost to scale grows inversely to the quantity of content provided. That is largely thanks to lexical scope, which allows a richer interpretation of context without any additional or specified syntax. That is the nature of information versus data. Conversely, data conveyance schemes that exist to primarily offer a syntax scale proportionally to the content provided because the ratio of syntax to content is static without any additional meaning.
XML is so awesome for UI layouts. I had a thesis that I worked on that was basically a subset of HTML (check the SMIL specification for something similar, albeit a bit more complicated, SMIL used to be a W3C recommendation).
It was so easy to understand that every person who was able to use a computer would pick it up quickly. This was not the case for HTML, my guess is because there are a ton of HTML tags and that can be overwhelming for a certain type of audience, whereas here there are at most 10 tags to learn.
The framework I'm talking about still exist, it's called XIMPEL [1] (sadly SMIL kind of died). It may seem like a weird thing, but IMO it's the only open-source framework that has an intuitive way to make non-linear storytelling easy on the web easy. People can kind of hack a choose your own adventure media story with YouTube, but XIMPEL really is so much better at it because it's actually made for that purpose. And the biggest reason why XIMPEL is simpel because it uses XML as its template language.
People just see the tags as lego blocks and build non-linear media essays, stories or even small (media-focused) games with it.
> It was so easy to understand that every person who was able to use a computer would pick it up quickly.
I find this hard to believe. I know many people who use computers but are not IT professionals or even hobbyists. Without an easy to use GUI they can't accomplish much. I couldn't imagine them picking up anything to do with XML.
If you scope it down to UI developers you're taking less than 1% of people. Far from everyone. Even if you scope it down to IT people it's less than 1% of people.
It’s not that they can’t. They’ve just been told they can’t.
I’ve been told that clerks at bell labs were using troff because they were told they weren’t programming and I think GUIs have the same opposite effect.
There’s the always forgotten type of computer users: those who use computers for productivity. People who need to achieve some business goal and they have the energy to learn.
Take for instance insane Excel spreadsheets glued with VBA powering entire businesses, built by accountants and other professionals.
Congrats on re-inventing frontend web development, I heard Facebook's hiring. This is one of the reasons people use frontend frameworks (besides state management).
I should add that I'm not literally saying that we should do this. I assume smarter people than me have thought this through, and that there are good reasons why my proposal would be a bad idea. I'd be interested to know what those reasons are.
I am not intentionally being hostile, just pointing out that your stated deficiency is the one of the reasons why people migrated to component-style frameworks. It's an affirmation of your comment's validity not a criticism.
Yep, to some degree. Though what I would love in an xml-based UI description language is the ability to opt into default system behaviors, while maintaining the ability to use whatever semantic naming convention that fits my application.
I wrote this code in another comment, but imagine if you could hook functionality to an element via defined attributes. With custom elements, you have to add the functionality via a script, and they aren't system functions (from what I can remember, I may be wrong).
The tags are defined so that there is reasonable default behavior. For example <label> is used to label a form field. Clicking the label focuses the form field.
Right, but this offers two benefits: (1) semantic naming, and (2) composed functionality. So for example, if you wanted an element that exposes label behavior and list-item behavior, you could do that. With html, you have to use 2 elements:
Yes, this is a major flaw of HTML, it is very specific about where certain elements can and cannot be, so you can't really even design a solution like the above.
The XML example seemed odd to me as written. In the JSON case, yes there was a prefixed key "$reports", but it told me what the relationship was. Looking at the XML, what does it mean for an Employee to be nested inside another Employee?
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?
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.
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.
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.
"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.
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.
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.
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.
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.
- 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.
Another reason why XML might be better for UI Layouts (in addition to typed nodes) is that it allows mixed content, making it more concise in the case where marked up text is included.
Whether it is JSON or XML, what I particularly like about both approaches is that both are fundamentally HATEOAS (https://en.wikipedia.org/wiki/HATEOAS)
Quite readable but it's a hell to parse. The first argument is the name of the element, but what is the second one? If it is a string or an array, it's the first child, but if it's an object, it's the attribute set?
[
"div",
[
"The ",
[
"a",
{ "href": "https://www.json.org/" },
[ "JSON format" ]
],
" was invented by ",
[
"em",
"Douglas Crockford"
],
"."
]
]
With all children being encapsulated in an array...
edit: though it again gets confusing when the 0 index is sometimes the element type and sometimes the straight text... so never mind I guess the problem persists.
Yeah that seems to make the most sense. I had to actually work it out before I saw it. I was looking for some further separation beyond indices but I just ended up over-thinking it.
That's is roughly how it's done in Reagent[1]/re-frame[2]:
[:div "The" [:a {:href "https://www.json.org/"} "JSON format"]
" was invented by " [:em "Douglas Crockford"] "."]
The fact that EDN[3] supports keywords makes it a bit easier to parse. Representing HTML in EDN this way was first done in a library called Hiccup[4], so it’s usually called “Hiccup” even when encountered outside of the original library.
> The first argument is the name of the element, but what is the second one?
If the second argument is an object/dictionary, it's attributes. Otherwise, it's the first child. Alternatively, the ambiguity can be resolved by using null/0 instead of empty attributes.
R uses markdown + a separate file with the output cached and while the non-rendered file is easier to version the whole thing is a lot more difficult to handle.
It's funny to me that even in an XML shining example of purpose you've got non-semantic "<div>" there likely because, "just float where I want, dammit!"
Just imagining a JSON that starts with
"dummy": "don't remove this or the API will mis-align this across two structs!!!"
The semantic of these things is what the code does with them. It's the only semantic there is. E.g. the <i> tag has perfect semantic, while <article> not that much.
A. You forgot to capitalize the first word in the sentence.
B. Your dangling whitespace characters are all wrong.
This tells me that the steps you took to craft the serialized version of the data were totally disconnected from the intent of the transmission.
You were more focused on syntax (decorative array brackets, and curly brace closures), than the human-readable aspects of the text.
More often than not, this is expressed as unclosed tags in XML mark up, which would express as run-on underlined link activation and bold face. Yet this is often cleaner, when formatting gets stripped out, preserving whitespace delimiters such that text us ungarbled.
In the source, this sometimes leads to excessive whitespace bloat, but luxuriously so.
In this particular example you need hierarchy for on at least two occasions.
1. The xml denotes that the whole thing should be wrapped in a div, and shouldn't just be considered a paragraph. With only lists you can't denote what kind of level you're at, unless you force each level to always carry the same meaning (which makes the format weaker than XML).
2. Setting "bold" to true isn't the same thing as emphasizing the text. Typically 'em' is italic, but more importantly a nested 'em' should no longer be italic. To achieve this with JSON you're forced to combine formatting and structure in a way that CSS was designed to prevent.
The information stored in this XML is essentially that:
{ "string": "The JSON format was invented by Douglas Crockford",
"structure" [
[ 0, 48, "div", {} ],
[ 4, 13, "a", { "href": "https://www.json.org" } ],
[ 32, 48, "em", {} ]
]
}
(If we allow empty elements, we'd need another field in the structural entries to be able to reconstruct the hierarchy.) Now I'd say that XML way to combine these three kinds of data is pretty elegant and natural. The JSON would be impossible to write by hand, although it's good for machine processing.
Upd: The three kinds of data: the string, the structures (div, a, em), and their position in the string.
Yup, use object notation for passing around objects, use a markup language for markup. It's almost like reading the names gives a hint as to what it was designed for and probably best at.
My sniff test is that if you're editing it by hand, JSON is a poor format because you'll want the benefit of a schema or at least a user-friendly format. If you're not, the syntax doesn't really matter so we should evaluate it on technical merits (verbosity, computational complexity for serialization/deserialization, memory footprint, etc).
I use:
- config file formats for config files (usually TOML or INI format)
- data formats for data (JSON, protocol buffers, etc)
- markup formats (Markdown, XML/HTML) or code for markup
I really don't get why people try to force all use cases onto the same format. Use whatever is well suited for the task, preferring familiarity over unnecessary technical benefits.
Having worked with SOAP/XML extensively at my past job I can say for web services I much prefer REST/JSON. JSON is much easier to work with and key value pairs make it much easier to get what you need. Parsing an XML tree can become a nightmare very quickly.
> However, we’ve created another problem in the form of inconsistency: some user properties are represented as element attributes, others as child elements.
Exactly. I’ve seen XML with element attributes and child elements all over the pace. No rhyme or reason for any of it. It’s especially bad in older systems.
I pushed hard at my last job for the SOA team to build REST/JSON web services. Oracle sold them a product to bridge the gap and they got End Of Life announcements 6 months later! Glad I’m gone.
1. Why is parsing a tree which is encoded in JSON easier?
2. Why does it matter if an element is in an attribute or in child elements. You need some kind of schema anyway, right?
It depends on the API of the system. I’ve worked on middleware that would not be able to get an attribute, it lacked the capability. Other systems used JavaScript and it was much easier with JSON
I still work with SOAP occasionally. I'd never recommend anyone start a new project with it, but I've never had to manually parse anything. Did the framework you had to work with not provide decent XSD/Class code generation and serialization/deserialization tools?
Yes and no. I worked with several middleware systems, a few disparate systems, and a couple very old systems. Right now I’m working on a few web service integrations with SerivceNow for Microsoft Teams, ticketing, and CMDB stuff, it has decent tools.
When you are hacking systems together for large/old enterprises the water gets muddy fast.
Technically, there are REST/JSON equivalents, but I don't see them actually used much in the wild - so much of the time with REST APIs you are stuck with whatever half-baked, out-of-date documentation that somebody may or may not have written, or just randomly poking at it through trial and error to discover how it works.
Agreed WSDLs are the only thing I love about SOAP and they are missing from REST. Most tools can import a WSDL and generate the code and structure for you.
Sometimes even getting a sample of the expected JSON format can be hard. If you’re not versioning you’re APIs you can break everything if the schema changes.
I used to debate this with the SOA manager. Swagger looks ok but never dealt with it in production or saw it in the wild with our customers.
The JSON examples are not even valid, the "$reports" properties on department are written as comma separated lists without enclosing array brackets.
I guess XML might be perfect for when you can't decide between singular and plural and want to leave the problem to others...
Because that's the biggest problem besides charset encoding that JSON helps solving: in JSON, you can be unmistakably clear that a given property is to be interpreted as a list of values, even when the current number is less than two. In XML you can just vaguely communicate that intent with an intermediary "plural element" unless you go full schema.
I find JSON better for random lookups, and XML good for sequential reads. UI falls into the later basket: start at the root, read the children, etc, etc.
Good thing we've had XML defining layouts for many years, despite many of the technologies that used the pattern being dead. XML as a layout definition vs XML as data were topics devs discussed heavily 15 years ago, too. So many Java frameworks used Xml to describe the user interfaces (like JavaServer Faces, early Tapestry, etc.). At one time, I worked with a lot was Adobe Flex which used MXML to define user interfaces [1], don't forget about Microsoft's XAML.
It's actually amazing to me how many of Flex's great ideas live on in other frameworks not dependent on the Flash Player, and looking at some modern day React often reminds me if it.
One thing I really miss when working on JSON vs XML data are comments. A workaround is to make the comment a valid string in the data, but still not as good as having the ability to comment an arbitrary line.
273 comments
[ 35.5 ms ] story [ 431 ms ] threadThis is true for any data - once you hit a moderate level of complexity neither JSON or XML really work - you need to build a tool to manipulate the underlying data rather than changing it directly. If you do that then it doesn't matter how readable or 'ugly' the data is because a human being shouldn't need to access it directly. This leads to other benefits you can optimize for like size or parsing speed or redundancy instead.
I think you underestimate the convenience of a text format.
It does not only provide a simple way to generate it, but also provide a way to modify it by hand.
One of the biggest issues with the most popular 'tool-only language' (Excel) is that there is no reasonable way to audit changes. Same goes for UIs that are backed by inscrutable file formats.
Readability and understandability depend on more strict requirements that a text file format may or may not have. Many do, but far from all do.
For instance, JSON files do not have requirements on the ordering of keys. When making a small change to a JSON file, it is entirely legal to reorder every single key, completely destroying the diff, and an automatic tool may very well do this.
And as a counter-example, we could easily use a binary representation of JSON data, but use a diffing tool that normalises key ordering to provide diffs that are more readable and understandable than a text diff of a JSON file, even without malicious reordering of lines.
Of course semantic diffs would be nice; even, or especially, for code for example but while they do exist they haven't seen much uptake because they do not integrate well with existing tooling.
Only if you ignore the bit where I said "once you hit a moderate level of complexity". Text file formats work really well for simple things.
I strongly disagree. SwiftUI is fucking amazing.
https://developer.apple.com/tutorials/swiftui/
Even with your other comment about "until you hit a moderate level of complexity." People are already creating some complex things with it. In fact, they can be more complex than what you can achieve with traditional frameworks when you consider the time it takes; what takes me a day in UIKit etc. takes me a minute in SwiftUI, so I can quickly move on to the next bit.
With declarative UI code I could literally have a usable app in the same time it takes me to struggle with getting separate visual designers + logic editors to agree over a single moderately complex component.
Though, it is several layers of abstraction over what really happens behind the scenes, so I guess a part of your point stands.
If you have a binary format for a tree structure, you almost always end up accruing garbage as you edit it. That always happens in rich HTML editors, for example.
For something like an image editor, the bitmap is OK because it’s not a tree structure and doesn’t balloon out of control as you edit.
Where your image is tree-structured, eg Photoshop layers, the editing tool will generally show you the exact layer tree in a sidebar, so you can make sure it stays clean and tidy.
It’s easiest to keep it tidy when the canonical source is human-readable text. (Although it’s worth watching out for formatting differences. Something like gofmt helps there.)
Yet people do this everyday. So it's not that complex.
https://docs.microsoft.com/en-us/visualstudio/xaml-tools/des...
Otherwise, I try to use JSON, where possible, because I am not a masochist.
https://json-schema.org/
I LOATHE XML Schema. I have used it for years, and have never memorized it. I still need to look it up like a n00b, every time I use it.
But the simple fact of the matter is, is that so many people and projects have inculcated it into hundreds (if not thousands) of toolsets and specs (Like -Ick- WSDL), that it really is the only viable game.
People tend to like JSON precisely because it eschews the kind of overhead that is the definition of XML Schema.
The thing about XML Schema, is that it is completely "baked into" pretty much every tool and library out there, so you can do "on-the-fly" runtime validation.
JSON is really about minimizing text. It works really well for this.
Another issue, is that JSON doesn't have comments, so it can be difficult to annotate a JSON file.
But the way article is put forward is as if using json we cannot achieve tree structure
https://www.ietf.org/rfc/rfc3252.txt
Consider a comparison of examples using JSON schema:
$schema and $ref are differentiated by convention in JSON, and require repeated consideration in every parsing scenario to treat them as exceptions relative to actual values within the JSON document. In the XML representation, the distinction is implicit and handled automatically for you by every parser.This is a good thing. The main issue with XML is how ridiculously overcomplicated and overengineered its design was. This isn't just a matter of usability, it has security implications because it increases the attack surface of anything that uses it (e.g. the XML billion laughs attack).
Citing element attributes as an example of such complexity is hardly reasonable. The JSON example above contains the same complexity, just moved to the application/implementation space, instead of the parser (so your app is more complex to handle it).
> e.g. the XML billion laughs attack
Also not a great example. This is a simple DOS attack, of which there are many other examples: zip bombs, yaml bombs, etc. None of these invalidate yaml nor zip themselves.
There are also far worse attacks on XML than the billion laughs attack (XXE attacks are an entire category in the OWASP top 10).
What these attacks have in common is that they use references. They aren't unique to XML because any format wanting to handle references (like JSON schema!) will have to account for them.
The difference is, since references aren't built into the JSON spec, you have to do it yourself (and protect against attack like this in your own code). Since XML handles this at spec. level, common XML parsers can account for & mitigate for this for you (which fyi, modern ones do).
---
Side note (and a vote in favour of JSON):
By your own metric, JSON is actually "more complex" (in a good way) than XML in one area: value types. XML values are strings. Having value types is one massive advantage of JSON imo.
In that sense, it would be nice to see a language that combines both of these "complexities", to form something better.
Where it belongs...
>so your app is more complex to handle it
There is a trade off between more simple markup and more complex code and vice versa. I would argue it is almost always better that way around because it helps enforce clear separation of concerns. I'm similarly allergic to putting complex logic in template code because that also violates a clear separation of concerns.
>Also not a great example. This is a simple DOS attack, of which there are many other examples: zip bombs, yaml bombs, etc.
This is precisely why it's a great example. YAML has the same problem with overcomplexity XML does. JSON has no such issues.
>There are also far worse attacks on XML than the billion laughs attack (XXE attacks are an entire category in the OWASP top 10).
Right, billion laughs is part of a class of security vulnerabilities that are enabled by XML's bloated design.
>The difference is, since references aren't built into the JSON spec, you have to do it yourself
Except you don't. I'm not sure if I've ever implemented references in any JSON schema I've ever used. It's an entirely pointless feature as far as I'm concerned. I've seen them used in YAML (where it's equally yucky) and every time it's been used it's been as a band aid over deficient schema design that also inadvertently made the markup harder to understand.
>By your own metric, JSON is actually "more complex" (in a good way) than XML in one area: value types. XML values are strings. Having value types is one massive advantage of JSON imo.
I hardly think having 4/5 scalar types counts as spec overcomplication. If you want a measure of how complex each markup language is simply look at the length of the respective specifications. XML is ridiculous.
But when you deal with inherently hierarchical data, trees, XML is good.
Numbers can be expressed, they just have to be parsed on the client. For array, child elements are ordered and form an array naturally.
But client has to know that they're numbers. So you can't just parse XML into JavaScript object without any knowledge about its structure.
> For array, child elements are ordered and form an array naturally.
But you can't express array of 0-length this way without explicit knowledge about structure. And you can't distinguish array of 1-length from an ordinary value without explicit knowledge about structure.
I'm currently working against a REST API which JSON format has three different date formats as sub-elements of the same root object...
<Number value="123" type="i32" />
It's inventory and optimized for certain language types, specifically those that are loose with their numeric types. This includes most scripting languages.
In languages that require specific intrinsic types to be defined for a number, there are usually a lot to choose from and using the wrong one can be a real problem when converting from XML or JSON to a native format.
On a very simple level, what container do we use to encode the following data structures:
In most dynamic languages, hut number type used is just the included numeric container, which generally includes some sort of complex decision between floating point and bignums. For something like C, Java or Rust, generally we would want to choose an appropriate type. In this case, it looks like an unsigned 8-bit integer will suffice for most, and a 16 bit signed value for Java (which doesn't support unsigned values).But what if the next number is much larger? Should we really need to parse all the values to determine the correct data type to use? That seems very inefficient, and we can't even be sure that we'll encounter values that accurately illustrate the range of values in one parsing. What if the next message or file we parse has large values?
For these languages the inherent data type definition of JSON is a poor match, since its looseness does not transfer easily to a language which does not inherently support it. If your target languages supports dynamicaly resizing untyped arrays, untyped key-value maps, and generic number types that support both very big and floating number types automatically, then JSON is an almost perfect representation format for you. If your target language works best when those items are broken into smaller more explicit components, there's a lot of extra work in parsing JSON, and I can see how that makes XML not look much worse in comparison (especially since your parsed data structure will likely be leaner because there isn't the overhead inherent in those convenient magical types, references are rarely as efficient as pointers).
What does that look like when you parse it?
That's why XML Schema exists. So, everything you listed is possible in XML if you don't put aside some specifications on purpose.
And JSON is so self-describing that someone came with... JSON Schema.
https://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com...
XML is also a query language with XQuery (https://en.wikipedia.org/wiki/XQuery).
XML is also a nested structure path specifier with XPath (https://en.wikipedia.org/wiki/XPath).
XML is also a file format with SVG (https://en.wikipedia.org/wiki/Scalable_Vector_Graphics), OpenOffice XML (https://en.wikipedia.org/wiki/OpenOffice.org_XML), OpenDocument (https://en.wikipedia.org/wiki/OpenDocument), ePUB (https://en.wikipedia.org/wiki/EPUB), DocBook (https://en.wikipedia.org/wiki/DocBook), and many others (https://en.wikipedia.org/wiki/List_of_XML_markup_languages).
XML is also an data/object serialization format with libraries like Jackson (https://github.com/FasterXML/jackson), YAXLib (https://github.com/sinairv/YAXLib), Boost (https://www.boost.org/doc/libs/1_38_0/libs/serialization/exa...), Pyxser (https://github.com/dmw/pyxser), and many others.
XML may not be as elegant as JSON, but it has a wide variety of uses and wide adoption across many programming languages (libraries), and disciplines.
What's nice about JSON is that there's very little ambiguity in how to serialize / deserialize data structures. That's what's so powerful about it. As a result, using "magic" serializers with language-native data structures often works well and has little gotchas.
In general, I think a lot of people hopped onto the XML bandwagon assuming that it would always sanely translate back and forth between XML and native data structures. This is not the case. When XML is the (cough) "best" format, the underlying data structures of different programs operating on the XML will look extremely different. Furthermore, XML terminology will end up leaking into business logic, because the semantics of the document are inseparable from handling it.
In general, I think the biggest sign that XML is the wrong choice is when someone's using a "magic" serializer, or when the data structures very closely follow the document structure. In those cases, JSON was probably a better choice.
See also Erik Naggum's legendary rant: https://www.schnada.de/grapt/eriknaggum-xmlrant.html
For the purpose of authoring comments on Hacker News (HN), I for one am grateful= that HN doesn't make us type out HTML. I also doubt very much that HN stores our comments in a different representation (e.g. HTML) than the one they were authored in.
The other problem is that HN comments and all those markdown-like formats are very ad hoc. If I copy/paste my reddit comments on HN, or the other way around, it won't always work as expected. In both cases, it has to be translated to HTML to be displayed by the browser, too.
So, the context would be: an export format for complex, multi-paragraphs textual documents with meta-information.
If you add the condition that it be human-readable, I admit I am not able to point to an existing format that is obviously better suited for this than XML.
A well reasoned XML instance can replace HTML for most things from presentation, accessibility, interaction, content negotiation, and so forth. You can apply JavaScript and CSS immediately to an XML instance. You don't get any of that capability with JSON, YAML, or anything similar.
I really think the people who hate XML the most are those are those who lack the imagination to move beyond raw data and query relationships. I agree XML isn't good at this, which is why it completely offloads that capability to a sibling technology: DOM.
I have also never seen anybody with a comfortable understanding of the DOM believe JSON, YAML, and the like fill that void, but then these other technologies do not primarily exist to structure human consumable content directly for human consumption. The most important part of the article you linked to describes markup relevance as a percentage of syntax overhead. The more the described content becomes an extraction of computer oriented data the more that percentage goes up thus making XML progressively a bad decision, but the opposite is also true.
The article really nails its bias in this regard by fixating on data as a facet opposed to information as a structure. When the goal is to provide primarily a structure, as opposed to fundamentally offering a syntax, the cost to scale grows inversely to the quantity of content provided. That is largely thanks to lexical scope, which allows a richer interpretation of context without any additional or specified syntax. That is the nature of information versus data. Conversely, data conveyance schemes that exist to primarily offer a syntax scale proportionally to the content provided because the ratio of syntax to content is static without any additional meaning.
For some clarity on the difference between data, information, and knowledge I suggest the DIKW model: https://en.wikipedia.org/wiki/DIKW_pyramid
It was so easy to understand that every person who was able to use a computer would pick it up quickly. This was not the case for HTML, my guess is because there are a ton of HTML tags and that can be overwhelming for a certain type of audience, whereas here there are at most 10 tags to learn.
The framework I'm talking about still exist, it's called XIMPEL [1] (sadly SMIL kind of died). It may seem like a weird thing, but IMO it's the only open-source framework that has an intuitive way to make non-linear storytelling easy on the web easy. People can kind of hack a choose your own adventure media story with YouTube, but XIMPEL really is so much better at it because it's actually made for that purpose. And the biggest reason why XIMPEL is simpel because it uses XML as its template language.
People just see the tags as lego blocks and build non-linear media essays, stories or even small (media-focused) games with it.
[1] http://www.ximpel.net/
I find this hard to believe. I know many people who use computers but are not IT professionals or even hobbyists. Without an easy to use GUI they can't accomplish much. I couldn't imagine them picking up anything to do with XML.
If you scope it down to UI developers you're taking less than 1% of people. Far from everyone. Even if you scope it down to IT people it's less than 1% of people.
I’ve been told that clerks at bell labs were using troff because they were told they weren’t programming and I think GUIs have the same opposite effect.
Take for instance insane Excel spreadsheets glued with VBA powering entire businesses, built by accountants and other professionals.
Why not allow authors to define their own names? Like
Then internal functionality can be attached to each element via attributes, like how aria roles work.https://html.spec.whatwg.org/multipage/custom-elements.html#...
https://github.com/w3c/webcomponents/
https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
I wrote this code in another comment, but imagine if you could hook functionality to an element via defined attributes. With custom elements, you have to add the functionality via a script, and they aren't system functions (from what I can remember, I may be wrong).
In the above code:- the LabelList element hooks into the systems "list" behavior
- the LabelItem element hooks into the systems "label" behavior
- the LabelItem element hooks into the systems "listItem" behavior
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?
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
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.
YAML is all sorts of strange.
JSON needs comments and support for trailing commas. Since that isn't going to happen.... TOML!
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.
JSON is a tree structure. It is dictionaries and arrays mixed together in a hierarchy.
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.
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.
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.
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.
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.
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.
- 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.
https://developer.mozilla.org/en-US/docs/Tools/3D_View
Whether it is JSON or XML, what I particularly like about both approaches is that both are fundamentally HATEOAS (https://en.wikipedia.org/wiki/HATEOAS)
Just try to write the JSON equivalent of:
If your document consists mainly in losely structured text with some annotation, you better use XML.I think I prefer the XML :-)
Edit: I agree that tagged text is a clear win for XML - for pretty much everything else I'd go for JSON.
Edit2: HN ate my formatting, but probably not a bad thing ;-)
edit: though it again gets confusing when the 0 index is sometimes the element type and sometimes the straight text... so never mind I guess the problem persists.
[ "div", "The ", [ "a", { "href": "https://www.json.org/" }, "JSON format" ], " was invented by ", [ "em", "Douglas Crockford" ], "." ]
First thing in array is element, if there is an object at the second location then that's the attributes?
1: https://holmsand.github.io/reagent/
2: https://github.com/Day8/re-frame
3: https://github.com/edn-format/edn
4: https://github.com/weavejester/hiccup
If the second argument is an object/dictionary, it's attributes. Otherwise, it's the first child. Alternatively, the ambiguity can be resolved by using null/0 instead of empty attributes.
R uses markdown + a separate file with the output cached and while the non-rendered file is easier to version the whole thing is a lot more difficult to handle.
["div", 0, "The ", ["a", {"href": "https://www.json.org/"}, "JSON format"], " was invented by ", ["em", 0, "Douglas Crockford"], "."]
Just imagining a JSON that starts with
"dummy": "don't remove this or the API will mis-align this across two structs!!!"
B. Your dangling whitespace characters are all wrong.
This tells me that the steps you took to craft the serialized version of the data were totally disconnected from the intent of the transmission.
You were more focused on syntax (decorative array brackets, and curly brace closures), than the human-readable aspects of the text.
More often than not, this is expressed as unclosed tags in XML mark up, which would express as run-on underlined link activation and bold face. Yet this is often cleaner, when formatting gets stripped out, preserving whitespace delimiters such that text us ungarbled.
In the source, this sometimes leads to excessive whitespace bloat, but luxuriously so.
1. The xml denotes that the whole thing should be wrapped in a div, and shouldn't just be considered a paragraph. With only lists you can't denote what kind of level you're at, unless you force each level to always carry the same meaning (which makes the format weaker than XML).
2. Setting "bold" to true isn't the same thing as emphasizing the text. Typically 'em' is italic, but more importantly a nested 'em' should no longer be italic. To achieve this with JSON you're forced to combine formatting and structure in a way that CSS was designed to prevent.
Upd: The three kinds of data: the string, the structures (div, a, em), and their position in the string.
We need more articles like this, to remember us that we should consider what's best for the task at hand and not what's trendy.
My sniff test is that if you're editing it by hand, JSON is a poor format because you'll want the benefit of a schema or at least a user-friendly format. If you're not, the syntax doesn't really matter so we should evaluate it on technical merits (verbosity, computational complexity for serialization/deserialization, memory footprint, etc).
I use:
- config file formats for config files (usually TOML or INI format) - data formats for data (JSON, protocol buffers, etc) - markup formats (Markdown, XML/HTML) or code for markup
I really don't get why people try to force all use cases onto the same format. Use whatever is well suited for the task, preferring familiarity over unnecessary technical benefits.
> However, we’ve created another problem in the form of inconsistency: some user properties are represented as element attributes, others as child elements.
Exactly. I’ve seen XML with element attributes and child elements all over the pace. No rhyme or reason for any of it. It’s especially bad in older systems.
I pushed hard at my last job for the SOA team to build REST/JSON web services. Oracle sold them a product to bridge the gap and they got End Of Life announcements 6 months later! Glad I’m gone.
> XML, on the other hand, optimizes for document tree structures, by cleanly separating node data (attributes) from child data (elements).
Unfortunately, there appear to be some implementation issues here. You have to create a string version of your data to store them in attributes.
So, you lose a bit of context in the conversion.
Such as:
`<Document text="true" />`
Is the text attribute the word _true_ or a boolean _true_. Without referencing some other piece of code or definition there is no way to know.
Whereas in JSON, this wouldn't be necessary, as you can simply remove the quotes and infer that it is not a string, but a boolean.
See this link on stack exchange[1].
[1] https://stackoverflow.com/questions/17604071/parse-xml-using...
> //Gets Street name xmlDoc.getElementsByTagName("street")[0].childNodes[0].nodeValue;
I’d much prefer something like jsonObj.address[0].street;. Personally I like to work with objects over parsing documents trees.
When you are hacking systems together for large/old enterprises the water gets muddy fast.
Technically, there are REST/JSON equivalents, but I don't see them actually used much in the wild - so much of the time with REST APIs you are stuck with whatever half-baked, out-of-date documentation that somebody may or may not have written, or just randomly poking at it through trial and error to discover how it works.
Sometimes even getting a sample of the expected JSON format can be hard. If you’re not versioning you’re APIs you can break everything if the schema changes.
I used to debate this with the SOA manager. Swagger looks ok but never dealt with it in production or saw it in the wild with our customers.
I guess XML might be perfect for when you can't decide between singular and plural and want to leave the problem to others...
Because that's the biggest problem besides charset encoding that JSON helps solving: in JSON, you can be unmistakably clear that a given property is to be interpreted as a list of values, even when the current number is less than two. In XML you can just vaguely communicate that intent with an intermediary "plural element" unless you go full schema.
isn't half as clear as (attributes unrelated to this difference omitted)It's actually amazing to me how many of Flex's great ideas live on in other frameworks not dependent on the Flash Player, and looking at some modern day React often reminds me if it.
[1] http://flex.apache.org/doc-getstarted.html
Same for Compose/Kotlin