Which should generate the HTML: JavaScript or php?

Question

Merry Christmas and Seasons Greetings all!

Quick question, looking for some recommendations. I have a site that will be requesting data from a database and displaying back to the user in a table. I am using jQuery (AJAX), php, and MySQL.

Where is the best place to generate the HTML for the table to display the data: should the php generate it and send the whole thing (HTML + data) back from the server, or should the php just send back the data, and the jQuery code make the table and insert the data?

Although this is running on an intranet, the I would still prefer the speediest approach.

Thanks in advance!

UPDATE:

I wanted to add a little additional information to this topic in case it might be useful to others. I agreed totally with the separation idea presented here, and went with that as my design approach. I used PHP to retrieve and organize the required data into JSON, and then used jQuery to generate the HTML to display the returned information. In this case, I was creating a spreadsheet style table form using jQuery, and populating "cells" that had values as returned from the PHP. With a few rows and columns, things ran fine, but as I increase to say, a 16 x 16 table, dynamically creating the input elements with jQuery...

At this point, I once again ran up against the ugly spectre that is IE6.

IE6 is still the approved browser where I work, so my app has to function on it. When I test my design on Firefox and Opera, the interface loads fast and is a pleasure to use. When I run the same code in IE6, it takes far too long to generate the interface; long enough that my users would start clicking things again, thinking the app was not responding. I can only chalk this up to the JavaScript engine that is in IE6 since the code runs fine in the newer browsers. So, because of this, I am back to a redesign for part of the interface to have the PHP generate at least the inner table form elements, populate with data, and then send that back to the client. It breaks the nice separation I wanted, but I don't see any other way to speed things up on the client side in IE6.

Anyway, just thought others might be interested in the results here, and for other beginners like me, how much browser support requirements can affect design choices.

Thanks.

Answer 1

On intranet bandwidth isn't a bottleneck, old clunky IE JS engine might be, so I'd say send generated HTML (even in better browsers native parsing of HTML fragments should be faster than building DOM with JS).

Answer 2

A good strategy is to use a "separation of concerns" approach i.e. use the Client Side to make things pretty on the GUI aspects.

Also note that this strategy aligns well with the current trends on the Web e.g. Google Web Toolkit (GWT).

Answer 3

Most would say AJAX should be pure data, and no html markup. I disagree with this, I find that AJAX is good at loading pockets of HTML into places within the screen. I think from a coding point of view, its easier to generate the HTML using the server side technology, and then let the javascript just plop it on the page where it needs to go. It will work well, the it will be efficient (innerHTML is the most efficient way of putting new html into a page), and the code maintenance will be easier. If you let the javascript generate the html, then you got to worry about 2 places if anything changes with the display, rather than just the PHP.

Answer 4

Speediest in terms of network bandwidth is having PHP output JSON, and use jQuery to create the markup.

Speediest in terms of client-side processing (and arguably, implementation) is using PHP to generate the markup -- for instance using templates -- and pass it via Ajax.

Answer 5

If you can get the data and generate the table before returning the page to the user, do it all in PHP. There's really no need to add the flash of AJAX if you're not gaining anything by it.

If the user is going to be filtering/requesting multiple data updates from the server...I'd return the data via PHP in JSON format to Javascript and let the Javascript render the HTML out to the page.

Answer 6

If you're going for the absolute fastest approach: render the HTML serverside with PHP. If you want a more maintainable, clean code approach: have the PHP send JSON to the AJAX code. This way you can maintain a good separation of data from presentation and behavior. It'll be easier to change how your site looks and operates if you can control the rendering of the HTML all from the same place - on the client.

Answer 7

One thing I had not seen in the other answers: consistency: When one sees a page rendered, he expects to be able to save that page as static html -- (although taht is less so now on these "web 2.0 days" ) but still, all thing being equal, the user should be able to save what he sees as a static page: therefore you should send it pre-rendered to html from the server.

Answer 8

I would create the HTML on server side, and use JavaScript to make some little refinements to the HTML. You cannot create an HTML page that is valid for all the browser, and detecting it from server side is not 100% sure; you cannot trust the user agent ID as many browsers make possible for the user to select a different one, and the only way to create HTML specific for a family of browser is to verify if the property being used is implemented.

What I report is valid in general; in specific case, it could not be valid.