Develop Reference

Building HTML client-side VS serving HTML server-side?

I always find it difficult to decide if I should render my HTML server-side or build it client-side.
Let's say I want to render a dynamic HTML dropdown with following requirements:
Shows records from a database table at page load
Must stay up-to-date (users can add/remove records from the database table using the website)
I can't decide between
Option 1
Render template with empty dropdown server-side
Populate dropdown client-side using ajax requests (JSON)
Update dropdown client-side using ajax requests (JSON)
Concern: Rendering empty elements before populating feels ugly to me
Option 2
Render populated dropdown server-side
Update dropdown client-side using ajax requests (JSON)
Concern: Why would you render server-side if you are still updating it client-side?
What solution is more commonly used in web development? Feel free to share different approaches.

This is a little opinion bases. There are schools for the server-side, and other schools for the client-side. The main reason for the later is utilizing the client machine (which are free for you) to free the server resources (which you pay for). This also makes your app more scalable.
The example that you gave is not detailed enough, and it is only one aspect. I usually use these general rules:
If there are dynamic parts of your page (e.g. dropdown, grid, popup form, etc), I use Ajax to avoid reloading the entire page.
If the HTML is very simple and/or requires further processing on the client-side, then just send JSON data from the server and build the HTML on the client-side. For example, I usually do not send error message from the server. Instead, I only send status codes (e.g. Successful, AccessDenied, Error, etc...) and I inspect those codes on the client and display the associated message. This is specially useful when different messages are displayed in different colors and styles or contain other HTML tags like links.
If it is a complex popup form or grid of data, then I send the HTML from the server. It is usually much easier and more flexible to build complex HTML on the server. Also when there are sensitive information used to build the HTML, it is usually much easier to build it on the server, otherwise you'll have to send some flags from the server or, better, you need to split your HTML building process to sections depending on permissions.
As for that very specific example in your question, I would go with the first approach (all client-side), mainly for the DRY concept (Don't Repeat Yourself). You don't want to have two pieces of code doing the exact same thing, and have to remember to update both every time you need change something.
Note though, that you don't have to send empty drop-down if you don't like it. Instead of only updating options like your example is suggesting, you can actually rebuild the entire dropdown every time. I don't particularly like this approach, especially if there are event listeners and other references attached to the dropdown, but I just wanted to say other ways to do it. This method can be useful on some scenarios, especially if the dropdown is part of a bigger section of the page that this whole section requires updating (rebuilding) every time, in which case I usually opt for sending the HTML from the server.

Your concerns are valid, each case has its advantages and disadvantages as you mentioned.
I would, personally, go with the first approach (all client-side); mainly for code maintainability. With this approach, you only have to update the HTML client-side instead of both client-side and server-side.
However, there is an argument to be made for saving that one request by server-side rendering the values. Even though it might be insignificant, there is a small performance optimization.

That depends. are you worrying about SEO?
Are you using any kind of client-side framework? I will assume that you don't, since JavaScript frameworks have there own way to do this, if you want you can read more about angular/react/vuejs which is the hottest JavaScript frameworks those days that will solve this issue.
Client-side frameworks render HTML on client-side only, and use only Ajax API to receive data from the server.
But if you don't want to use any client-side framework and do it in the "classic" way, both ways are appreciated. I tend to like the first way, this is almost how client-side frameworks do it and makes the most sense, yes you render empty table but you only render the "container" of your data, if you're bothered by how it looks visually (Showing empty list before data is fetched) you can just show loading bar or hide the table till the data is fetched.

JavaScript Grid that create markup in HTML5 Web Worker

I am working on Business intelligence based web dashboard, i have tried several Third party JavaScript grids namely JQGrid, ng-grid.
Problem is that when Grid try to Render with big data Object it stuck and crash the browser.
Now i am thinking to Write my own GRID using HTML5 web-worker,it will create html mark up in String from data object and then pass to main object and append in DOM.
Please write suggestion about this approach,
and name the Grid that use this approach if any..
Thanks

One of the most performant grids for huge amounts of data is SlickGrid.
If you are to write your own you should ensure you avoid paints, like comments mention, and use a virtual scroll if you really have a lot of rows (100k+++).
I once started writing my own grid and I can guarantee you that making it performant for lots of data while keeping it usable is not exactly an easy job :)

