Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

mdxi (4658)

mdxi
  (email not shown publicly)
http://mdxi.collapsar.net/

Journal of mdxi (4658)

Saturday May 28, 2005
10:00 PM

HTTP Must Die

[ #24928 ]

After avoiding web programming for half a year, I'm back in it doing this diary thing for friends, and it sucks just as much as it ever did. In fact, I have come to a realization: "web programming" in its current state, must be ended. It's breaking the minds of a generation of programmers.

Olive is a far more complex program than the web app I'm working on now, but it's easier and far more enjoyable to develop, for a single reason which can be expressed in a single word: state.

Olive, being a traditional user-space app, has state information. As much state information as I want, all neatly organized in data structures of my own choosing. Web apps, as we're all aware, have no state, forcing the programmer to painfully reconstruct it via a horrible system of parameter passing and parsing, every single time the user does anything.

Someone who knows more about such things than I do needs to come up a stateful connection protocol for writing browser-embedded apps with server-side data storage. I am thinking less XMLRPCHTTPRequest (which, as I understand it, is just far more sophisticated message passing) and more constrained network-transparent virtual memory with XUL and/or HTML as a user interface definition.

The web was meant to be a collection of linked documents; let it go back to that, and let programmers go back to getting work done instead of coming up with package after package to attempt to work around the horrible pain of HTTP.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • It is not going to die. You are falling for the fallacies of distributed computing [java.net].

    There is a reason that HTTP was successful and all the stateful protocols that were around at the time or long before it were not. HTTP is beautiful. Learn it and understand it instead of trying to use it like an RPC mechanism which it is not. See, f.ex, How I explained REST to my wife… [naeblis.cx]

    • Numbers 3 and 7 are basically true these days, as long as you're not trying to do something really stupid. Number 8 is true -- TCP/IP has killed all competing protocols. The rest were clearly said with LANs, and not the internet, in mind. Only a Microsoft would make those kind of assumptions these days.

      No, there definitely has to be a better way to do this kind of thing. There just has to be.
      • No, bandwidth is not infinite, not now, nor is it ever going to be. “Cost” need not (and indeed, for the purpose of that list, does not) have anything to do with money. And the wire protocol is only a fraction of homogenity.

        Maybe in a few decades when we’ll be used to writing for machines with dozens of CPUs in non-uniform configurations, writing distributed applications will no longer be a huge leap from writing local applications. But local applications on those systems will not be any

  • Web apps, as we're all aware, have no state, forcing the programmer to painfully reconstruct it via a horrible system of parameter passing and parsing, every single time the user does anything.

    You don't have to pass everything around, just pass an ID of where you currently are, and store the actual state data on the server.