Which should generate the HTML: JavaScript or php?

Question

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.

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.

Cetacean

Okay, so based on a few of the answers, I should consider learning about JSON! :) – Cetacean

Based on reading everything over, looks like there are pros and cons in either approach. This is a hard one for me to accept an answer on because it looks like there is no "right" answer... what should I do in that case? – Cetacean

As with most real-life situations, we are faced with "shades of grey". What makes a "solution bubble up" is when we start considering trends: in the Web world, it seems that "decentralize/distribute workload" is a trend to consider. – Philistine

Answer 1

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).

Philistine

I agree with separation as the future, +1 – Neom

I like the separation idea too, which is why I was originally leaning towards making the table, the GUI, in js. I guess there are more things to consider, but I still like your idea conceptually. – Cetacean

@Carvell: of course, things like the ability to dispatch work to different team members, easier maintenance etc. – Philistine

I think all these answers are excellent. Thanks all. I went with the popular vote here. I voted up others that I thought were helpful. – Cetacean

Assuming server-side has some form of templating language, you'd still have separation of app logic and presentation. – Thickwitted

@porneL: of course but the difference being that "cpu cycle$" wise, you are paying whilst doing it on the Client side, you distribute this cost to others :-) This observation scales along with the complexity of the GUI. – Philistine

Answer 2

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).

Thickwitted

I definitely agree. Also, @Carvell Fenton: keep in mind that with the former approach (PHP generates HTML) you transfer HTML markup as well as real table data from PHP application server, but on the other hand - as porneL said - DOM complexity could represent a concern even for most advanced browsers. So, according to my experience, I would suggest discarding building DOM with Javascript unless it is commensurately tiny. Bye. – Got

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.

Gorky

Usually, i follow the convention "If js have to do some calculation over the data, then php will only print them; If the js have just to add the content in the DOM, then php will output the full html". But every situation must be valutate separately, in order to fullfill in the best way all the needs. – Cointreau

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.

Aubin

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.

Shabby

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.

Borlase

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.

Ulric

I see what you're saying, but having users being able to save a static version of the page in my environment is meaningless since they will always be looking for the latest data. Saved data is out-of-date and not useful to them. In a general Internet environment though, I could see this would be more of a concern. – Cetacean

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.

Stillman