JavaScript as AJAX response (RPC)

[petermichaux]

Hi,

Some servers return JavaScript as the response to an AJAX request. When
the response JavaScript is eval'ed it calls other JavaScript functions
already in the browser to update elements, etc. This seems like a good
system because it allows so much freedom in creating the desired
behavior in the browser. The required data doesn't have to be converted
to XML or JSON on the server. The browser doesn't have to have
templates for interpreting and converting this data into some change in
the browser. All of the conversion algorithms don't have to be written
and changed when new behavior is required. This remote procedure call
approach is the predominant system in the Ruby on Rails world.
(Unfortunately they are calling Prototype.js functions.)

However apparently some people seem to think this remote procedure call
approach is a bad idea. I can't see why it is so bad because it is so
lightweight and flexible. It also helps to keep the client less
intellegent which seems good in a world of incompatible client-side
bugs.

If I use some neutral data format like XML to accomdate different types
of clients then I have to write different client-side interpreters for
each type of client (browser, RSS, POP, cell phone, etc). Why not just
write different server-side code that generates the correct JavaScript
(or other) for the requesting client type?

When is the RPC approach such a bad idea?

Thank you,
Peter

[Leo Meyer]

Some servers return JavaScript as the response to an AJAX request.

When is the RPC approach such a bad idea?

One problem I see with this approach is the need to change the API you are
calling. You limit your refactoring choices if you need to keep the new API
call backwards-compatible, and you may run into trouble when changing
versions.
The other issue is that you have a relatively high coupling between server
and client code across language boundaries, which is not always desirable.
Having said that, I also like this type of "RPC" calls. In my shop we use it
for one of our products. So far we haven't had any problems.
OTOH, we have a very small codebase for this product, and we use only one
AJAX request with a choice of server code (PHP, ASP, Java). In our setting
this works quite ok without too much hassle.
For large codebases with lots of different AJAX requests, though, I would
recommend to use this approach with extreme caution. You may be better off
with a data-centric approach here. But, then, I'd recommend extreme caution
for any kind of programming technique. There is no such thing as fool-proof.

Regards,
Leo

[Laurent Bugnion]

Hi,

pe**********@gmail.com wrote:

Hi,

Some servers return JavaScript as the response to an AJAX request. When
the response JavaScript is eval'ed it calls other JavaScript functions
already in the browser to update elements, etc. This seems like a good
system because it allows so much freedom in creating the desired
behavior in the browser. The required data doesn't have to be converted
to XML or JSON on the server. The browser doesn't have to have
templates for interpreting and converting this data into some change in
the browser. All of the conversion algorithms don't have to be written
and changed when new behavior is required. This remote procedure call
approach is the predominant system in the Ruby on Rails world.
(Unfortunately they are calling Prototype.js functions.)

However apparently some people seem to think this remote procedure call
approach is a bad idea. I can't see why it is so bad because it is so
lightweight and flexible. It also helps to keep the client less
intellegent which seems good in a world of incompatible client-side
bugs.

If I use some neutral data format like XML to accomdate different types
of clients then I have to write different client-side interpreters for
each type of client (browser, RSS, POP, cell phone, etc). Why not just
write different server-side code that generates the correct JavaScript
(or other) for the requesting client type?

When is the RPC approach such a bad idea?

Thank you,
Peter

The main issue I have with this approach is that you limit yourself to a
JavaScript client. Moreover, probably you limit yourself to a web
browser based JavaScript client.

Web services (in the broad sense of the word) should be, IMHO,
"universally" callable. We are only starting to see RIAs (rich internet
applications) calling all kind of web services (SOAP based, POX based
(plain old XML), etc...) to enhance the user experience. If you publish
a JavaScript-only web service, you close your door to such applications.
Additionally, if you want to open the door, the refactoring effort will
be huge.

I prefer standard interfaces when possible, i.e. SOAP or POX. In .NET
2.0 applications (ASP.NET, WinForms, WPF), for example, integrating SOAP
based web services is ridiculously easy. It means that a lot of
programmers will do so. As a web service provider, you have "duties" to
them (just like an interface is a "contract"). IMHO the duties are:
don't add breaking changes to your interface; make the interface easy to
use; make the interface as universal as possible.

Of course there are exceptions to that "rule" (of thumb ;-), but more
than often an interface designed for one single application ends up
being reused in other apps as well. If you choose standard to start
with, the refactoring will be easier.

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch

[Chris Smith]

Laurent Bugnion <ga*********@bluewin.chwrote:

The main issue I have with this approach is that you limit yourself to a
JavaScript client. Moreover, probably you limit yourself to a web
browser based JavaScript client.

Web services (in the broad sense of the word) should be, IMHO,
"universally" callable.

Who was talking about web services? This was a question about AJAX.

--
Chris Smith

[Chris Smith]

<pe**********@gmail.comwrote:

Some servers return JavaScript as the response to an AJAX request. When
the response JavaScript is eval'ed it calls other JavaScript functions
already in the browser to update elements, etc.

Okay.

However apparently some people seem to think this remote procedure call
approach is a bad idea. I can't see why it is so bad because it is so
lightweight and flexible.

If I'm understanding your approach properly, the main disadvantage is
that you are introducing high levels of coupling between the user
interface and the server-side implementation code. If that's not
important to you, then great. In many cases, though, it's nice to be
able to redesign a web page without needing to go through the
implementation of four or five different asynchronous requests it makes,
just to make conforming changes. With the more traditional approach,
the code to update the web page is in JavaScript code that's inside or
stored near the client-side page itself.

That said, there are other ways of approaching a solution to the
coupling problem. For example, using a component-based environment
(something like JavaServer Faces) for developing the server-side code
may allow you to ensure that the changes to server and client are made
in synch and reduce coupling, without needing to abandon this general
technique.

--
Chris Smith

[Laurent Bugnion]

Hi,

Chris Smith wrote:

Laurent Bugnion <ga*********@bluewin.chwrote:

>The main issue I have with this approach is that you limit yourself to a
JavaScript client. Moreover, probably you limit yourself to a web
browser based JavaScript client.

Web services (in the broad sense of the word) should be, IMHO,
"universally" callable.

Who was talking about web services? This was a question about AJAX.

Which is why I wrote "in the broad sense of the word". Web services as
services exposed on the web. I think I made it clear in my answer that I
was also talking about POX.

Greetings,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch