DWR and JSON

[Gregg Bolinger]

I was wondering (and this goes for anyone,not just this weeks author) how using DWR would benefit over generating JSON on the server and eval on the client? If we're talking about passing Java objects to JavaScript I can accomplish the same thing eval'ing JSON. Add that ability to a library like JQuery and you've got a pretty powerful combination.

Where or does DWR jump ahead of what already exists?

[Bear Bibeault]

If I recall correctly from what (somewhat shallow) research I did into DWR when I was writing Ajax in Practice, the major advantage would be in making the calls. Using jQuery we could use $.getJSON() to initiate the request and get the automatically eval'd structure back.

With DWR, it would create a client-side proxy to a Java function so that, rather than making requests to a URL, you simply have a procedural-appearing API that abstracts the request from your code.

I think that's really neat and I was impressed with what I saw of DWR when I was looking into it, but not enough to make me want to actually adopt it. I'm finding the jQuery/JSON combination too easy to use to make me want to shift gears at this point.
[ March 11, 2008: Message edited by: Bear Bibeault ]

[Bear Bibeault]

Speaking of which, I'm putting the finishing touches on re-writing my BlackBox™ game using jQuery and JSON. Watch for an announcement in BA when I'm done.
[ March 11, 2008: Message edited by: Bear Bibeault ]

[Gregg Bolinger]

Originally posted by Bear Bibeault:
If I recall correctly from what (somewhat shallow) research I did into DWR when I was writing Ajax in Practice, the major advantage would be in making the calls. Using jQuery we could use $.getJSON() to initiate the request and get the automatically eval'd structure back.

With DWR, it would create a client-side proxy to a Java function so that, rather than making requests to a URL, you simply have a procedural-appearing API that abstracts the request from your code.

I think that's really neat and I was impressed with what I saw of DWR when I was looking into it, but not enough to make me want to actually adopt it. I'm finding the jQuery/JSON combination too easy to use to make me want to shift gears at this point.

[ March 11, 2008: Message edited by: Bear Bibeault ]

I went and did a bit more research after I posted this question and yes, it would appear there is more to it than passing java objects to javascript. Quite a bit more actually. The DWR Servlet acts as a Controller and calls methods on POJO's which return data to the calling function.

My argument is that I can already do that, and a lot more, with Stripes + JQuery. Even if I don't want the whole page request forward action typical web application process, I can make simple method (event) calls to Actions and return JSON back. So I'm not seeing the benefit of DWR over that scenerio. I'm not saying there isn't one. I'm just not seeing it and am hoping for some more insight.

[Bear Bibeault]

Originally posted by Gregg Bolinger:
So I'm not seeing the benefit of DWR over that scenerio[sic].

I'd say it's in the abstraction of that process behind a tidy API.

Again, not enough to push me over the brink, but I can see the appeal.

[Gregg Bolinger]

Originally posted by Bear Bibeault:
I'd say it's in the abstraction of that process behind a tidy API.

Again, not enough to push me over the brink, but I can see the appeal.

Maybe, and this might not be fair but....

( I typed this pretty quick so it might have a syntax error here or there, but conceptually it is accurate)

<script>
jQuery(function() {
   jQuery('#sendButton').click(function() {
      jQuery('#demoReply').load('/action/say/hello', {name:jQuery('#demoName').val()});
   });
});
</script>
<p>
  Name:
  <input type="text" id="demoName"/>
  <input value="Send" type="button" id="sendButton"/>
  <br/>
  Reply: <span id="demoReply"></span>
</p>

Assuming my Stripes Action has a UrlBinding to a controller named Say and the action has a method named hello() which simply returns the name you passed in. I don't find the above code all that worse than the similar DWR code found here.

Again, taking simple examples as these might not be the best way to determine better/worse but its a decent place to start.

[Bear Bibeault]

Originally posted by Gregg Bolinger:
Again, taking simple examples as these might not be the best way to determine better/worse but its a decent place to start.

I'm really interested to see Frank's response to this. With regards to the above, all too often we hear that "well, as things get more complex, Xyz framework really makes things easier".

Frankly, I haven't seen it. In fact, I often find that as things get more complex, the frameworks get more and more in the way as you try to do things that the framework doesn't really want to let you do. Then you just end up writing a lot of crappy code to get around the limitations.

Now I realize that DWR is not a full-fledged framework, so let's not even go there. But I would be interested in hearing Frank's view on how DWR scales in complexity compared, say, to jQuery's simplicity and scalability.
[ March 11, 2008: Message edited by: Bear Bibeault ]

[Frank Zammetti]

My thought is that it's two totally different paradigms.

When you use the jQuery/Stripes approach, and you could substitute virtually any other combination here (Prototype/Struts, Dojo/plain servlets, etc), you're still dealing in URLs. You're still essentially creating abstractions: those URLs are a layer of abstraction above some back-end code. Now, with some frameworks that abstraction may be very thin, with others it's thicker, but it's always there.

With DWR, you're dealing in remote procedural calls. You no longer think things like "well, url X maps to class Y,method Z". Instead, it's simply "I want to call method Z of class Y and get it's return value", and that return value may be a simple String, or it maybe be a whole value object.

You're right I think to say that the example you showed isn't complex, and probably isn't any more complex than the DWR answer, at least in terms of code volume. Where I think DWR has the advantage is in conceptual simplicity. Assuming for the moment that you're talking about a Java-based back-end, why should you have to mentally flip a switch and think of something other than what you're used to doing, which is method calls on objects?

Aside from that, why would I want to write code to spit out JSON representing some Java object? Because somewhere, you're either going to have to write that code, or at best find some library that does it and make use of it. DWR gives you that for free essentially (it's not JSON it returns, but my point is, who care! ).

For me, I've done code similar to what you're talking about with jQuery. And it's by no means difficult! But I find the approach that DWR pushes you towards, that whole RPC approach, to be simpler and more appealing from an architectural standpoint. YMMV of course