3 ms·

Compressed JSON is good enough and requires less human communication initially. Sure it will blow up in your face when a field goes missing or value changes ty

Compressed JSON is good enough and requires less human communication initially. Sure it will blow up in your face when a field goes missing or value changes type. People who advocate paying the higher cost ahead of time to perfectly type the entire data structure AND propose a process to do perform version updates to sync client/server are going to lose most of the time. The zero cost of starting with JSON is too compelling even if it has a higher total cost due to production bugs later on. When judging which alternative will succeed, lower perceived human cost beats lower machine cost every time. This is why JSON is never going away, until it gets replaced with something with even lower human communication cost.

deleted 10mo ago
[deleted]
esafak 10mo ago
It won't go away in the same way COBOL won't. That does not mean we should be using it everywhere for greenfield projects.
DyslexicAtheist 10mo ago
> People who advocate paying the higher cost ahead of time to perfectly type the entire data structure AND propose a process to do perform version updates to sync client/server are going to lose most of the time. that's true. But people also rather argue about security vulnerabilities than getting it right from the get-go. Why spend an extra 15 mins effort during design when you can spend 3 months revisiting the ensuing problem later.
- jstanley 10mo ago
  Alternatively: why spend an extra 15 mins on protobuf every other day, when you can put off the 3-month JSON-revisiting project forever?
  - OccamsMirror 10mo ago
    I use ConnectRPC (proto). I definitely do not spend any extra time. In fact the generated types for my backend and frontend saves me time.
morshu9001 10mo ago
I've gone the all-JSON route many times, and pretty soon it starts getting annoying enough that I lament not using protos. I'm actually against static types in languages, but the API is one place they really matter (the other is the DB). Google made some unforced mistakes on proto usability/popularity though.
- almosthere 10mo ago
  why are you against static types in languages? I once converted a fairly large JS codebase to TS and I found about 200 mismatching names/properties all over the place. Tons of properties we had nulls suddenly started getting values.
  - MobiusHorizons 10mo ago
    Sounds like this introduced behavior changes. How did you evaluate if the new behavior was desirable or not? I’ve definitely run into cases where the missing fields were load bearing in ways the types would not suggest, so I never take it for granted that type error in prod code = bug
    - sevensor 10mo ago
      The most terrifying systems to maintain are the ones that work accidentally. If what you describe is actually desired behavior, I hope you have good tests! For my part, I’ll take types that prevent load-bearing absences from arising in the first place, because that sounds like a nightmare. Although, an esoteric language defined in terms of negative space might be interesting. A completely empty source file implements “hello world” because you didn’t write a main function. All integers are incremented for every statement that doesn’t include them. Your only variables are the ones you don’t declare. That kind of thing.
    - almosthere 10mo ago
      it was desirable because our reason for the conversion was subtle bugs all over the place where data was disappearing.
barremian 10mo ago
> When judging which alternative will succeed, lower perceived human cost beats lower machine cost every time. Yup this is it. No architect considers using protos unless there is an explicit need for it. And the explicit need is most times using gRPC. Unless the alternative allows for zero cost startup and debugging by just doing `console.log()`, they won't replace JSON any time soon. Edit: Just for context, I'm not the author. I found the article interesting and wanted to share.
- duped 10mo ago
  Print debugging is fine and all but I find that it pays massive dividends to learn how to use a debugger and actually inspect the values in scope rather than guessing which are worth printing. It also is useless when you need to debug a currently running system and can't change the code. And since you need to translate it anyway, there's not much benefit in my mind to using something like msgpack which is more compact and self describing, you just need a decoder to convert to json when you display it.
  - themafia 10mo ago
    > rather than guessing I'm not guessing. I'm using my knowledge of the program and the error together to decide what to print. I never find the process laborious and I almost always get the right set of variables in the first debug run. The only time I use a debugger is when working on someone else's code.
    - duped 10mo ago
      That's just an educated guess. You can also do it with a debugger.
      - mekoka 10mo ago
        The debugger is fine, but it's not the key to unlock some secret skill level that you make it out to be. https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/ https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/