Mobile Webapp: render data list in PHP or Javascript?

I am currently developing a webapp aimed for mobile devices which basically consists of a couple of long and complex lists, lots of data, collapsible cascading elements.
I'm getting the data to be displayed as XML, now as I see it I have two options:
build the list on the server and send HTML to the client
send XML to the client, build the list with Javascript/jQuery
Not sure which is more efficient, less data to transfer is good, less load on (especially older) phones is also good.
Any other pros/cons I'm not seeing? Suggestions?

The less data you send the better.
I often prefer to make a one-page application. All of the data needed is loaded via AJAX or Web Sockets (check out Socket.IO for a nice wrapper, with compatibility for mobile browsers that don't directly support Web Sockets). That way, you can have a much smoother user experience, and save bandwidth while doing it.
The con with this method is SEO. Search engines won't be running your JavaScript, and therefore won't index any data you are displaying. For "application" like sites, this is typically not a problem. If your site is more content based, then it might be an issue for you. There are ways around this, and progressive enhancement goes a long way to helping the problem. You will need to decide if this is right for you and your situation.

The presentation of Nicholas C. Zakas on velocity 2013 can help you.
Enough with the JavaScript Already. The peroformace or js rendering is very bad, especially for mobile webapp. We have changed the render of data list form js to php in some appliction. You should try to compare the performace or these two ways, and choose the better one. I recommend you do the render of big list in php, just for performce.

Render partial view on the server or send json data and render template on the client

I was wondering what would be a good approach (or recommended approach) to render partial views in a web application.
I have a requirement where I need to load data into an already rendered page using AJAX, sort of like a "Load more..." link at the end of the page which grabs more information from the server and renders it to the bottom of the page.
The two options I am playing with at the moment for the AJAX response are
Return a JSON representation of the data, and use a client side template library, (e.g. jQuery templates) or just plain javascript to turn the JSON into HTML and append to the bottom of the page
Render the partial view on the server (in my case using grails' render template:'tmplt_name') and send it across the wire and just append the result to the bottom of the page
Are there other ways to do this? If not, given the above options which would be better in terms of maintenance, performance and testability? One thing I am certain about is that the JSON route will (in most cases) use up less bandwidth than sending html across the wire.

This is actually a really interesting question, because it exposes some interesting design decisions.
I prefer rendering partial templates because it gives my applications the ability to change with time. If I need to change from a <table> to a <div> with a chart, it's easy to encapsulate that in a template. With that in mind, I view almost every page as a aggregate of many small templates, which could change. Grails 2.0 default scaffolding has moved towards this type of approach, and it's a good idea.
The question as to whether they should be client-side templates or server-side is the crux of the issue.
Server side templates keep your markup cleaner on initial page load. Even if you use something like Mustache of ICanHazJS, you kinda sorta need to have an empty element in the page (something with your template), style it appropriately, and work with it in Javascript in order to get update your info.
Drawbacks
"chatty" applications
larger envelopes across the wire (responses include HTML, which may be considered static)
slower UI response time
Benefits
Good for people with lots of server side language experience
Maybe easier to manipulate or modify in a server-side environment (e.g. return a page embedded with multiple templates, which are programmatically loaded and included)
Keeps most of the application stuff "in one place"
Client-side templates can really reduce server-load, however. They make an application "less -chatty", in that potentially you could minimize the number of calls back to the server by sending larger collections of JSON back (in the same number of bytes, or fewer, that would be taken up by HTML in a server-side template scheme). They also make UI experience really fast for users, as clicking an "update" link doesn't have to do an AJAX round trip. Some have said:
Anthony Eden #aeden 10 Dec Reply Retweeted Favorite · Open
the future of web apps: requests are handled by functions, logic is always asynchronous, and HTML is never generated on the server.
Drawbacks
Not great for SEO (un-semantic extraneous UI elements on initial page load)
Requires some Javascript foo (to manipulate elements)
Benefits
- Responsive
- Smaller envelopes
Trends seem to be moving towards client side templates, especially with the power exposed by HTML5 additions (like <canvas>)...but if leveraging them requires you to rely on technologies you're not extremely familiar with, and you feel more comfortable with Grails partials, it may be worthwhile to start with those and investigate refactoring towards client side templates based on performance and other concerns later.

in my view the second option rendering partial is better because if you get a json data you are supposed to manipulate it like set style, create elements, set values and similar thing as per the need just after you get ajax response in javascript but if you render partial, you can design your view in that partial before and keep ready and just import using ajax call so there is no responsibility of handling the response data.

I would say it depends on how much data you're sending across the wire as you put it. If you're implementing a "load more" feature then it seems like you wouldn't want to take 5 seconds to load something. Google images is a good example of how quick that feature should be. If you know you'll never have that much data then rendering the partial on the server might be cleaner, but if you're requirements change then it's a hassle to go back to the first approach. So in short, I'd say the first approach allows for more disaster control as far as how long a load more takes to load a large amount of data. I'd say it's also general good practice to take load off server when you can, even if it's a little inconvenient on the client side for the developer.

Which is better: HTML rendering on server or on client in JS?

I have a best practices/performance question. I am creating an ASP.NET MVC 2 project, and I have several parts of the page that are accessed dynamically either at load time or on user interaction.
My question is this: is it better to have the sections rendered in HTML on the server and then just replace the sections of HTML or is it better to just retrieve the information as JSON objects and then use JS to create and insert the HTML?
It should be noted that the objects of concerns are very simple in nature. An example would be a 'message' object that has an ID field, a to field, a from field, a subject field and a body field that are all strings.
Are there some serious advantages or disadvantages to either approach? Or is this a case of preference to how to construct your application?

Consider the following questions:
Will there be any advantage of having the raw data on the client? In some cases other parts of the page use the data. In these cases it may make more sense to send data over the wire.
Are there potential performance differences? Consider the total pipeline. Sending HTML can be verbose, but is rendering faster on the server? Can the rendered HTML be cached on the server?
If neither of these push you in one direction or another, then I choose the more maintainable code base. This will depend not only on the specific problem, but also on the skillset of the team.
Bob

I don't think either are better; it's going to depend on your requirements. The question is borderline unanswerable. Are you using the data on the client for further computation or manipulation or are you just plopping something out to be displayed?
In both cases you're outputting textual data, though it happens to be easier to represent data structures as JSON more directly than it is to convert data structures to HTML and it's easier to directly display HTML than JSON.

Many frameworks have relatively slow render libraries (the View portion of Model-View-Controller architecture.) The reason is that the render library needs to parse/execute a View domain-specific-language to substitute variables, etc.
Depending on your app's scale, it can be much faster to have the client's browser execute the render. But moving the View computation to the client can be tricky to do in a consistent way.
Google's Closure compiler includes a template library. Another option is liquid. It has a Javascript, .Net and Ruby implementation.

As Jonathon has said already, I don't think there is a simple yes/no answer to your question.
The only factor that hasn't been mentioned already is that server side execution is more predictable, whereas client side execution is out of your control and may vary depending on the browser. This may practically not be a factor on an intranet site, but can become important if the audience is diverse. Modern Javascript libraries usually (not always) shield us from browser quirks, but older browsers could have specific performance issues as well (performance really shouldn't be your primary criteria though, unless you try it out and it's horrendous).
Picking the solution you feel the most comfortable implementing might very well be the way to go.