"We have libraries for these technologies" is a poor substitute for "These technologies don't really solve the problems that need to be solved."

The nice thing about the old internet protocols is that they tried to distinguish between abstraction and implementation layers. (Not always successfully or effectively, but they did at least try.)

Modern protocol designs seem to do the opposite. They start from a default implementation layer - usually REST, HTTP, and JSON - and then try to build the abstraction layer out of that.

This isn't necessarily a good approach. But it is a reflection of the difference in culture - the change from hackers who were comfortable with open-ended bottom-up development, and modern developers who seem to prefer snap-together development using standard libraries.

> They start from a default implementation layer - usually REST, HTTP, and JSON - and then try to build the abstraction layer out of that.

Also known as the Unix philosophy ;-)

This isn't about comfort, but about doing what needs to be done.

Every webmail interface in existence has implemented their own half baked, proprietary protocol that does what JMAP is doing. Or do you think Google's Gmail web interface is using IMAP?

---

> "hackers who were comfortable with open-ended bottom-up development"

That's because they lacked basic tools. Hackers in those days weren't getting much work done either.

> That's because they lacked basic tools. Hackers in those days weren't getting much work done either.

Wat.

I grew up with ZX Spectrum, MS-DOS, Windows 3.x, started programming in secondary school and while in high school watched as the Internet took over the world.

I was one of those hackers ;-)

Well if you're really going to go down that route, you should remember that the "unix philosophy" favours plain text as the data-passing mechanism. JSON itself does not have rules for how things like malformed UTF8 decoding should work, which means that every implementation of this JMAP protocol is going to need to refer to a specific JSON spec for starters, which is already destroying the credibility of the "simple" argument. Also, I don't see how your claims about hackers "in those days" has any basis other than speculation here.

> every programming language in existence has easy to use HTTP and JSON parsing libraries

That argument doesn't hold much water. Every programming language in existence also has easy to use socket libraries. Are you implying that HTTP and JSON are less error-prone than whatever-over-TCP? There's nothing magical about either HTTP or JSON that makes them the right tool for every job. But I guess when all you have is a hammer ...

I would be willing to put a lot of money that the same application built on HTTP/JSON will be much much less error prone than the same app built on TCP sockets.

The tooling is better; debugging is easier; the interfaces are less finnicky; the transfer is less brittle; dealing with objects and documents is much easier conceptually than streams; very powerful performance optimizations and catching can just be turned on while being transparent to the app; crappy networking equipment won't ruin your day; corporate firewalls won't get in your way; encryption is basically drop-in with transparent tooling support.

In no way is HTTP/JSON the best protocol for every situation but thinking you can do better with something home grown on top of TCP is ignoring all the human effort that's gone into solving the problems with straight-tcp protocols. So yes any protocol that's had as much love put into it would probably be just as good but few things have.