Question

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,

Answer 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.)