I agree that there are a lot of factors to consider. Here's an idea of the list I went through with a former colleague when he was looking at building a very dynamic web application:
Payload - the json is likely to be smaller than the full html, although the difference is usually lessened after gzip. Accessibilty - how much behavior do you want to work without JavaScript? If it's "a lot" or maybe even just "some" then you'll need to be rendering the same DOM both server side and client side. SEO - see accessibility above; goggle's solution relies on you serving HTML from the server side to spider ajax delivered content. Maintenance - as mentioned elsewhere, it can become difficult & time consuming to make changes to content structure so you really only want one method of turning data into html. - the same goes, although more so, for application logic. You really don't want to be creating the same routines in two places if you can avoid it. In the end the team went with a quite interesting solution that suited their various skill sets, and the group's previous efforts by serving RDFa (HTML with a consistent and parsable set of data in it). If you're interested you can see it here: http://www.bbc.co.uk/music/showcase Another option that gets round quite a lot of the concerns above (although not those around maintenance of application logic) is to use the same re plating system at both the server and client side with something like Mustache. By sharing templates, you are simply creating a standard data object for a piece of the page, and either handing it off to the template parser at the server side or encoding as json and sending it down the wire to let the JavaScript use exactly the same template at the client side. If you look at this option you'll definitely want some kind of optimization-friendly JavaScript loader that can inline all of your template files for (my favorite is RequireJS), but that's just one of the things you'll need to deal with. Best Pete On 10 Sep 2011, at 14:54, Samuel Richardson <[email protected]> wrote: > There's a lot of factors to take into account, but if you have control over > the entire environment then I find working with JSON that's transformed using > JST templates to be the most flexible way of doing things. > > That being said, there are cases for the server rendering HTML and the XHR > request inserting it into the page (also, jQuery's live binding can be very > helpful in this situation). The server might be configured already for > rendering HTML server side, it might be pulling content from existing > templates in other areas or in some cases, the backend team might just not be > very good or unable to handle JSON for whatever reason. > > For applications that are very programmatic, one page applications for > example, transforming the JSON client side is a must. For more static > applications, you can use the HTML bound with live events instead. > > Samuel Richardson > www.richardson.co.nz | 0405 472 748 > > > On Sat, Sep 10, 2011 at 10:50 PM, Martin <[email protected]> wrote: > From a separation and maintenance point of view (I'll leave others to discuss > performance), having a server generate HTML is definitely a bad thing. I'm > working on a several-year-old website at work which has elements of modern > Dojo-based JSON REST services but also older XSLT-generated server-side HTML > generation that's then replaced client-side, and I can assure you that fixing > bugs or altering the code in the old server-generated HTML "bit" is much, > much harder work. > > > On Sat, Sep 10, 2011 at 11:44, Mo Cheng <[email protected]> wrote: > Hi All, > > In highly AJAX-ified web site, XHR is used to update part of page, which > basically update partial HTML tags. Then we need to make a decision: > Should server render the HTML and sent in XHR response? or Should server just > return JSON data and have browser JavaScript render HTML according to JSON > data? > > Anybody has experience in both approaches? Which is more performant? > > > Thanks, > -Morgan > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
