
Blurring of MVC lines: Programming the Web Browser. - iamelgringo
http://advogato.org/article/993.html
======
hxa7241
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...

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

------
IsaacSchlueter
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?

~~~
jimbokun
"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.

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

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

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

~~~
jimbokun
"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.

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

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

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

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

