I'm a bit curious as to why you said "Why is the web based on text based protocols?". Last time I checked, TCP was pretty damn binary. Or do you mean HTML, etc.?
I was mainly thinking HTTP at the time, as it's an actual transfer protocol, as is FTP, but yes, HTML is an example of something else that doesn't really need to be text based. XML is an even worse example.
Mind you, there is perhaps a minor benefit to ease of use with HTML, since the web server just needs to know how to serve raw files, and you can write the HTML with any text editor, so it makes use of pre-existing tools. That will help get things started, but there is no real reason why things need to be left this way. For example, due to size reasons, a lot of website will gzip the HTML before sending over the wire. How is this really much different from compiling it in terms of usability or workflows? You could have built a compiler module into the web server instead of a gzip module (for on the fly compiling/compression), or precompiled stuff as the equivalent of prezipping stuff. Sure, to do it on the fly, you'd need a module for the web server you're using, and there are lots of web servers, but there are also lots of browsers, and they all (currently) need an HTML parser. So really, you could have just moved the parser from the myriad of web browsers into the myriad of web servers.
With things like HTTP, it's a little harder to justify the text based nature. I don't know of anyone who has ever used .asis (as-is) files. If you're not writing the HTTP headers into your file, they're either being generated by the web server itself, or by some dynamic script. Consider the sort of code it takes to generate those headers. Is it any easier to type something like:
header("Content-Length", data.length) , then say:
header(ContentLength, data.length) , where ContentLength is just some named numeric constant (perhaps from an enum)? Or do you prefer a more raw:
print "Content-Length: " + data.length.to_s + "\r\n" . I suppose the binary equivalent of that would be with a struct, such as:
header.contentLength = data.length . My point being that the nature of the protocol would likely have little effect on the code to generate those headers. It's still the same basic problem that needs to be solved, and all the APIs are just trying to abstract out that problem. They will change slightly, mostly to make writing the API easier, or more transparent, based on the form of the underlying protocol, but we're talking very minor differences here.
Hooman, if they put it into all binary, wouldn't you need a compiler to build web pages? If that were the case, would it not be more difficult to make changes?
I was thinking mostly transfer protocols, and in that case: No.
In the case of HTML: No (with dynamic compiling, or web browser support for both text and binary formats), but a compiler would be a natural tool to have available for performance reasons. As web browsers only understand a text based format, this optimization is not currently available. With good web server support, or at least with dual browser format support, you could at least get a lower performance version working automatically for quick testing and debugging. (The performance of which would not be worse than what you currently get).
Slightly off topic rant:
The dynamic compiling ideas is not entirely unlike how the D programming language lets you put a shebang line such as: "#!/usr/bin/dmd -run" as the first line of your source. The "-run" compiler switch means compile and run without leaving any intermediate files in the file system, and so having that on a shebang line makes it appears to work like a scripting language, even though it's actually compiled.
Now here's a thought for people. Since browsers already support multiple protocols and data formats currently, how hard would it be to define a new protocol (say a prefix of 'bhttp://', instead of 'http://', or 'https://', or 'ftp://'), and then define a binary version of HTML (perhaps just use a new MIME type, like 'application/bhtml').
Edit: Btw, I'm not overly impressed with TCP sometimes, even though it's a binary protocol, but that's another rant. Mind you, it depends on the nature of the traffic. There are certain features of web traffic that make most of the feature of TCP useful, but I still have my doubts about how some of it is done. But perhaps more on the current topic, why is HTTP a stateless protocol? Apparently it was done for efficiency reasons of not having to burden the web server with having to maintain state for each client. But then why did they build it on top of TCP, which *does* have state, and does burder the web serving computer with maintaining state information. Sure, the web server software doesn't have to deal with it, they've pushed the problem to the OS. Oh, but wait, state is very useful to have, how else would you get logins to work? Due to the stateless HTTP layer, we need to add an additional Cookie layer to get state back. There's no chance of adding that state to a uniform state system, nor much of a chance for optimizations at the transport layer, since it explicitly doesn't have state. Hmm, considering the current "state" of things, the original reason is starting to smell a little fishy.
