Re: HashInURI

Yves Lafon wrote:
> On Thu, 10 Feb 2011, Nathan wrote:
> 
>> Yves Lafon wrote:
>>> The example of twitter, where the search is using a hash sign
>>> (http://twitter.com/#search?q=foo) is a "good" example of the new 
>>> syndrom "everything is done in js, and I expose only one resource to 
>>> the world", with lots of consequences, including on caching. Another 
>>> instance of "I expose only one cgi for the whole site" or "one flash 
>>> page that contains the whole website", or even "one service enpoint 
>>> in WS-* world".
>>
>> Sorry, but I disagree strongly.
>>
>> There's nothing wrong with creating applications entirely in js, and 
>> in almost every respect it's much better for the network, servers, 
>> clients, users and the web in general.
> 
> Well, I hope you agree that it's the same exact thing as a complete site 
> in one flash page.

sorry no, quite different - explained further down.

>> It promotes separation of concerns as the data is separated from the 
>> applications.
> 
> It is more the separation of data and resources.

distinction between data and resources?

>> It's a pattern optimized for both fine grained data transfer and 
>> coarse grained hypermedia transfer, it plays very nicely with the 
>> network as you only GET what you need, allowing heavily optimized 
>> caching of data components on a granular level at clients, servers and 
>> intermediaries.
> 
> Optimized ?
> You need to a GET on twitter.com/ then load all the js, then let the js 
> run, interpret the hash and get the data from an API.
> So you have extra latency over twitter.com/foo.

On the first "hit" perhaps, after that it's somewhat reduced.

>> Application state is managed by the user agent thus making http 
>> interactions stateless.
> 
> doing a simple GET on something that represent the query, without any 
> cookie or nothing is not stateless ? Since when adding a hash make this 
> more stateless ?

Well it's now an application where application state (for instance 
displaying your username) is now on the client, and the search results 
are distinct sets of stateless JSON data (several (re)sources might I 
add), whereas formerly a GET to the old search results would have had 
your username in there, the several resources that make up the results 
would be smashed in to one with your user details and wrapped in html, 
app state would be on the server, "results" couldn't be cached and the 
protocol would be being used in a stateful manner.

>> Servers are freed from the responsibility of wrapping the data in to 
>> presentational markup, which reduces load, allows greater scalability 
>> and reduces latency all round.
> 
> I strongly disagree with that assumption.

s/are/can be/ - better?

>> It makes use of the uniform interface between the different tiers of 
>> the system which allows independent evolution of each 
>> component/layer/tier.
> 
> Having things exposed through an API _and_ having more expressive URIs 
> is not incompatible. In fact it's not even correlated.

below..

>> Users have a far better, more interactive, and more responsive 
>> experience.
>>
>> There are countless benefits, far too many too list, for instance I 
>> haven't even mentioned how it promotes the usage of web standards and 
>> allows applications to run on virtually any browser/os/hardware 
>> configuration possible - but in short JS applications are a key part 
>> of the distributed application architecture.
> 
> I never said that using JS was bad, far from that ! Just that a site 
> that is exposed through one URI through a JS program was the same as 
> having a "one service endpoint" in WS-*.

And here is the key distinction, it's not a "site" anymore, twitter used 
to be a web site with pages, now it's an web application with views, 
it's a critical distinction:

   http://www.w3.org/2011/rdf-wg/wiki/User:Nrixham refers to a page on a 
website
   http://twitter.com/#!/webr3 refers to reconstructable view in an web 
application.

The latter is not a site that is exposed through one URI through a JS 
program, it's a web application which provides views of data accessed 
over the web, each bit of data identified by it's own distinct URI, the 
data is currently in JSON, but it could easily be in RDF, or HTML, or 
atom or XML with an XSLT referenced, or any other format, it could even 
pull the data from the old existing HTML pages and present it.

Just because google doesn't index and send people to raw JSON, doesn't 
mean that data isn't on the web, the media type of the data could be 
changed to HTML with links and a stylesheet, would we then still be 
having this conversation? Would you still be saying it's a site that's 
exposed through one URI?

Best,

Nathan

>> The key failing in twitters system, and in many of these javascript 
>> based HashInURI apps, is that they are operating as a silo and haven't 
>> exposed their data properly.
>>
>> That is to say, they haven't applied the principals of linked open 
>> data to the data tier, if they published their data openly using the 
>> standards, then everybody would clearly see the distinction between 
>> the data URI, and a URI of an application with a reference to a view 
>> state of that application embedded in it.
>>
>> People are trying to suck data out of these client side applications, 
>> because companies like twitter haven't exposed their data tier in a 
>> web friendly manner (it's not machine understandable and has no link 
>> semantics, 'tis just dumb json you don't understand unless you know 
>> their API).
>>
>> Ultimately there's nothing wrong with JS applications or using 
>> HashInURI, it should be encouraged, the problems are:
>>
>> - failing to publish data properly in a visible / web friendly manner
>> - trying to reference data by using a URI that doesn't refer to data
>>
>> If we can focus on the real problems, then maybe we can fully separate 
>> the apps from the data, turn storage in to a commodity, let users 
>> control their own data, create an open app marketplace, encourage 
>> innovation, break down the silos, gain a distributed application 
>> architecture and take a giant leap in to the generation of the web.
>>
>> Apologies but this is something I feel quite strongly about (can you 
>> tell? :p), we need more people with the shared vision to drive this 
>> forward - not more people to push the buck on to using js and 
>> hashinuri claiming that's the source of the problems.
>>
>> Best,
>>
>> Nathan
>>
>

Received on Thursday, 10 February 2011 18:40:53 UTC