RE: The Web as an Application

>    At least we need to 
> examine what is meant by the term before accepting.
Agreed, what does "application" mean.  I have a different meaning in mind then you. perhaps everyone does.

> The thesis of this thread is that the Web is a single application, albeit
> composed.  
I don't comprehend this at all.



> Perhaps the Unix 'application' is analagous.  
I would say "The Web" is more analogous to the entire sum of unix systems worldwide that have internet server capability.
Entirely different from a unix "application" ... 


> Ideally, I apply simple primitive tools, possibly in
> combination, as in Unix pipelines, to achieve necessary complexity.
Precisely why I invented xmlsh :)
http://www.xmlsh.org/Philosophy


----------



> If simple links were available to connect XML resources (with any other
> resources), similar to pipes | > etc in unix, standards like XInclude
> would probably not be necessary, because transclusion for example,
> could be available via @xml:src.

I argue this analogy breaks down because you are now assuming that XML itself has web semantics.
That is @xml:src can be *indirected* 

This is precisely why XInclude is at a higher level than XML itself (same with XQuery and XSLT).
They take a subset of XML and apply additional semantics which is not necessarily approprate for ALL XML.
I think this is a good thing not a bad thing. 
But then this is why XML is not HTML ... 


> which I personally dont see as a 
> lasting model.

>REST not lasting? Surely you jest.    The Web has been going for ~20 years
>now - I just was looking at the first Web site a few days ago.

Not Jesting, no.  I am not refering to REST as a protocol.  
I am referring to REST being the foundation of "web applications".
Big difference in my mind.
A pure HTTP GET is REST and yes I dont see that going away soon.
But the era of *applications* being designed around server generated content with REST enabled links I do think is going away.



> and moved towards JavaScript based 
> applications generating the entire experience (with a tight, 
> not loose, coupling to the backend).

Yes proprietary platforms want to have the tightest possible coupling.

But I believe/hope you're wrong about those platforms winning in the end.

-----
Time will tell, not us.
But look around.  Look at most "modern" (last 3 years of so) Web Applications.
What are they being built out of ?   They are primarily pure JavaScript GUI's where the application in the browser is
driving state, managing  100% of the GUI and making occasional AJAX-y type calls to the back end only as needed 
and caching the results.    Look at the mobile apps.  Successful Mobile apps using either native apps or HTML5 techniques
pass down entire databases and attempt to run unattached as much as possible.
Many many page transitions or entire application runs can occur without hitting the back end.
There are good reasons for this, one huge one being unreliability and latancy of the web.
If an application doesnt need to do a client/server call to display a new page it is much more resiliant and provides a better
user experience.   Particularly true on mobile but also true on regular internet connected browsers.

Look at server-server applications.  More and more these are being driven by asynchronous queued messages, not 
synchronous request/response.

I do feel that the time to promote page-by-page server driven REST based applications may have passed us by already.

Received on Thursday, 6 June 2013 16:44:03 UTC