So normally I would only use JS to modify the dom after the user interacts with something or some event goes off. This seems right for some reason.

But I'm developing a widget based app where widgets need the capability to draw (print) themselves and it feels redundant to send the widget's html via the initial http request when I can just print them with the js method when the page loads.

Should I be trying to avoid printing html elements with JS on the page load as a rule or is it just an optimization thing?

2 Answers 2


It depends.

Unless client-side performance is an observable concern, focus on maintainability.

That means you ideally want the translation from data to markup/DOM to be consolidated. You don't want two or three different objects, especially sitting in two or three different languages, that are each responsible for producing the same DOM structure.

If your client-side script provides progressive enhancement or needs to be crawl-able/scrape-able/Googleable, render HTML server-side. Write your server-side components in a highly modular fashion: Be able to request new markup for a single component quickly and easily. And depend as minimally as possible on direct client-side manipulation of the DOM.

Alternatively, if your app is "highly interactive" or dependent on client-side script, the server probably doesn't need to know anything about the final markup/DOM as it pertains to these interactive components. Send "bare" markup, XML, or JSON for your JavaScript library to consume and display.

Don't spend time optimizing for client-side rendering performance unless it's a known issue.

If you have doubts, and even if you don't, model your app after another successful app that's similar. Open your browser's network profiler and see what comes over the wire and when.

Personally, I've been tending towards client-side DOM construction and have found even the more ancient devices, running modern browsers, perform perfectly well using this strategy. The burden on keeping my client-side code and server-side code is greatly reduced.

  • I think I like this approach the best. I'll start with a client side approach and optimize later. The app requires a login to use so it isn't crawlable and I've given up any idea of making it no-script friendly.
    – DanielST
    Commented Jul 8, 2014 at 12:47

For those who are looking for the quick answer

Avoiding writing anything that modifies the JS DOM is always good practice, unless you have a good handle on exactly what is or is not going into the page, your likely going to run into a lot of trouble.

If you want the longer answer, keep reading

Unless your code and html is encapsulated in the new web component architecture, then when ever you call one of the various JS output methods, that's likely to modify anything the rest of the page flow may depend on, you're going to halt the DOM renderer and force it to wait while it checks everything.

Even if what you print out is not going to interfere with other elements in the page, the DOM renderer doesn't yet know this, (especially if it's still constructing things) and so will pause while it double checks what it does already know.

There are ways and means to mitigate this, for example you could output everything into a sandboxed I-Frame, then the only renderer that gets paused is the one in the I-Frame, or you can make sure that your script runs before anything else ever, produces its output, but keeps it hidden until the rest of the page is created.

Another reason that folks often overlook are things like Google advertising elements.

GAd's do some very, very funky stuff with the DOM, including busting themselves out of I-Frame containers and up the page tree to sit above other elements, so they can interact with them.

In a project I worked on previously, we where doing a LOT of work in this area, and the trouble GAd's caused us in scenarios like this was nothing short of maddening. And it's not just GAd's there are other things too, widgets from other providers, map widgets, web components and various scripts that try to hook up to things in sneaky ways.

Unless you know every single line of code your including in your page (Including that in 3rd party scripts) I'd strongly advise against doing this.

If your target is modern HTML5 based browsers and you don't care much for the older ones, then you might want to consider using the newly emerging web-components standard. It's designed exactly for this kind of scenario and is designed from the ground up to make sure you can wrap anything you need in your own little JS world and not harm anything running in the browser. This new technology is what makes things like the new Video and Audio players available with their own controls and skinning capabilities.

If you use 'PolymerJS' or 'X-Tags' to support your efforts, these things will work across the board right now, and adapt to use native features as the browser manufacturers start to enable this in their browsers.

If you're using Polymer, then even though officially the Docs state IE 10 or higher, you can get support using it all the way back to IE8, Chrome 30 and I cant remember the exact version, but a few versions back on Fire fox too.

If you're not able to use the newer web-component architecture, or you have to support really old browsers, and need to write contents out, then the absolute safest way is to lock your script away inside an I-Frame and keep it as physically separate as you possibly can from the rest of the page DOM.


Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.