When should JavaScript generate HTML?

Question

I try to generate as little HTML from JavaScript as possible. Instead, I prefer to manipulate existing markup whenever I can and only generate HTML when I need to dynamically insert an element that isn't a good candidate for using Ajax. This, I believe, makes it far easier to maintain the code and quickly make changes to it because the markup is easier to read and trace. My rule of thumb is: HTML is for document structure, CSS is for presentation, JavaScript is for behavior.

However, I've seen a lot of JS code that generates mounds of HTML, including entire forms and content-heavy modal dialogs. In general, which method is considered best practice? In what circumstances should JavaScript be used to generate HTML and when should it not?

Answer 1

Whenever I have encountered heavy HTML generation in javascript, it was almost solely in a stand-alone UI plugin. It makes sense, as it allows to encapsulate the entire plugin in a single .js file (+ a .css to customize styles), thus making it easily reusable, distribuable, and independent from the framework used in the application.

So if you're writing a stand-alone javascript plugin or a generic UI component which you would like to use across different applications, such an approach has its upsides. Otherwise, I think it's both cleaner, easier to write and easier to maintain when you keep html generation away from javascript and on the server side.

Answer 2

I think the problem is that you are comparing cleanly written server side templating to badly written ad-hoc client side HTML generation. Of course the cleanly written code is easier to read, maintain, and trace.

You call the client side code "mounds of HTML", but of course it's the same HTML wherever it's generated. The "mound" is really the big lump of code.

There are lots of client side templating libraries out there. They work similarly to the server side ones. As for which you should prefer, the performance tradeoff is complicated, but JSON is usually more compact than the HTML it becomes and having the template on the client may eliminate some server calls. On the other hand, the client may have JS disabled, or be too slow to be practical, so it depends on your target audience as well. Overall I think the approaches are pretty comparable, with the biggest factor being your target audience's browser capabilities.

But it depends on exactly what you are doing, whether you prefer JS to your server environment, which templating solution you prefer, etc.

Answer 3

There is a trend to use client-side templates, in extreme case you'd have server providing only RESTful API for example in JSON format, while doing all rendering client side. The advantage of that approach is that JS code and templates are static resources that can be cached, proxied and distributed via CDN. Which cannot be done if you have server-side generated dynamic HTML. Also, returning just data from RESTful API in lightweight format uses much less server-side resources, making response faster. Also being lighter it's less network transfer, which again makes it faster. This way you can have very responsive low-latency application even on slow connections such as 3G. Thus this approach is popular for mobile pages and applications.

There are numerous libraries implementing JS templates, one of the popular ones are Pure, Mustache and dust.js. Later is used by LinkedIn, they have described the advantages in their article "Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates".

Answer 4

The advantage of generating HTML on the client, is you offload the rendering work to each client, that sits generally idle waiting for the response. Freeing more server resources to deliver only JSON data and static content(HTML, JS and CSS).

We do a web app that generate exclusively HTML with Javascript. 87% of server hits are JSON data, the static content is generally loaded once, then from the browser cache.

But you can't use it - at least not easily - if you need SEO. Or if you target a population that have Javascript disabled, but I'm not sure this one is still relevant with Youtube, Twitter, Facebook, Gmail,... naturally forcing people to enable it.

Answer 5

Regarding dynamic page loading, one should realize that behind all the "JQuery AJAX Cloud!" magic, only two possible things are happening:

1. An element's code is being injected in a div (bad), or
2. Content is being loaded in an iframe (better, but it's just not the same...)

---

Regarding the original question, I only create HTML content via Javascript when I'm creating a web app of some kind that reads XML or JSON data stored on the server, and it gets changed a lot.

It wouldn't make much sense to load static content on a page with Javascript, as there's always the possibility that it won't load right, or the client will have it disabled ("take that pesky ads!"). In addition, it makes it really hard to change HTML content when it's smushed inside an ugly document.write() or a chain of document.createElement()'s.

So, you are right; either type up the raw HTML, or if dynamic-ish content is necessary, use a server-sided script to output what's necessary. Use Javascript to inject HTML only if the site is meant to work without an Internet connection, or a similar case.

One last note, if you do want to implement xmlhttprequests, er, AJAX, into a website, probably the best/safest way to do it is to store the data in a data format (like XML), load it, and output it accordingly on the client. document.write and element.innerHTML really isn't the best way to go about manipulating content, and is bound to cause potential headaches in the future (why isn't this script running? My broken <i> tag is italicizing everything! etc.).

Answer 6

My mantra on that is: when its easier and nobody cares about the markup.

You can also leverage both and define a limit where its just too difficult to care about the markup and you'd rather focus on the DOM tree. For example, a form that has dynamic rows (e.g. "add another attachment"), you'd probably want the form in HTML, the "add row" button, and the submit button... you probably don't want to generate the HTML with your server-side language or something.

Another rule of thumb can be reusability. If your solution can be applied to other problems on the client side, encapsulate it in js.

Answer 7

We build single-page apps (ala Google Mail) and there is literally no server-side generation of HTML in our apps at all. Instead we're using Backbone.js to structure our client side and Handlebars to render our JSON into templates which go into the page. It works very well indeed and we're coming to the close of our first app which uses it and we'll tackle an even larger project in the future.

Any kind of fat client where the server is used only to persist data and return query results is a poster child for a time where you're going to want JavaScript to generate HTML. Just be sure to use a good template engine to make it clean and easy.

Answer 8

I am generating html code in jquery because I'm using a portlet and after the jsp code execution, I need to make a loop with html code, that I can't get in a java for loop with some javascript code within. So I am rendering java arraylist in a javascript array and the using the strings to generate html.