theshrike79 10mo ago
Also: debugging You (a human) can just open a JSON request or response and read what's in it. With protobuf you need to build or use tooling that can see what's going on.
- generativenoise 10mo ago
  It is only "human readable" since our tooling is so bad and the lowest common denominator tooling we have can dump out a sequence of bytes as ascii/utf-8 text somewhat reliably. One can imagine a world where the lowest common denominator format being a richer structured binary format where every system has tooling to work with it out of the box and that would be considered human readable.

deleted 10mo ago

[deleted]

esafak 10mo ago

It won't go away in the same way COBOL won't. That does not mean we should be using it everywhere for greenfield projects.

DyslexicAtheist 10mo ago

> People who advocate paying the higher cost ahead of time to perfectly type the entire data structure AND propose a process to do perform version updates to sync client/server are going to lose most of the time. that's true. But people also rather argue about security vulnerabilities than getting it right from the get-go. Why spend an extra 15 mins effort during design when you can spend 3 months revisiting the ensuing problem later.

jstanley 10mo ago
Alternatively: why spend an extra 15 mins on protobuf every other day, when you can put off the 3-month JSON-revisiting project forever?
- OccamsMirror 10mo ago
  I use ConnectRPC (proto). I definitely do not spend any extra time. In fact the generated types for my backend and frontend saves me time.

morshu9001 10mo ago

I've gone the all-JSON route many times, and pretty soon it starts getting annoying enough that I lament not using protos. I'm actually against static types in languages, but the API is one place they really matter (the other is the DB). Google made some unforced mistakes on proto usability/popularity though.

almosthere 10mo ago
why are you against static types in languages? I once converted a fairly large JS codebase to TS and I found about 200 mismatching names/properties all over the place. Tons of properties we had nulls suddenly started getting values.
- MobiusHorizons 10mo ago
  Sounds like this introduced behavior changes. How did you evaluate if the new behavior was desirable or not? I’ve definitely run into cases where the missing fields were load bearing in ways the types would not suggest, so I never take it for granted that type error in prod code = bug
  - sevensor 10mo ago
    The most terrifying systems to maintain are the ones that work accidentally. If what you describe is actually desired behavior, I hope you have good tests! For my part, I’ll take types that prevent load-bearing absences from arising in the first place, because that sounds like a nightmare. Although, an esoteric language defined in terms of negative space might be interesting. A completely empty source file implements “hello world” because you didn’t write a main function. All integers are incremented for every statement that doesn’t include them. Your only variables are the ones you don’t declare. That kind of thing.
  - almosthere 10mo ago
    it was desirable because our reason for the conversion was subtle bugs all over the place where data was disappearing.

barremian 10mo ago

> When judging which alternative will succeed, lower perceived human cost beats lower machine cost every time. Yup this is it. No architect considers using protos unless there is an explicit need for it. And the explicit need is most times using gRPC. Unless the alternative allows for zero cost startup and debugging by just doing `console.log()`, they won't replace JSON any time soon. Edit: Just for context, I'm not the author. I found the article interesting and wanted to share.

duped 10mo ago
Print debugging is fine and all but I find that it pays massive dividends to learn how to use a debugger and actually inspect the values in scope rather than guessing which are worth printing. It also is useless when you need to debug a currently running system and can't change the code. And since you need to translate it anyway, there's not much benefit in my mind to using something like msgpack which is more compact and self describing, you just need a decoder to convert to json when you display it.
- themafia 10mo ago
  > rather than guessing I'm not guessing. I'm using my knowledge of the program and the error together to decide what to print. I never find the process laborious and I almost always get the right set of variables in the first debug run. The only time I use a debugger is when working on someone else's code.
  - duped 10mo ago
    That's just an educated guess. You can also do it with a debugger.
    - mekoka 10mo ago
      The debugger is fine, but it's not the key to unlock some secret skill level that you make it out to be. https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/ https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/

theshrike79 10mo ago

Also: debugging You (a human) can just open a JSON request or response and read what's in it. With protobuf you need to build or use tooling that can see what's going on.

generativenoise 10mo ago
It is only "human readable" since our tooling is so bad and the lowest common denominator tooling we have can dump out a sequence of bytes as ascii/utf-8 text somewhat reliably. One can imagine a world where the lowest common denominator format being a richer structured binary format where every system has tooling to work with it out of the box and that would be considered human readable.