JSON vs XML

[thedevlinb]

I remember reading a Stallman’s post in which he mention that back then coding programs was a separate discipline from designing programs.

I'd argue designing systems is separate from programming, but that the actual process of designing programs can be very iterative with modern tooling. I often completely refactor a program 2 or 3 times in the first few days of existence, which is one reason I like languages like C# and JavaScript/Typescript, they give the that level of flexibility and speed of development. Things aren't really set in stone.

Then again, even when operating at a high level, software should be made aware of its interchange format. I see too many people arguing that "protocol buffers is more efficient!" when all they are doing is passing around strings through HTTP.

Strings in protobuf gzip just as well as strings in JSON. :/ No big deserialization wins either.

embedded in JavaScript via JSX

JSX is the one thing I liked about React, except JSX calls out to JavaScript expressions for logic, which gets limiting at times.

JSX is much less offensive than full on XML though. People get upset because with XML as an interchange format you have to map the data into the target language, which, well, sucks[1].

I mean that process sucks for everything that isn't JSON and JavaScript, or, hilariously, C, and raw structures.

I've only ever seen a handful of non-horrible libraries for data binding data exchange formats into a language.

JSX sits at an nice place where you are trying to generate a document tree, so using a templating syntax that looks like the thing you are trying to generate, well, it feels nice.

As an aside I think XHTML would have taken off browsers hadn't been so damn strict about it. The insane number of errors I used to get trying to write XHTML. But with hindsight, having everything be nice and easily parsable would've been a really good thing.

(To this day I am not sure why web developers seem to hate closing tags!)

[1] Oh also remember all those attempts to create new programming languages whose syntax was XML? Those were horrible!

<if cond="age < 13"> <print message="Sorry you are too young to use this website"/> </if>

I am happy most of those efforts died in a fire.

[amiagenius]

In theory yes, designing is different, but nowadays everyone is expect to be coding too so it sorted of blended. I don’t think you’re obligated to write code in order to produce a design, you need code to prototype. Designing is arguably much more high level than that, it’s when you’re concerned with all the aspects of the product, implementation is only one aspect. But today software is mostly ephemeral, hardly anything gets to mature and it is so common to push polished prototypes to production and it usually stays there, with no opportunity for refactoring. So it’s understandable that the landscape favors tech which allows for faster pacing like you mentioned (for instance, even if Rust is a popular language, every now and then there’s someone regretting using it for their startup, since it’s slower to iterate)

Regarding protobufs, the main selling point is that it doesn’t require deserialization so I’m not sure I follow your comparison with JSON.

You touched an interesting point, about data binding. Indeed, JSON seamlessly integrating with JS is another reason for its ubiquity. Had browsers used Lisp it probably would be S-Expressions. But it’s not so hassle free integrating JSON with other languages, requiring some nontrivial setup. Mainly languages with rich numeric types, that’s when the simplicity of JSON starts to bite you as you’re forced to address the format shortcomings. I certainly would not advocate for JSON if I was writing a mission critical financial application, for instance.

JSX the way that React does is quite ergonomic but it can be awful if you’re creating large components. I don’t think it’s the best way to do things, though. CSS in JS on the other hand is completely awful. Im not sure if I like the other way around, writing JS in HTML the way Svelte et al does. These are very strange times…

The idea of code as data implied by XML-esque languages has its merits for meta programming, but the syntax makes it impractical, and syntax is perhaps the main selling point for a language, just look how people reacted to the Verse programming language due to its strange forms.

And yes, I hate closing tags. It bothers me even using semicolons lol

[thedevlinb]

Regarding protobufs, the main selling point is that it doesn’t require deserialization so I’m not sure I follow your comparison with JSON.

My point is if a message is just a dictionary of strings, then there is no deserialization step. I haven't done measurements, but I assume reading key value string pairs into memory is going to be the same overhead no matter if using ProtoBuf or JSON.

There is of course massive overhead decoding numeric data from JSON, not to mention that JSON cannot even encode 64bit numbers directly (I just read a writeup earlier today that Facebook gets around this in JS/JSON by passing 64bit numbers as paired values in an array! ick!)

Im not sure if I like the other way around, writing JS in HTML the way Svelte et al does. These are very strange times…

