AJAX best practice: loading rendered html or json?

[Rico]

Hi,

This is not directly related to the Play! framework, but I'm
interested on how Play! developers answer this question:

For loading data via AJAX, which method do you prefer and why?

(A) Return "only" the data as JSON and build the HTML component on
the client side

OR

(B) Render HTML on the server, return the HTML ready to be inserted
into the DOM


I tend towards (B), because when constructing complex HTML elements
with JavaScript the code is harder to read. I'd much rather create a
view template and use the templating mechanism of Play!

How do you solve this in your apps?

-Rico

[Adi..! was here]

Well It depends on the type of Application you want.

   (A) If your site contains like 5-6 pages or more and you don't want the site to be refreshed every time a user moves from one page to another.(A) Approach works here.Adding all the html objects to the dom from javascript.

   Although the user experience is great after intial load but there are some cons too.

   1) No SEO capability to the site.As everything is rendered on the fly.

   2) Nothing shows up if javascript is disabled in the browser.(Although a very small user base.)

   3) Everything moves from server to javascript.Increases the client side load time on old browsers like IE6.

   4) Maintaining browser state(Back and Forward button and Refresh button) is really pain.

   I guess many others can be added here.

 

  (B) Approach works well but if you want your site to look of 90's.As if everything is rendered from the server the user experience won't be something you can brag about.

      

   I would prefer a fusion of both the things.For example if a user clicks on user Registration link rather than redirecting on a new veiw i would prefer a new user registration flip made through javascript.Now the html here could be one rendered from server too in display:none block.

   

  I don't think you always have to create a large block of html in javascript.You can always pass html blocks written through play templates as json response to javascript and attach them to the dom there So the html and javascript remains separate as much as possible.

How do you solve this in your apps?

-Rico

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

--
thanks,

aditya...

[dirk]

Have you taken a look at the Mustache module?
http://www.playframework.org/modules/mustache

[Rico]

@Dirk: Thanks for pointing that out! This indeed solves my trouble
with creating complex HTML in JavaScript (jQuery to be precise). The
code ends up being very clean and easy to read. Great!

@Aditya: The shortcomings for AJAX-heavy web apps that you pointed out
are absolutely valid. In my case, SEO is not an important factor as
users have to sign in to use the app anyway. As for the browser, yes
people will need a JavaScript. In the days of Gmail most people should
have been turned into JavaScript fans anyway ;)

Rendering HTML on the server and loading it via AJAX requests does not
automatically make your site look like in the 90's. In fact for my
question, the resulting web page should look exactly the same for JSON
and server HTML versions.

Here is a screenshot of the app I'm working on:
http://startupsignals.com/wp-content/uploads/2010/11/ajax-ui-example.jpg

It's similar to an RSS reader with a master-detail interface. When a
user clicks on a review from the list in the top part, the details are
fetched via AJAX and the lower right content pane is filled.

In my case I decided to generate the HTML on the server with a
template. Loading it on click is 2 lines of jQuery:

var detailsAction = #{jsAction @Ajax.activityDetails(':id') /}
$('#activity-details').load(detailsAction( { id: $
(this).attr('id') } ) ); // Load server generated HTML

Everything you see in the lower right corner of the screenshot is
generated on the server and pulled in dynamically.

I'm quite happy with the readability/maintainability of the code. The
template as well as the JavaScript look clean. The price is a higher
load on the server, but in my case I hope to get away with that.

-Rico

[martin]

Hi
I usually go for HTML fragments. This way there is only one template
language to use and the view stays consistent. If you use JSON you
have to build the HTML pieces with JavaScript or a JavaScript
Templating system (jquery has one). I haven't tried mustach yet
because i try to avoid to use more than one templating language.

JSON i use only for a things like shoutbox, where the data is quite
simple (list of messages).

Martin

PS: For SEO you can always provide seperate views with plain HTML that
look like if they come of the 90's.

[wyz]

Mustache module looks interesting. I had a glance at the project at
github and did not find any javascript file inside. Will there be a
client-server round trip when PlayMustache.to_html is invoked?

And if no, how does PlayMustache.to_html compare to some jQuery
plugin's doing tempalte like jquery-tmpl, jQote2 or pure?

Thanks.

[wyz]

I think I have been mistaken, seems mustache is another client-side
templating technology.

[Pascal Voitot Dev]

On Mon, Nov 29, 2010 at 5:59 AM, wyz <wangy...@gmail.com> wrote:

I think I have been mistaken, seems mustache is another client-side
templating technology.

what did you expect?
anyway mustache can also be used on serverside afaik!

you can also have a look at the google-closure module which provides only 1 of the closure tools: the templating on client side... I will soon add the serverside stuff when I can find 5mn :)

Anyway, the main difference of closure (and certainly mustache) compared to "pure" for ex is that it generates Javascript (or Java or other languages) from your template. The result is that the client templating computation is very quick compared to a full template interpretation on the fly such as "pure". Moreover from the same template, you can generate JS or Java so you can use the same templates on server and client side.
The only drawback is the template compilation into your JS or Java but using live compiling provided by Play!, this is transparent!

regards
Pascal

 

[Ivan San José García]

See knockout.js . It solves the problem of re-render HTML from
JavaScript with JSON recieved data.

I think that "push" HTML blocks inside another HTML page with AJAX is
a bad practice.

2010/11/29 Pascal Voitot Dev <pascal.v...@gmail.com>:

[Ω Alisson]

+1 for Knockout :)

2010/11/29 Ivan San José García <iva...@gmail.com>

[Rico]

Thanks for pointing out knockout.js Ivan! This is exactly what I need
at the moment. I just wrote a lot of glue code yesterday to keep all
buttons in my UI in sync. All this can go away now with knockout.js.
Awesome!

http://knockoutjs.com/examples/

-Rico

On Nov 29, 2:03 pm, Ivan San José García <ivan...@gmail.com> wrote:
> See knockout.js . It solves the problem of re-render HTML from
> JavaScript with JSON recieved data.
>
> I think that "push" HTML blocks inside another HTML page with AJAX is
> a bad practice.
>

> 2010/11/29 Pascal Voitot Dev <pascal.voitot....@gmail.com>:

[Niko]

Indeed knockout.js looks really like a good fit on the client side, to
keep the overview about the JavaScript dynamics.

The one thing I am not yet clear is, how does it fit in when
submitting data to your Play! controller, since knockout seems pretty
bound to a JSON representation, how would you get the POJO binding to
work (which expects the parameter name dot notation) ?

Any experiences or ideas how that could work out?

Thanks,
Niko


On 30 Nov., 08:09, Rico <ga...@zero2many.com> wrote:
> Thanks for pointing outknockout.js Ivan! This is exactly what I need

> at the moment. I just wrote a lot of glue code yesterday to keep all
> buttons in my UI in sync. All this can go away now withknockout.js.
> Awesome!
>
>    http://knockoutjs.com/examples/
>
> -Rico
>
> On Nov 29, 2:03 pm, Ivan San José García <ivan...@gmail.com> wrote:
>
>
>

> > Seeknockout.js . It solves the problem of re-render HTML from