Let me begin by saying that I have tremendous respect for Douglas Crockford’s contributions to JavaScript. This post is only about two of his comments from his latest installment of the Crockford on JavaScript series. See YUI Theater — Douglas Crockford: “Crockford on JavaScript — Scene 6: Loopage” (52 min.) for the complete video and slides. But for two points, this is an excellent lecture worth watching.
Scroll to slide 59 (42nd minute in the video), where he talks about the stack of protocols. In his opinion, "(HTTP) is completely wrong" as the "fact that HTTP is stateless becomes a real problem", and "(we) spend a lot of time trying to put the state back in…"
Note: The text in quotes in the above para may not be verbatim. I jotted down notes while listening to the video and may have missed some words.
Does the argument about trying to put the state back in HTTP sound familiar? That is the exactly the reason used by most web frameworks that promise to solve the "state management problem" and fail miserably at scale. The only scalable way to introduce state into HTTP is by using hypermedia.
Then scroll down to slide 62 (from the 47th minute) where he descries "Elko". This is a system that pins a given client to a given server that maintains state in server’s memory. In addition to Chip Morningstar’s post on Elko, see JSON Messaging Over HTTP that explains what happens at the HTTP level. The client connects to the server to get a session ID, and replays this ID with future requests. Apart from reducing protocol visibility, such an architecture requires state replication to remain fault tolerant. Replication reduces scalability. In HTTP, you store state in links and form fields to maintain visibility as well as to improve scalabilty. Such an approach lets you add as many server nodes as necessary without worrying about replication. This is a feature of HTTP and not a bug or a hack.
{ 9 comments… read them below or add one }
this world view of seeing loose coupling as either a bug or a feature is a very common pattern. when you’re primarily a developer trying to develop distributed applications, tight coupling is more convenient and might even be your goal. when you’re primarily an information architect trying to design massive-scale information systems, loose coupling is essential to get the job done. it’s fine that the application developers have different goals than the information architect, but it is sad to see that even the good ones still seem to think that the web is nothing but a client/server programming platform.
1. I think he is focused on keeping state for “conversational” systems, high interactive. A direct reference to HTTP as an static page retriever clearly denotes a misunderstanding of the protocol itself. Is this on purpose? No idea.
2. I can point my suspicious eye to the fact that he is putting Ajax as a protocol on the top of the stack. First because, although many people is aware that Ajax is not a protocol, there may actually be people that treats Ajax as such (there are others that think Ajax is a RIA technique). Second, because Ajax is originally based on asynchronous HTTP calls.
3. Lastly, to Erick, as an Architect I should, sometimes, choose tight coupling based on system needs. There is a trade of. Anytime I choose fighting the current, it is because I’m aware of consequences and I have all rationale in place. Also, now it is much emphasized to students the value of loose coupling, so I can tell junior developers try hard to accomplish it, just because “it is good”.
Cheers!
I thought the “two points” were quite jarring, actually. They betray a less-than-complete understanding of REST. My hope before viewing was that this would be an instructional “balancing trade-offs” sort of example, but it really does seem to simply miss something fundamental about the architecture of the Web.
That said, I’m still a big fan of Crockford’s lectures and his work on JSON. I do think Ajax-y interfaces will continue to be important (increasingly so), and I certainly think we are only seeing the beginning of a very broad embrace of JSON. What is crucially important at this point is that the REST folks start talking about how one uses both Javascript and JSON in a RESTful way (as I don’t think Crockford will!).
You state: “In HTTP, you store state in links and form fields to maintain visibility as well as to improve scalability.” Which raises the question how one should do that w/ JSON. Well, recipe 5.2 in the RESTful Web Services Cookbook is a great start (at least for links). But I think the question remains as to how (and if?) one should do forms in JSON in a way that is inline w/ the principles of REST. I happen to think a sort of runtime JSON/WADL approach (a la Google’s new discovery-based web services) is a reasonable way to do that (I know many other REST folks disagree!). But JSON is not going away, nor are interaction patterns that lead folks to grab for tightly-coupled approaches like Elko. I think that have a rich set of patterns that address those needs in a more RESTful manner would be quite useful.
Should one? IMO, yes, definitely – links alone are not enough in all situations. How should one? URI Templates, I think – to minimise the structural support required in the surrounding format for specifying a form.
Seems simple to answer to me (even if it doesn’t necessarily follow that that’ll be simple in implementation, of course). Or am I missing something?
Application state can surely be managed in links without a form-equivalent in JSON.
There is Mike Amundsen’s study on hypermedia and JSON at his blog… a nice start on that.
Frankly I ‘m saddened this is still up for debate. Subbu, I remember we were discussing HTTP state management, session replication etc. back in 2001/2002 in the context of netui!
As an end-user the thing that irks me most about AJAXy websites is the lack of browser feedback. Something as basic as, “Has the page finished loading?” Like portals/portlets I can’t help feeling that the web-browser “shell” should be providing more standard UI, so that I don’t have to learn a new way to monitor progress for every site I visit.
Dan
Wow, et tu, Crockford? I suppose this meme that HTTP is wrong or broken because it’s stateless is here to stay, forever – it was the first thing I “learned” about HTTP when I started writing CGI scripts almost 15 years ago –, but it’s always shocking to see people of such high profile get such fundamental things wrong about technologies they should know better about (even if the technology is not in their core area of expertise, as HTTP probably is not for Crockford).
Still, Erik’s comment is illuminating in that respect.
i want write a code if i bookmarked one page and closed the browser.
again i opened the browser then i opened the bookmarked page it should open login form.plz help me in javascript