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.

Ok survey of the terrain, but WAY biased, and not very well-written.

If it wasn't for the fact that programming in Javascript is so obtuse

If Javascript is obtuse, You're Doing It Wrong. Javascript is a very powerful and expressive language—it's the browser API that's a piece of garbage.

data fields must involve a round-robin trip to the server

Wait, there are scheduling algorithms involved? http://en.wikipedia.org/wiki/Round_robin

Word salad anyone?

"it's the browser API that's a piece of garbage."

And that's the real purpose of Prototype, JQuery and friends. To glom over the unholy mess that is cross browser DOM compatibility.

Another question: is MVC still a suitable design pattern for web application development? We have HTML to model structure, CSS to model appearance, and Javascript/DOM to model interaction, and JSON to transfer structured data over the network. This suggests a design where each language plays to its respective strength, instead of trying to find "one language to bind them all."

This suggests a different model than what Xerox PARC had in mind when they came up with MVC for SmallTalk. I'm not sure what that model is, but I believe that the unstated assumption that MVC is a good pattern for web applications needs to be defended.

The sensible way to build more complex web apps these days is to have a (invisible) client side model, and have the controller communicate with the server as is required (typically to fetch data, sometimes to poll). The server becomes more of a router and data repository, with less intelligence. It is sometimes easier to think of the server as a secondary, dumb user with a huge amount of data on tap. And the more intelligence you can push out to the client side the better the system will scale.

I like where you're going with that. Now we just need a catchy acronym. :)

REST may be the applicable acronym for the server side (or at least, one design for implementing what you describe). But I haven't heard any design patterns with a catchy acronym for what all the cool kids are doing in the browser with Javascript. Perhaps that's for the best. Often a catchy acronym is a sign that a technology will soon either stagnate or be considered passe.

jimbokun and dmaclay,

It really depends on the application. Remember, the client is always untrustworthy. You can trust them with their data, but nothing else. In three-legged cases, like an ad or some other third-party developed app hosted in your page, you can't even trust the client-side to have unlimited access to the client's data! Plus, there are remote script hacks that potentially will compromise the user's state or other information.

a catchy acronym for what all the cool kids are doing in the browser with Javascript

At Yahoo, we call it Progressive Layered Enhancement. Start with working markup and server-side logic, and then enhance it in layers to add functionality for the browsers that can handle it, so that it always works, even if a layer is missing or broken.

Having worked on a Microsoft stack in the past, I can say that it was nice to have a single language from end to end. It just really sucked that the language was VisualBasic. So, I get the excitement behind GWT and Pyjamas. Not that the author is wrong, I just think he doesn't really treat the material very well.

"At Yahoo, we call it Progressive Layered Enhancement."

PLE! We have our catchy acronym :).

Good point about the security implications. That must be an integral part of any web application design methodology. For traditional kinds of desktop applications, that wasn't so much of a concern.

In my day job, we have a Java back end with a lot of user interaction implemented with Javascript in the browser. Data access server side stuff actually plays to a lot of Java's strengths, I think, and the more dynamic nature of Javascript is a good fit for DOM manipulation in the browser. I'm not sure I would want to pick one of them to run both places.

We use Adobe Flex, and at times have the Flex app write to a HTML page in the browser (for the vastly better markup). The .swf format makes things a bit more secure, although you can decompile Flex apps. For the most part we are targeting the flash engine for performance and functionality.

"So, I get the excitement behind GWT and Pyjamas. "

cool. very few people do! and don't forget rubyjs / rwt.

"Not that the author is wrong, I just think he doesn't really treat the material very well"

well, you can't have everything :)

I agree. Biased, poorly written.

"the idea of handing complete responsibility for "View" generation and near-complete responsibility for Model "business rules" validation to the Web Browser would make perfect sense"

The idea of handling business logic in the browser makes me puke. This guy should hand in his programmer card and never approach a computer again. You end-up with different set of rules implemented twice in two very different execution environments.

The only way it would not be utterly stupid would be if the server somehow generated the JavaScript validators based on the business rules, but that would, also, be a very ugly kludge (and probably require a validation DSL that is different from the implementation language of the rest of the server side).

"You end-up with different set of rules implemented twice in two very different execution environments"

precisely!!! read the article - that's exactly the present situation except....

"The only way it would not be utterly stupid would be if the server somehow generated the JavaScript validators based on the business rules,"

precisely!!! that's EXACTLY what the article advocates, by using XXXX-to-javascript COMPILERS.

in this way, the SAME language that is used server-side is ALSO the same language from which the client-side javascript is generated from.

in this way, the SAME source code which is used to perform the business rules validation can be either executed client-side, OR server-side, OR both, depending on the application requirements and depending on what the developer chooses to do.

this _was_ mentioned in the article - and was the whole _point_ of the article.

it's not as ugly an approach as you might think - it just takes a _lot_ of getting used to, and a significant amount of "old thinking" and "disillusionment with the present situation" has to be overcome.

let me put it this way: if someone wanted me to write in pure javascript, they would have to pay me a _lot_ of money. but, using compiler technology such as pyjamas, GWT or rubyjs / rwt, i don't mind at all - because i'm writing in a high-level language where the output happens to be javascript.

He fails to mention Cappucino, which seems even more ambitious than the MVC projects included.

thanks for the link. cappuccino looks interesting - except that it also looks _way_ out of most people's league. by that, i mean that you appear to have to abandon everything you've learned - the server-side languages you're used to - and go the whole hog into both a new language _and_ a new framework. i've included it for reference, on the original article at advogato.

I think MVC was always blurred, even in established contexts.