Let's assume you want to change what user sees on the website.

There are two ways to do that:

a) manipulate the DOM via JavaScript, but user has to download whole script, with possibility he may not need that script. More bandwidth is wasted. Also this limits what you can display.

b) rebuild the whole page on demand (ie user input/click) via PHP (or simmilar server-side language). This way, you have to reload the page, yes, but you did not have to download any additional data prior to that and you can always use caching if you have resource heavy images, etc.

And let's discount situation where server-side data manipulation is only option for security/validity reasons.

  • In addition to my answer, why that focus on bandwidth? That would definitely not be my first criteria.
    – gvo
    Jun 23, 2016 at 13:29
  • @gvo Downloading >100kB of JS is still lot to ask for a mobile users, if you are already doing what you can to serve them minimal CSS and images. Most mobile connections have FUPs <50MB, so asking so much useless data is really not great for user experience. On desktop it does not matter of course
    – The Law
    Jun 23, 2016 at 13:32
  • @TheLaw Surely you only have to download it once. Jun 23, 2016 at 13:42
  • I'm not sure sending a lot of similar HTML multiple times is that much better, but I don't have the figures. Also, it seams possible to do some lazy loading of the JS code (but never tried). If mobile is your preoccupation, have you considered doing an app the user can download when he has wifi instead?
    – gvo
    Jun 23, 2016 at 13:53

1 Answer 1


Both solution are viable, they simply don't apply to the same use-cases.

a) manipulate the DOM via JavaScript : This result in a more heavy first page, but after that you will use less bandwidth, because you will only fetch what you need, and not rebuild and send everything. And in the cases where you don't need to fetch anything, it will be really quick (pre-validation of a form for instance).

b) This is the old traditional way to do web-applications. It is still valid a valid way to do web sites, let's just have a look to why most people are changing their way.

Doing stuff client-side allows faster rendering when the user makes an input. It also reduces the resources needed by the server. And finally, by fetching data only on a webservice, you provide something that might be reusable by other systems. That's why those solutions are getting more and more popular. It comes at a cost, not everything can be done on the client (validation/security) and you often need to deal with different technologies as well as more numerous interfaces.

I'd just like to add that you don't need to do everything with one solution or another, you can mix both approaches, on some event manipulating the DOM, on some other reloading the page.

EDIT : Since bandwidth seems to be a very strong concern, you can loose some of the user-reactivity by loading the JS code only when needed with solution a. See this example of lazy loading in JS Probably the more efficient design if you consider mainly/only that aspect.

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.