While designing html interface elements it\'s a pretty common scenario having DOMs show/hide depending on certain events. My question is simple, but every time I run into th
performance needs to be considered when working on bigger apps, and when there is no much performance concern while coding smaller ones do what you feel easy and manageable. Very big DOM might kill mobile browsers. A lot of DOM modification can affect performance. In bigger applications it is better to keep DOM light and also reduce DOM modifications. So in a nutshell it's kind of convenience over convention when performance is not closely watched. it is but always recommended to keep a watch on performance and good practices.
Ultimately, it really depends on what you're working with and what your application does, but:
Static markup means more work for the server (but only if the page is generated dynamically in the first place, for static pages the effect is negligible).
Dynamic markup means more work for the client, which is not always a bad thing, depending on your target audience.
Technically, however, Graceful Degradation suggests that static markup is the way to go, as ideally the page should remain usable with scripting disabled (dynamic markup being an optional layer above a working static core).
On the other hand, Progressive Enhancement builds from there and basically says that since we're already working with a bare-bones core, we can fire on all cylinders client-side, and dynamically enhance the static markup with content that takes advantage on the latest browsers' technologies.
For instance, jQuery UI and jQuery Mobile are designed around progressive enhancement, as their strategy is to extend existing markup with richer client-side behavior, generally exposed through dynamically created elements.
So, both options in your title can and arguably should be implemented together. In the general case, and if possible, rendering the markup necessary for your application to work on a scriptless platform, then enhancing that markup from the client side looks like a good idea.