2

This is a design question. I find myself going back and forth between two UI design styles.

The UI on a prototype I developed recently relied heavily on loading the elements of the UI as partial views via AJAX. I did not like that approach because I had to do a lot of requests to the server while my page was loading. However, the plus of this design was that I could easily edit the partial view templates, so the code was easier to manage.

In the next iteration I decided to package all the information at once and then use JavaScript to generate partial views and plug this information into it (and only use Ajax when on-demand up-to-date information was actually needed). My page loads faster, but I find myself generating a lot of HTML snippets in JavaScript, which is getting harder to manage.

As I see it, using Ajax you get:

  • Easier to maintain (+)
  • Longer UI response times (-)

And with JavaScript only, you get

  • Faster UI response (+)
  • Easier to handle server-side errors (+)
  • Harder to maintain (-)

So, There are a few things on which I would like to hear your comments:

  1. I do not like using Ajax unless I don't have a need for actual on-demand data. Am I wrong?

  2. Are there frameworks/libraries that would make managing HTML-generating JavaScript code easier?

  3. Are there any other pros/cons of the two approaches that I have missed?

Thanks,

Improve this question
5
  • 1
    There are jQuery templating systems that help generate the HTML client-side, but this has a terrible SEO consequence. Building systems where the data is passed to the client using JSON and building the entire UI client-side are pretty fast since the data is was smaller than the equivalent HTML, but the SEO issue remains. Commented Aug 17, 2011 at 21:14
  • @Diodeus: SEO is not an issue for this particular site. However, what do you mean, exactly? Isn't it possible, in theory, to generate client-side HTML that works well with SEO? Commented Aug 17, 2011 at 21:24
  • 1
    I'm guessing the issue to be that search engine spiders don't have JavaScript enabled, so they don't see client-side generated HTML. Commented Aug 17, 2011 at 21:29
  • Ah, yes. There's that :) Commented Aug 17, 2011 at 22:03
  • All search engines see is what you'd get if you did "view source". Anything manipulated after that is lost. There are ways around this such as hash-url. Commented Aug 18, 2011 at 15:43

4 Answers 4

Reset to default
1

There are templating libraries for JavaScript, if you want to get that involved. In general I would avoid manually sticking together HTML strings from JS unless there's a particular need to (eg in some cases for performance when dealing with very large tables).

HTML-hacking is difficult to read and prone to HTML-injection security holes when you don't get escaping right.

Start instead with the DOM methods, and use DOM-like content manipulation libraries to make it easier. For example, if using jQuery, do this:

$('<a>', {href: somelink, text: sometext})

and not this:

$('<a href="'+somelink+'">'+sometext+'</a>')  // insecure mess

There doesn't need to be a big difference between fetching data through XMLHttpRequest vs including it in the HTML document itself. You can direct a bunch of JSON data to the same function that will build page parts whether it was just fetched by XMLHttpRequest in an update operation, or included in function calls at document load time.

When including data in the page you will generally need to include a timestamp they were generated in any case, so that if the browser goes back to the page a while later without reloading it, the browser can detect that the information is now out-of-date, and cue up an XMLHttpRequest to update it.

The usual question when you're creating your page content from data with client-side JavaScript is, are you going to fill in the initial static HTML version from the server too? If so, you're going to be duplicating a lot of your content generation work in both client-side JS and the server-side language(*). If not, then you're making the content invisible to non-JS user agents which includes search engines. Whether or not that matters to you typically depends on what the app is doing (ie does it need to be searchable and accessible?)

(*: unless you can use server-side JavaScript from something like node.js and re-use your content generation code. This is still a somewhat rare approach.)

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

Why not look at integrating require.js into your workflow? I'm not entirely sure how it would work with templates, but included in their pipeline is the ability to package all required script files into a single .js to be served by a single server request/response.

Improve this answer

Comments

1

I have no personal experience about it, but Closure looks promising. The thing about its templates being usable on both server and client side might be of interest to you. Here is what was said about using it in Google+:

The cool thing about Closure templates is they can be compiled into both Java and JavaScript. So we use Java server-side to turn the templates into HTML, but we can also do the same in JavaScript client-side for dynamic rendering. For instance, if you type in a profile page URL directly, we'll render it server-side, but if you go to the stream say and navigate to someone's profile page, we do it with AJAX and render it client-side using the same exact template.

Improve this answer

Comments

1

When working with remote data after a page is loaded, for small datasets I prefer returning data only and adding to the UI with templates.

For large datasets, I recommend using your partial views to render the html on the server to reduce overhead in the client as @bobince mentioned.

For client-side state tracking, check out Knockout at http://www.knockoutjs.com. It uses an MVVM approach with data models bound to UI elements and makes it very simple to send the data back to the server via AJAX. It works with the jquery.tmpl template library out of the box or you can integrate another library of preference with a little more effort.

As far as managing templates, it's easy enough to store common templates in an object, either on the server to be retrieved with your remote data, or in a javascript object on the client.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.