Hey senior programmer out there. Please give one good reason to continue using JSON.

(When i'm dealing with AJAX, i insert a specific symbol in the string returned by the server and later on the front end , i just split that string to separate my data.

And JSON has become useless to me since

I learned the other day that the X in AJAX means XML. So does that mean we should be called AJAX that used JSON, AJAJ? In your case you are using a custom format for your data. Would it be AJAC? Or AJACSV?

Sure.. What about data that contains that symbol you are using as a delimiter?

What about 400kb payloads? And readability/debugging?

What about reducing your dataset [columns]?

It's a well documented standard.

Easy to state both property names and values.

Easy to declare arrays of objects.

Easy to turn into JavaScript objects.

Good support in many languages.

Easy to store in a NoSQL database.

Less verbose than other options such as XML.

Used in many useful APIs.

1) it's not ridiculous like what you're doing.
2) it supports nesting; your approach does not.
28) encoding issues
29) escaping issues
57) browsers can parse json data so you can i
get actual numbers and arrays and hash maps instead of only strings.

@Root 🤣🤣🤣 it's not ridiculous what i'm doing though

@Afrographics mhm.

@Root it's was for my chat application

And I needed to return many separated data

Not coming from the same source.

JSON is a well understood, conventional, structured, reasonably efficient standard with wide ranging support in many libraries or languages. It's not perfect, but it's often a reasonable option. Certainly better than rolling your own weird protocol.

If you're just coding something as a hobby, sure, do what you like. If you tried to pull that crap on me in a code review in a corporate setting however, you'd be sent back to rewrite.

🧐technically you could send binary blobs back and forth, but "standards" are a thing for a reason, not only are you adding something that could potentially break by user input, your making someone's life miserable if that codebase is ever shared.

Another way of looking at this is:
Do you drive a car in reverse down the freeway? Why not? There's nothing stopping you.

The problem is not that you're not using json, it's that's you're manually serializing payloads.

All depends on how complicated data structures you use and need, but don’t over engineer something that is stupidly simple and every boot camp self called developer can do.

@SortOfTested i don't understand

@Afrographics
Json is just one of many formats used as a canonical protocol for web services. There's also xml, soap xml, xml-rpc, gRPC, etc.

Users generally have an expectation that some understandable form of data returns from a service, indicated by it's contract, and that expectation is based on what their side of the pipe features implicit deserialization support for. They also expect that the Accept header can be passed to communicate how they expect the response to be formatted. If the accept header features an encoding that is not supported on the service, the receiver expects to see a 415 status code. The content-type header functions similarly to communicate the data serialization strategy utilized in the body on either request or response.

Sending back a random string is fine, and can be your protocol, but it will mean you or your users have to reinvent handlers and expose them in your code rather than leveraging standard data schemas and out of the box optimized serialization support. You also won't be able to feature metadata people understand, or be able to leverage automated client generation, and pretty much every other advantage of 40 years of other people's work you could leverage from go.

https://en.m.wikipedia.org/wiki/...

@molaram so what are the cases and how do you measure latency, bandwidth and parsing speed.

Yeah there are plenty of formats starting from more popular like thrift, protobuf, msgpack, yaml, bson ending on less popular ones or sticked to one language like kryo, yami, pickle but there is never a win win situation cause you need to either sacrifice latency, bandwidth or the cpu.

You always need to chose something from that.

If you’re at this point you’re either developing high grade enterprise software and don’t ask stupid questions or just over engineering because you’re stupid dickhead who knows better.

One word: Injection.

- Because you don’t know how your communication format will evolve and what you will do with the data you collect. Stick with a solution that works.
- 2 years from now, some poor junior will have to maintain this piece of crap. Are you sure he is capable of not fucking up parsing and escaping?