4 ms·

My problem with this article is not the general sentiment that developers should know the history of the technologies they work with, which I think is absolutel

My problem with this article is not the general sentiment that developers should know the history of the technologies they work with, which I think is absolutely right, but instead how the author seems to put HTTP on a pedestal. It just happens to be the protocol TBL & company came up with in the early 90s for this thing that took off beyond anyone's wildest imagination. It's not some perfect work of art that should be revered. Also native apps don't make me sad. They're faster, more featureful, and have more consistent platform specific interfaces than their Web brethren. There are good reasons they exist and consumers prefer them.

Guthur 12y ago
I am guess that the apps referred to are the ones which have existed quite happily as a web page before moving to smart phones where for more likely business rather that user experience reasons they became apps. The ones I can think of are Twitter, Facebook, and LinkedIn. I am certainly not a proponent of web as a platform for everything but there are certainly some things it is rather good at, and making content discoverable in a consistent manner is one of those. If you hid the content in an app it's rarely exposed.
- TheOtherHobbes 12y ago
  This debate has been going since the days of AOL and CompuServe. As here, it usually misses the differences between public content, private content, and corporately farmed content. Twitter etc are corporately farmed content, and they all provide web and app access. The access method is just a front end. Personal content in apps isn't usually all that interesting. It's hard to think why anyone would care about my Angry Birds scores, or what level I'm on in Candy Crush. (If I played Candy Crush, which I don't.) If you want to make an app that shares content on the web, it's not difficult. I don't see a problem with the fact that it's extra effort, and if you're going to do it you need to justify that effort in some way.
yawboakye 12y ago
Agreed. Apps didn't break HTTP. They consume APIs (which can also be used by web applications). Thus, designing the API is what really matters.
curun1r 12y ago
This whole discussion reminds me of discussions about language evolution. Some people are prescriptivists and believe that learned language experts should determine what is and isn't correct usage. Others are descriptivists, arguing that languages are a living reflection of how they're used and that incorrect usage can become correct if and when it becomes widespread. Similarly, we have standards boards, who are often very divorced from the realities of actually building real-world software and we also have the engineers building real-world software. Which version of HTTP is correct, the one codified by the W3C or the version codified by the engineers building Chrome, Firefox, IE, Apache and Nginx? As a learning exercise, I implemented an HTTP server a few years ago and remember finding it fascinating that none of the popular user agents implemented the Keep-Alive header per the specification. And yet they all implemented it in a common, non-compliant manner. It made me realize that as much as I was using the spec as my guide, my implementation wouldn't be correct if I followed what it said for that header.
- dtech 12y ago
  There is a major difference between the two: computers are dumb. As a human, I can usually communicate with someone who uses a dialect or makes language errors. Computers are much worse at doing that, they basically need to know about every standard and non-standard behavior to correctly handle it. As such there is a very good reason for standards and thus standard bodies to exist.
- Morgawr 12y ago
  >Which version of HTTP is correct, the one codified by the W3C or the version codified by the engineers building Chrome, Firefox, IE, Apache and Nginx? There is a reason why protocols are not languages. A protocol is a well-defined standard that engineers are supposed to follow. There really is no space for "descriptivists" in technology and especially in standardized protocols. What is that, the protocol is useless? Well, maybe we should come up with a new standardized one instead of bastardizing the already-existing one and creating a lot of confusion and ambiguity (which machines have a hard time to deal with).
  - cpeterso 12y ago
danellis 12y ago
HTTP is different, though. Developers are constantly creating thousands of HTTP services. What other Internet protocol can you say that about? Protocols like DNS, FTP, NNTP etc tend to be provided by a small number of fixed services. Once in a while there will be a framework for a non-HTTP protocol, like Zed Shaw's Lamson SMTP server, but that's uncommon and I doubt it's widely used. I can't think of any other protocol where even the most unskilled developer is given the tools and encouraged to determine how the protocol is used.

Guthur 12y ago

I am guess that the apps referred to are the ones which have existed quite happily as a web page before moving to smart phones where for more likely business rather that user experience reasons they became apps. The ones I can think of are Twitter, Facebook, and LinkedIn. I am certainly not a proponent of web as a platform for everything but there are certainly some things it is rather good at, and making content discoverable in a consistent manner is one of those. If you hid the content in an app it's rarely exposed.

TheOtherHobbes 12y ago
This debate has been going since the days of AOL and CompuServe. As here, it usually misses the differences between public content, private content, and corporately farmed content. Twitter etc are corporately farmed content, and they all provide web and app access. The access method is just a front end. Personal content in apps isn't usually all that interesting. It's hard to think why anyone would care about my Angry Birds scores, or what level I'm on in Candy Crush. (If I played Candy Crush, which I don't.) If you want to make an app that shares content on the web, it's not difficult. I don't see a problem with the fact that it's extra effort, and if you're going to do it you need to justify that effort in some way.

yawboakye 12y ago

Agreed. Apps didn't break HTTP. They consume APIs (which can also be used by web applications). Thus, designing the API is what really matters.

curun1r 12y ago

This whole discussion reminds me of discussions about language evolution. Some people are prescriptivists and believe that learned language experts should determine what is and isn't correct usage. Others are descriptivists, arguing that languages are a living reflection of how they're used and that incorrect usage can become correct if and when it becomes widespread. Similarly, we have standards boards, who are often very divorced from the realities of actually building real-world software and we also have the engineers building real-world software. Which version of HTTP is correct, the one codified by the W3C or the version codified by the engineers building Chrome, Firefox, IE, Apache and Nginx? As a learning exercise, I implemented an HTTP server a few years ago and remember finding it fascinating that none of the popular user agents implemented the Keep-Alive header per the specification. And yet they all implemented it in a common, non-compliant manner. It made me realize that as much as I was using the spec as my guide, my implementation wouldn't be correct if I followed what it said for that header.

dtech 12y ago
There is a major difference between the two: computers are dumb. As a human, I can usually communicate with someone who uses a dialect or makes language errors. Computers are much worse at doing that, they basically need to know about every standard and non-standard behavior to correctly handle it. As such there is a very good reason for standards and thus standard bodies to exist.
Morgawr 12y ago
>Which version of HTTP is correct, the one codified by the W3C or the version codified by the engineers building Chrome, Firefox, IE, Apache and Nginx? There is a reason why protocols are not languages. A protocol is a well-defined standard that engineers are supposed to follow. There really is no space for "descriptivists" in technology and especially in standardized protocols. What is that, the protocol is useless? Well, maybe we should come up with a new standardized one instead of bastardizing the already-existing one and creating a lot of confusion and ambiguity (which machines have a hard time to deal with).
- cpeterso 12y ago

danellis 12y ago

HTTP is different, though. Developers are constantly creating thousands of HTTP services. What other Internet protocol can you say that about? Protocols like DNS, FTP, NNTP etc tend to be provided by a small number of fixed services. Once in a while there will be a framework for a non-HTTP protocol, like Zed Shaw's Lamson SMTP server, but that's uncommon and I doubt it's widely used. I can't think of any other protocol where even the most unskilled developer is given the tools and encouraged to determine how the protocol is used.