Hacker News Reader

Comment by samwillis | Hacker News Reader

I believe that the "world wide web" took off for two reasons. It was completely free and it was incredibly easy for ANYONE to make a website. If you needed to "compile" all HTML it would have discouraged a lot of casual experimentation. Not everyone understands what a compiler is.

Just as an example I started playing around with HTML when I was about 12 (in 1998), it was easy and I got instant results. A year or so later I tried to learn Perl and quickly gave up because I couldn't get my first script to run. It was another year before I tried to "program" again and became hooked.

HTML and HTTP were successful because they were incredibly easy to understand. I wish we could keep it that way.

View on HN

Wouldn't it have been cool if there were an efficient binary format and a nice human-readable and human-editable format, with a well-defined transformation from one to the other?

Back in the 1990s, Ron Rivest came up with canonical S-expressions, which are fully capable of representing the same information represented by HTML, XML, ASN.1—but can be either human-readable or binary.

Here's a simple example: (p (* class (footer x-treme)) "This is a " (b "footer") "."). Very human-readable, very human-editable, and easily machine-readable, wouldn't you agree?

As a binary format, it would be (1:p(1:*5:class(6:footer7:x-treme))10:This is a (1:b6:footer)1:.). Still geek-manipulable, if necessary, and extraordinarily simple to parse. And it has the advantage that it is a distinguished encoding--any of the myriad human-readable encodings all reduce to the same canonical encoding, which has advantages for hashing.

I'd argue the big thing that made HTML so easy to play with was permissiveness, not the lack of explicit compilation.

Perl doesn't tend to have an explicit compilation step. You could write a HTML compiler to be as permissive as HTML parsers and you wouldn't have the same frustration you had trying to get started with perl.

Gopher was simpler to understand than HTTP/HTML. But it wasn't as flexible, and didn't have as nice support for pretty pictures and midi files.

If anything, HTTP/REST was much more complex. HTML was somewhat mystic yet allowed you to move things around easier, and actually design things vs just presenting them. And hyperlinks were really cool.

http://www.ils.unc.edu/callee/gopherpaper.htm

>HTML and HTTP were successful because they were incredibly easy to understand. I wish we could keep it that way.

The web is big enough today that we can afford to make it more efficient since we have so many professionals that don't require the kind of implicit hand-holding provided by the original implementations. Back then everyone was a newbie and there were no web professionals.

I think we need to be careful about claiming its more efficient. There seemed to be significant disagreement about how much more efficient SPDY was last year from the various different benchmarks. From memory the consensus seemed to be that its only 5-10% quicker. Does anyone have any more up to day benchmarks?

I hate the idea that you would have to be a "web profesional" in order to get started today. We should embrace and keep the culture the web was built on.

That's an incredibly good way to lock out new newbies. I don't know how many people I know who got into programming through web development. Just because existing web developers don't necessarily need a simple solution doesn't mean new web developers couldn't take advantage of it.

For what it's worth, I started messing with HTML in elementary school, but had no idea how simple HTTP/1.0 was until I hit the 400 level classes in college. Editing in Notepad was the only way to go back then: even Dreamweaver got too complicated. Likewise, my first foray into JMS/message-queue type stuff was with STOMP, the simple text-oriented message protocol: there was no way I was going to understand the 'open wire protocol' for ActiveMQ. Ain't got time for that!

All that said, I think peterwwillis is right: http/X.0, as long as it's well-simplified, is better in binary than it is in text. Ideally, there's a bijection between your text-mode and binary-mode (like a lens), where it's easy to parse (rely on your toolset to do the translation back and forth) and easy to put on the wire. Forth is a good example of how to do it sanely.

Really? I can't imagine anything they might do putting this out of the reach of say a sophomore C-S student or a motivated independent learner.

A lot of current professionals started out as 11- and 12-year-olds dodging COPPA to host their first HTML web sites, not CS sophomores.

>A lot of current professionals started out as 11- and 12-year-olds dodging COPPA to host their first HTML web sites, not CS sophomores.

I would put those 11 and 12 year old down under "motivated independent learner"

If your concern is the a binary HTTP, too bad, it already here, its called HTTPS. It does seem to be holding anyone back.

If your concern is a binary HTML/compiler for it, I don't by that either. I was using a compiler when I was 8 years old and didn't have a problem with it conceptually.

HTTPS is HTTP over a TLS connection, not a binary version of HTTP.

Obviously, but hits take very helpful to look at HTTPS over something like wireshark. That was my point.

Yesterday, I showed a classroom full of high school kids HTML and CSS. They were so excited to be building stuff, and thought it was so neat that the text would turn into a web page.

Just because we have more 'professionals' today doesn't mean everyone is a professional.

