xml: the bad parts

Excellent transcribed interview with Douglas Crockford from the  Corecursive Podcast.

I first heard about Crockford in the early Atari 8 Bit computer scene, especially his lovely physics-and-sound software toy Jane's Program. Later he achieved fame with JavaScript: The Good Parts and for championing JSON which indeed supplanted XML.    

Here's what he says about it:

 So there is an intellectual trap in XML, that it's really complicated. It doesn't look like it should be complicated. It's just angle brackets, but the semantics of XML can be really complicated, and they assumed it was complicated for a reason. This problem of data interchange is so complex that there's a conservation of complexity, that your format has to be complex, and the tools supporting that format have to be complex, so that the applications are manageable. And that's a false assumption, there is no such thing as conservation of complexity.

That generally, if you push on simplicity anywhere, you can get it everywhere eventually. So simplicity is the thing you should be driving, not complexity, but they didn't know that. And I think if you have bought into that, you have emotional connection now to this format, and you've been telling people that it's complicated for a reason, and it's good that it's complicated. And then this little piece of syntactic fluff shows up, which is solving the same problems without any complexity at all. You look stupid. And also, you have invested a lot of time and energy into learning this thing, which turns out is becoming irrelevant. And that's a tough thing. And if you're a consultant, it's even harder, because you've established a standing in the community that you have clients because this stuff and this stuff is no longer the thing. And so, a lot of them took this really, really hard.

My unpopular opinion is this: TypeScript has a lot of the same disadvantages as XML, and for similar reasons. Both are an attempt to make data formats more rigid and specified, and both lack the syntactic elegance of their competition (Plain old JS and JSON, respectively.) 

Despite needing a guide to avoiding the bad parts of JavaScript, Crockford realized there's a power there that even mighty Java lacked - first class function, just as one example! (And I would say modern ECMAscript has really made it easy to move away from most of the pitfalls, with properly scoped variables, rarely any need to use "this", etc.) People who aren't comfortable with duck type languages love mocking the edge cases but honestly most of the examples are really contrived.

Interestingly, he doesn't mention TypeScript as the new XML, but rather JS frameworks in general. Here's what he says in favor of plain Vanilla JS (at least these days)

Adam: What do you think is the XML of today?

Douglas: I don't know. It's probably the JavaScript frameworks.

They have gotten so big and so weird. People seem to love them. I don't understand why.

For a long time I was a big advocate of using some kind of JavaScript library, because the browsers were so unreliable, and the web interfaces were so incompetent, and make someone else do that work for you. But since then, the browsers have actually gotten pretty good. The web standards thing have finally worked, and the web API is stable pretty much. Some of it's still pretty stupid, but it works and it's reliable.

And so, when I'm writing interactive stuff in browsers now, I'm just using plain old JavaScript. I'm not using any kind of library, and it's working for me.

And I think it could work for everybody.

(That said - I DO like React, but you actually don't need that to do declarative programming - with template strings even JSX loses some of its specialness! I mean I wouldn't want to do a whole SPA in Vanilla, but if you have some technology that's more about SSR than pushing everything to client, it's not such a bad world.)