views:

328

answers:

5

This is a design question. I have data that needs to go into an HTML table, which will later be manipulated by the user. Basically the user will be able to select items in the table rows.

I have two options - in both cases I'm using AJAX to get the data:

  1. Create the HTML code using PHP on the server side, send it to the client as HTML. The user then manipulates the table using Javascript (jQuery, essentially).

  2. Send the raw data to the client using JSON, then use jQuery to both create the HTML and later manipulate it by the user.

From a design/ease of coding/beauty point of view, which approach is recommended? Thanks for any insight.

A: 

Equally compelling arguments could probably be made for both, but you'll likely be sending less data down the pipe if you go with 2.

brian
+15  A: 
Tatu Ulmanen
Some good points, but do you think it is really computationally faster for one server to do the work vs thousands of individual clients?
patrick dw
@patrick, I was talking about the computational speed of one individual page load - the content will load faster if the HTML is created on the server. But of course it is always easier for the server if maximum amount of computations is transferred to the client.
Tatu Ulmanen
Hmmm. If you want a comparison on equal grounds (and speed), you should build a string array in the javascript as well and just push the elements. At the end, join them and assign at once.
andras
+1 I totally second this. We are putting enough load on the clients' machines as it is with all the tons of JavaScript stuff that is common these days.
Pekka
-1 for recommending non-templatized php.
Tchalvak
+1 for completeness of answer, but I'd remove the point that says "faster on server" as this is not really a point to consider here. You said it yourself it's better to, regardless of option, throw computations to the client.
Cawas
Actually, if you consider this is not client-specific computational data, it could all be cached by the server. That is a lot more optimized in a broader view of computational usage than if every client have to compute the same data every time the page is loaded. So, in a second thought, that's actually a very good point, but if described this way.
Cawas
+1  A: 

I really like the idea of putting things like this together on the client side. I found JavaScriptMVC to be a good Framework (the 2.0 Version is based on jQuery) for that because it has client side view templates (though not everybody likes that approach).

With jQuery alone I find it quite complex to create client side views though (because that is not what it is meant for), so you might be better of with putting everything together on the server side in PHP if you can keep your application equally dynamic that way.

Daff
+2  A: 

If the HTML generated is identical to page HTML you may be able to leverage your existing templating code to generate the same HTML with less code duplication.

Otherwise, JSON is typically more common as it tends to be more compact and it allows you to create nodes and assign non-HTML properties like event handlers to them as you go.

If you create your new nodes by creating an HTML string, however, you have to use HTML-encoding to ensure any <, & or quotes are escaped correctly. There's no built-in function to do this in JavaScript like htmlspecialchars in PHP; it's pretty trivial to write one, but no-one seems to bother. The result is jQuery apps that are full of client-side cross-site-scripting security holes, just as we were starting to make some progress of fixing the server-side XSS stuff.

bobince
A: 

Both options have plus and negative points, however andras makes a good point in stating whether the content needs to be indexed/searchable. I personally would opt for option 1 thhough as I believe the architecture would be easier to produce.

RichW