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