Comment by hxa7241 | Hacker News Reader

Comment by hxa7241 | Hacker News Reader

Parent Full thread

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

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.

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.

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.

Reply on news.ycombinator.com