Re: HashInURI

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.

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

It is more the separation of 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.

> 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 ?

> 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.

> 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.

> 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-*.

> 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
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 10 February 2011 18:02:39 UTC