Building web pages on the server-side or client-side?

Con (client solution): The client-side solution relies on the client to execute your code properly. As you have no control over what client system will execute your code, it's much harder to ensure it will consistently give the same results as the server-side solution.

Con (client solution): The client-side solution relies on the client to execute your code properly. As you have no control over what client system will execute your code, it's much harder to ensure it will consistently give the same results as the server-side solution. This particular problem doesn't really seem to need a client-side solution, does it?

I'd stick with the server-side solution. The only extra work there is a foreach loop with one echo and that's not really so resource heavy is it (unless you've profiled it and know that it IS)? And the resulting code is all in one place and simpler.

I'm sceptical that moving the report generation on to the client side really saves any resources - remember that it's still doing an HTTP request back to your (?) server, so the database processing still gets done. Also, giving away your database schema on the client side could be a recipe for database attacks. Perhaps you should use a model-view-controller pattern to separate the business logic from the presentation on the server?

At least this keeps all the code in one place but still lets you logically separate the components. Look at something like Zend Framework if this sounds useful to you.

Typically, it's best not to depend on Javascript being enabled on the client. In addition, your page will not be crawled by most search engines. You also expose information about your server/server-side code (unless you explicitly abstract it).

If you want to transform data into the view, you might want to take a look at XSLT. Another thing to read up on if you have not already, is progressive enhancement. alistapart.com/articles/understandingpro... In the first client-side solution you presented, it's actually less efficient because there's an extra HTTP request.

And the second one is possibly not very efficient as well, in that all the data must be processed with json_encode. However, if what you're working on is a rich web application that depends on Javascript, I see no problem with doing everything with Javascript if you want to.

Actually, Google is making big steps in indexing JS content. See for instance googlewebmastercentral.blogspot. Com/2007/11/… – nico Dec 1 '10 at 18:53.

You can maintain a better separation of concerns by building it on the client side, but that can come at a cost of user experience if there is a lot to load (plus you have to consider what FrustratedWithForms mentioned). To me it's easier to build it on the server side, which means that becomes a more desirable option if you are on a strict timeline, but decide based on your skill set.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.