Re: HashInURI

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.

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

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.

Application state is managed by the user agent thus making http 
interactions 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.

It makes use of the uniform interface between the different tiers of the 
system which allows independent evolution of each component/layer/tier.

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.

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 11:58:42 UTC