4 ms·

There is a major, fundamental problem with moving the definition of web applications to being JavaScript/Python/Java-centered. It offends one of Berners-Lee's p

by hxa7241 18y ago

There is a major, fundamental problem with moving the definition of web applications to being JavaScript/Python/Java-centered. It offends one of Berners-Lee's principles of web architecture: the 'principle of least power' http://www.w3.org/DesignIssues/Principles.html#PLP http://www.w3.org/DesignIssues/Principles.html#PLP. That allows the substance of the web to be accessed, analysed, processed by other unforeseen applications. But encoding everything around a full procedural programming language is very opposite to that. There is certainly a place for JavaScript-like power -- very specialised, low-level tasks, perhaps like the core of google maps interface. But there needs to be a larger, general framework of a simple, declarative form to express web apps. Something like SMIL and XUL. Actually, W3C has begun to develop something that might form the basis: CDF, but probably few have heard of it even, and it lacks the most important stuff...

cpr 18y ago
What if the client is fully in the browser and the server is simply serving up JSON or XML? Seems like as long as the verbs and nouns served are appropriate, you've got a good RESTian solution in the end, with interactive (browser client) and batch (server) interfaces available.
- lkcl 18y ago
  that's precisely the architecture that i use for the two web sites i've done, so far, and i'm currently working on two more. the only exception to the use of JSON has to be the uploading of files, where you're forced to use HTTP POST. and, for the same reason, when _downloading_ the file (e.g. an Image, a PDF) i don't use JSON, i use an HTTP GET. the reason for using the HTTP GET instead of JSON is because it's necessary to set a "Content-Type" header, in order to get the browser to load the file (Image etc.) correctly. other than file upload / download, yes, you can design your Pyjamas / GWT / RubyJS-rwt web site as a totally-compiled-to-javascript site that loads data exclusively using JSONRPC.
- hxa7241 18y ago
  But this doesn't address the explicit, simple, standardisation of app/interaction structure. If it is defined in a full procedural language, it is obscure and un-manipulable. The application structure should be moved as much as possible into that JSON, XML, or similar, and standardised. So the browser has a fairly simple and very general app-engine, and everything specific is in a simple, open format. In a sense: turn as much as possible into 'content', including interaction and app intelligence. Then, like other 'content' like movies or music, it is dumb, but infinitely accessible and manipulable.

by hxa7241 18y ago

cpr 18y ago

What if the client is fully in the browser and the server is simply serving up JSON or XML? Seems like as long as the verbs and nouns served are appropriate, you've got a good RESTian solution in the end, with interactive (browser client) and batch (server) interfaces available.

lkcl 18y ago
that's precisely the architecture that i use for the two web sites i've done, so far, and i'm currently working on two more. the only exception to the use of JSON has to be the uploading of files, where you're forced to use HTTP POST. and, for the same reason, when _downloading_ the file (e.g. an Image, a PDF) i don't use JSON, i use an HTTP GET. the reason for using the HTTP GET instead of JSON is because it's necessary to set a "Content-Type" header, in order to get the browser to load the file (Image etc.) correctly. other than file upload / download, yes, you can design your Pyjamas / GWT / RubyJS-rwt web site as a totally-compiled-to-javascript site that loads data exclusively using JSONRPC.
hxa7241 18y ago
But this doesn't address the explicit, simple, standardisation of app/interaction structure. If it is defined in a full procedural language, it is obscure and un-manipulable. The application structure should be moved as much as possible into that JSON, XML, or similar, and standardised. So the browser has a fairly simple and very general app-engine, and everything specific is in a simple, open format. In a sense: turn as much as possible into 'content', including interaction and app intelligence. Then, like other 'content' like movies or music, it is dumb, but infinitely accessible and manipulable.