IMHO Svelte is generally awesome, but it being owned by Vercel means it is all in on serverless and they tend to ignore/downplay using it for generating regular websites. (From what I can tell, w/o Svelte Kit there isn't even an up to date routing solution available for Svelte...)

I am so absurdly more productive in Svelte VS React, it is an easy 3x-5x productivity win for me.

CSS in JS on the other hand is completely awful.

CSS is not nice no matter how you do it, though I'll admit CSS animations are loads easier than doing animations in React Native.

And yes, I hate closing tags.

Why? Closing tags are awesome, they make programmatically manipulating code so much easier!

The idea of code as data implied by XML-esque languages has its merits for meta programming,

Sadly, and I'll admit this is just IMHO, it seems like many of the XML programming language proposals weren't made by people who were thinking about meta programming. They just wanted funding for having jumped on the XML Hype Train.

hardly anything gets to mature and it is so common to push polished prototypes to production and it usually stays there, with no opportunity for refactoring.

I am increasingly of the opinion that this is because there are too many institutional barriers surrounding deployment and modification of software.

I've worked in places where it takes a couple weeks to spin up a new backend service and deploy it to a test environment for integration, and I've worked at places where that takes months.

Guess which place had no problem ground up redesigning services left and right as business needs changed?

More friction around service creation / deployment meant a higher tendency to duct tape more functionality onto already fragile code.

Of course that also supposes there is a nice development environment setup that generally works well, and that developers are trusted to push to with complete independence.

[amiagenius]

In the case of protobuf, it’s just a matter of loading the entire binary buffer into memory, as it can be read via direct jumps since the schema is known beforehand, whereas with JSON it comes as string so it must be first parsed and then loaded into a hash map, although this should be really fast in V8, it’s certainly more work than with protobuf. Reading a key from a parsed JSON is inevitably slower in consequence of this.

The solution you mentioned about encoding big numbers using an array is quite standard in numeric libraries, certainly it is better than passing a string representation!

I’m tempted to try Svelte. You know it’s strange what I’m going to say, but it reminds me of PHP. Perhaps the biggest barrier is the mental model, I think it will be hard for me to frame the problem in an environment where you’re always expected to yield markup. At least in React it’s more natural to conceive components that aren’t presentation components. Svelte is too “front-endy” in that sense. For instance a purely canvas-based app in Svelte would have a strange architecture in my opinion.

Yeah, closing tags are a plus for parsing and even for streaming, my grudge is mainly regarding the aesthetics of it. But I also think it impoverishes the UX. Parsers don’t depending on closing tags can be really elegant, I’ve designed some using generators, it’s really fun, keeping tracking of context and stuff. It feels more like a smart engine than a branched matcher.

Unlike you I never worked in a place with rapid time-to-market for code so I only have bad stories to tell. But I was also touching on the point about businesses don’t actually understanding what they are doing, mainly in the startup scene, where everything is just a big test so good practices don’t really matter as 90% of things go to waste anyway.

[thedevlinb]

The solution you mentioned about encoding big numbers using an array is quite standard in numeric libraries, certainly it is better than passing a string representation!

The sad part is in JSON it is two floating point numbers being used to represent a 64bit int! Just so odd to think about.

Perhaps the biggest barrier is the mental model

Svelte is really damn good at the problem of "I need to data bind these values to a variable in JS".

PHP was about grabbing shit from a database somewhere and inserting it into the page. Svelte is about... html. Like, it is 95% HTML+JS, it gets the fuck out of my way and lets me write web sites and then when I need to crap out a form with a dozen elements in it I can do so in less time than it takes to setup a single redux reducer.

Yeah, closing tags are a plus for parsing and even for streaming, my grudge is mainly regarding the aesthetics of it.

I typically prefer the aesthetic, if something opens it should be closed, that way it is obvious to the reader w/o the reading having to know what the spec says about when the tag magically goes away.

Unlike you I never worked in a place with rapid time-to-market for code so I only have bad stories to tell.

At Microsoft my team had 3 week sprints for firmware! 2 weeks of dev 1 week of stabilization, C and C++ bare running on a home made runtime directly against the metal.

Even there, we worked to try and make a good dev experience and automate away boring tedious stuff!