Reputation: 21126
I have code like this at the moment:
<li onclick = "
function CBAppData( callerObj, data )
{
var string = '';
for( a in data )
{
debug.push( data[a] );
if( data[a].__attributes.config.name )
{
string += '<li>' + data[a].__attributes.config.name + '</li>';
}
else
{
alert( 'Error with json index ' + a );
}
}
$( callerObj ).children( '.returnData' ).html( string );
}
DoAjax(
this,
'get_for_url',
'<?php echo Site::$url; ?>Process.php',
{
'space_id': '<?php echo $space->__attributes[ "space_id" ]; ?>'
},
CBAppData
)
">
<?php echo $space->__attributes[ "name" ]; ?>
<ul class = "returnData"></ul>
</li>
DoAjax is just this:
function DoAjax( callerObj, _request, _url, _additionalData, callback )
{
$.ajax({
type: "POST",
url: _url,
data: {
request: _request,
additionalData: _additionalData
},
success: function( data )
{
callback( callerObj, jQuery.parseJSON( data ) );
},
error: function( a, b, c )
{
alert( "error: " + a + ", " + b + ", " + c + "." );
}
});
}
If I were to have a page that AJAX called written in PHP that just generated the LI part for me, I could save a lot of arsewhooping with the amount of fiddling i have to do with the string += '' bit.
Thing is... which is better?
Rendering html using clients compy, or rendering html using the server?
I don't care which I use, as long as I know it's the best or best practice way at the very least.
This query comes from needing to make this application ultra future proof.
Upvotes: 1
Views: 256
Reputation: 1
Not sure about the 'server side is faster' argument here. That's true generally, but in this case the difference is ..
Client-side rendering : Get JSON via ajax build html string in javascript inject HTML string into doc body, causing rendering (=the bulk of the processing)
Server-Side pre-rendering (ie server deliversready to go HTML) : Get HTML via ajax (so a bit more traffic) inject HTML string into doc body, causing rendering (=the bulk of the processing)
The only part you optimise out is the building of the HTML string in jacvascript, whcih is a miniscule amount of processing time compared to the bulk of the work: The HTML inject and subsequent rendering.
I like this client-side rendering approach, especially if there'as a chance the server platform might be changed in the future.
Banks do things like this with ackup services : sometimes they have a service running on on platform, two or more instances for failover, and sometimes one other service doing identical stuff, but written on a totally different platform. Heavyweight stuff, and normally not needed for everyday web apps, but it emphasises the value in splitting rendering processing from data processing.
Upvotes: 0
Reputation: 10469
Historically server-side processing has been faster. Having said that, for your application this is pretty small stuff and might not make much difference. Ask yourself which method is easier to maintain and there's your answer.
Upvotes: 1