I think to get maximum innovation on anything technology related, it should always be simple enough to get started at any level, then as you gain more experience you can (and the specs allow you to now -- AS2/EDIHTTP spec for one has encryption, compression, on top of HTTP/HTTPS - http://www.ietf.org/rfc/rfc4130) do more for performance, optimization etc otherwise it is premature optimization and a bit of a wall.

Like with gaming, each game should be simple to start but deeper to master. That is what this layer is all about, lower down the OSI stack it is much more of a wall to beginners. Never lock out beginners as they can be better masters with time, don't hide the entrance to the labyrinth. Leave things as approachable, but with better professional experience, modifiable to perform better. We have all that now, a competing binary protocol will never see the innovation that a more simple one like HTTP will. Higher up the stack you can see how this was better for exchanging data in standard ways from old school binary blobs, to CSV files, to XML files, to JSON. Same reason REST services won over SOAP, simplify... There is a JSON binary format BSON in mongo and also MessagePack but guess which one is used more in service/exchanging data the textual one or the binary ones? The binary formats work well in certain situations where both endpoints are controlled by the same entity.

Binary and more locked down/optimized formats and messaging have their place but the start/base should always focus on simplicity over optimization.

The general rule in exchanging via standards is be liberal in what you accept, conservative in what you send. Being all binary all the time is a backwards step and is conservative on what is accepted, I also think it would lead to a host of difficult to debug problems just based on work I did with AS2/HTTP RFC implementation one of them being streaming and of course encoding/decoding which can fill hours of work if you can't visually see the content at some level.

But I don't think we should be raising the barrier to entry and making it more difficult for a young hacker to get started. Like the above commenter I started hacking around with HTML and CSS when I was around 12 and it led me into linux/python/php/web frameworks.

There's something beautiful about being able to teach someone how to write a basic HTML document in 20 minutes. My mother can easily understand what HTML is doing, I doubt she'd understand a compiler.

I see where you're coming from, I had a similar experience playing with HTML as a kid. That said, "compiling" HTML from text to an efficient binary format wouldn't have prevented browsers from including those compilers themselves and transparently compiling all plain text pages received. Newbies could keep on serving plain text HTML (until someone chastises them for it) while the web as a whole would benefit from the increased efficiency that comes from binary pages being the norm.

Your argument doesn't really apply at all to HTTP, though. No one "got their start" peeking at HTTP requests. It's solely the domain of those working on infrastructure (for some definition of that word). Anyone with any idea of what HTTP really is (ie more than "that thing at the start of a URL") should have no problem using a tool to convert between a binary and text representation of the protocol. It's not like you can just magically pull HTTP requests out of the ether, you need a tool anyway. There's no reason why curl (for example) couldn't transform a request you write into an equivalent binary protocol, or why it couldn't do the inverse operation when it receives the response. It's utterly ridiculous to me that there is such inefficiency in HTTP just to make things slightly easier on the implementers of curl and wireshark.

HTTP is a protocol designed to communicate information between two machines. There's no reason it should be human-readable. Trying to make a protocol that's easy for humans to read and write leads invariably means making it harder to write software for.

A while back, I wrote a daemon that checked a bunch of network stuff in a loop. I needed a UI for it, so I made it speak http. No library, just raw GET support. It worked. Didn't take long to write, either. I would never have tried that with a binary protocol.

I don't think anyone's saying HTTP/1.1 should go away.

You say that like you think a custom binary protocol would be harder than writing a HTTP server, even a simple one, from scratch.

A custom binary protocol? Then I would have to write a client! And install it everywhere. And keep it updated. And design my gui in wingdi instead of html.

That is not a viable option.

I thought you said you weren't using existing libraries? Or did you just mean for the server? You made it sound as if you thought writing a server for a custom binary protocol was harder than writing a HTTP server from scratch.

If you're aiming for an existing ecosystem, then sure, there's no reason not to use HTTP, assuming you make use of established libraries. But widespread use is HTTP's only real virtue; the protocol is considerably more difficult to implement correctly than it should be.

No libraries. Ordinary web browsers for the client side.

A minimal HTTP server that recognizes GET requests, finds the url, throws away everything else, runs the relevant code and returns an HTML document of the results is actually really easy to write. And easy to integrate into an existing event loop.

Sure, if you cut corners, place some hard buffer limits, discard the vast majority of the specification, and don't care about breaking parts for brevity, HTTP starts to become tractable.

But even a minimal HTTP server, even one that ignores things like HEAD requests, is still going to be more complex than, say, receiving the URL raw, or even a URL wrapped in a simple structure like a netstring.

Actually implementing a full, correct HTTP server would be one or two orders of magnitude more complex that implementing a more modern protocol from scratch.

Reply on news.ycombinator.com