I'm sure I'm missing something, because Zed is smarter than me. Why is this much better than just running each of those services on different ports? How does having everything behind a single port increase flexibility? It seems like he's serving multiple services over a single port, but I thought the point of ports as a software construct were to advertise different services?
Helps with firewalls. Helps with poorly-documented services. Helps when you don't know what you're going to be running (i.e. your language/platform supports multiple sorts with a config file, and you don't want your web server to have to read that config file).
Also helps when you may be changing what you're doing. You know all that annoyance you currently do with NGinX and Apache and whatever else where you write a very cryptic config file telling it what runs on what ports and in what directories and how to serve it? I would love to do less of that. I would love to not have to change it every time I put up a new little Ruby-on-Rails toy web-app. I would love to be able to just shove a new Rails or PHP or Sinatra or Node.js project into my github repository, have a simple cron job on my server check it out into my "checkouts" directory, and then not have to configure the web server for it.
These things are doable with current servers, of course. They're just a pain and involve writing a fair bit of code to make it happen. If you could subtract the "update your NGinX/Apache/whatever config" step, you'd eliminate a fair bit of the current friction.
This is more important for hobbyists than big sites. A really flexible server will never be quite as fast as a fully dedicated server (cf Mongrel_cluster versus, say, Passenger). But for hobbyists, it could be a godsend.
Newer hobbyists won't even have to learn how to deploy a Comet/FlashSocket/Websocket server from behind a reverse-proxy. I envy that.
In general yes, but as more and more technology gets added to the stack, it becomes increasingly difficult to keep everything running on port 80, which is the only port your users should have to hit on a web request. Take web sockets for instance, I have to run that on an off port because I can't run it through nginx yet.
That's very true. There's only so far a parser can go at keeping the protocols straight. Thankfully most protocols are designed to be really different so it's easy to do this right now. If I ran into a protocol that didn't work in this way then I'd have that on a separate port.
Port 80. This means you can make web apps that use all available protocols but only need to know about port 80. Gets through firewalls, cuts down on configuration, and it's not too hard to do in the server.