Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The result of the following process should be a html form. This form's structure varies from one to user. For example there might be a different number of rows or there may be the need for rowspan and colspan.

When the user chooses to see this table an ajax call is made to the server where the structure of the table is decided from the database. Then I have to create the html code for the table structure which will be inserted in the DOM via JavaScript.

The following problem comes to my mind: Where should I build the HTML code which will be inserted in the DOM? On the server side or should I send some parameters in the ajax call method and process the structure there?

Therefore the main question involves good practice when it comes to decide between Server side processing or client side processing.

Thank you!

share|improve this question
    
Would depend. In general I would prefer to do this on the server. Especially in environments like Ruby on Rails, where you can use templates and partials and have other options to get html generated easily. But there are tasks where simply sending the data with json may be better and let the frontend decide what's the best way to render it. (I think, question would fit better on Stackoverflow, but you should add more details about your environment) –  thorsten müller Mar 19 '12 at 10:46
1  
Another aspect to consider is the amount of data to transfer. If all you need to generate the table is a '10' then it could make more sense to do it client-side, but if you need to pass a whole table of data that needs to be calculated/manipulated client-side, might as well do it server-side, and pass the resulting table to the client. –  Rodolfo Mar 19 '12 at 18:28
add comment

2 Answers

up vote 3 down vote accepted

Server-side

  • Pros: More controllable, easier to debug, less dependent on client's browser
  • Cons: More server load, higher network traffic and latency

Client-side

  • Cons: Depends on decent JS/DOM implementation in the browser.
  • Pros: Performance, performance, performance. Less server load (thus faster server response), much less network traffic, and thanks to previous two much less latency.

For example LinkedIn's Engineering Team article "Blazing fast node.js: 10 performance tips from LinkedIn Mobile" as one of the points talks about that issue.

share|improve this answer
    
Please remember that any security code must be performed on the server side, even if that code (such as input validation) is also performed on the client side. So for Server-side I would add "Pro: Perform input security validations once." –  GlenPeterson Nov 12 '12 at 13:33
1  
@GlenPeterson: That's always good advice, however for that it doesn't really matter if the HTML is generated server side or client-side. For example you cannot trust submitted data, regardless where the HTML of that form was generated. –  vartec Nov 12 '12 at 13:44
    
Server-side pro: SEO works fine. Client-side con: forget about SEO. –  Florian Margaine Nov 12 '12 at 13:44
    
@FlorianMargaine: not true since a year ago: searchengineland.com/… –  vartec Nov 12 '12 at 13:45
    
@vartec Notice "some dynamic comments". Which is far far away from "any AJAX content". –  Florian Margaine Nov 12 '12 at 13:46
show 2 more comments

Definitely server side. If you do it server side, you will be able to take advantage of many more programming tools and libraries to do this sort of task. The processing for this task could get really complicated as the types of forms you want to create get more and more complex and the number of different types of forms gets greater and greater, so you'd really be limiting yourself by handling it client-side.

share|improve this answer
1  
you might be surprised how many of those tools now exist in the browser space. –  Zachary K Mar 19 '12 at 18:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.