0

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.

asked Jun 23, 2016 at 13:06
4
  • In addition to my answer, why that focus on bandwidth? That would definitely not be my first criteria. Commented 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 Commented Jun 23, 2016 at 13:32
  • @TheLaw Surely you only have to download it once. Commented 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? Commented Jun 23, 2016 at 13:53

1 Answer 1

3

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.

answered Jun 23, 2016 at 13:29

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.