Client-side or server-side processing?

views:

270

answers:

+8 Q:

Client-side or server-side processing?

So, I'm new to dynamic web design (my sites have been mostly static with some PHP), and I'm trying to learn the latest technologies in web development (which seems to be AJAX), and I was wondering, if you're transferring a lot of data, is it better to construct the page on the server and "push" it to the user, or is it better to "pull" the data needed and create the HTML around it on the clientside using JavaScript?

More specifically, I'm using CodeIgniter as my PHP framework, and jQuery for JavaScript, and if I wanted to display a table of data to the user (dynamically), would it be better to format the HTML using CodeIgniter (create the tables, add CSS classes to elements, etc..), or would it be better to just serve the raw data using JSON and then build it into a table with jQuery? My intuition says to do it clientside, as it would save bandwidth and the page would probably load quicker with the new JavaScript optimizations all these browsers have now, however, then the site would break for someone not using JavaScript...

Thanks for the help

+1 A:

It is much better to do the heavy lifting on the server side.

In CodeIgniter you create a view, looping through all the rows in the table adding in the classes or whatever else you would need. There is no reason at all to do this in Javascript.

Javascript is a sickly abused language with unfortunate syntax. Why on earth would you want to load a page, and then issue a AJAX call to load up some JSON objects to push into a table is beyond me. There is little reason to do that.

Javascript (and jQuery) is for end user enhancement. Make things slide, flash, disappear! It is not for data processing in even the mildest of loads. The end user experience would be crap because you're relying on their machine to process all the data when you have a server that is infinitely more capable and even designed for this specifically.

Josh K 2010-06-17 17:31:22

Really? This surprises me. Basically, I'm creating a small running log website, and this will accumulate a TON of workouts and information. I would think pushing all of that information to the page pre-formatted would take a long time compared to say, pulling 10 entries, formatting it, and then pulling 10 more if the user clicks "Next"

Nick 2010-06-17 17:37:31

@Nick: Note my other comment. PHP is *much*, **much** faster at formatting then Javascript.

Josh K 2010-06-17 17:39:15

@Nick, an app like what you are building is a perfect use case for JS enabling it... and it can be built quite fast on the client side.

Doug Neiner 2010-06-17 17:40:31

@Josh K but if the connection is slow, and you are sending an exponentially large amount of data (than say, JSON), whatever gains you think you are seeing are removed by the connection speed. Especially where Wireless devices are concerned, send less, not more.

Doug Neiner 2010-06-17 17:42:01

@Doug: He's talking about using the "latest technologies" and mentions AJAX. I doubt that the server load would be decreased *by any reasonable amount* by offloading this to the client side.

Josh K 2010-06-17 17:43:05

@Doug: Where is this "exponentially" large amount of data coming from? He's just sending ten rows! Click next and use an AJAX fetch to load another ten. **Do not use javascript to format HTML**.

Josh K 2010-06-17 17:44:06

@Doug Neiner: If you're sending that much data, it's less likely that it's formatting but more likely to be actual content, which will be almost the same size anyways if you transferred it via JSON. And I sure wouldn't want to use all my phone's memory to process huge webpages because the webmaster doesn't want to use his server resources.

animuson 2010-06-17 17:45:08

@Josh K, at 10 rows I agree it would be negligible, but depending on the formatted markup, you could be sending as much as two times the data to send formatted markup as unformatted. And utilizing proper techniques on the client side it can be done quickly, and effectively. Also, putting a dogmatic statement in bold **does not make it correct**, only that you feel strongly about it.

Doug Neiner 2010-06-17 17:49:52

@animuson I think you forget how much extrapolated content we build on the server. There are class names, and id's and formatted time stampts, etc. All of which can be built with a much smaller subset of data than a fully formatted table, or list, or whatever. I honestly don't think you would really know the difference between your phone taking a while to download a huge amount of formatted data, or taking a second to process a much smaller subset and render it. If you know what you are doing, speed on the client side becomes a much smaller issue.

Doug Neiner 2010-06-17 17:53:43

@Doug: You're still talking about a negligible amount of markup. Why don't we just send JSON objects and let Javascript sort everything out? Because it's faster. It's more reliable. And there is *little or no* increase in speed. If anything there would be a *decrease* do to the amount of client side processing you have to perform. Take a look at the size of a properly gzipped web page and let me know if you want to quibble over a few bytes of data.

Josh K 2010-06-17 17:53:59

@Doug: That would of course require you know what you're doing. I suspect the asker doesn't particularly.

Josh K 2010-06-17 17:55:00

Yeah, I'm sort of new.. but I do know how to gzip the page!I was just thinking of Gmail as an example. Like when you're looking at the list of emails and you press "Older", does Gmail pull an already formatted list, or does it pull the subjects and sender and then apply the style to it once it's there?

Nick 2010-06-17 17:57:29

@Josh K, front end technology is really what I love. I work with the server all the time as well, but how will people like the OP ever learn if all they hear is the same outdated info you are presenting in your answer and these comments. JS is not just for making things "slide" flash or pop, it can be used for so much more. But I suspect you don't understand that because you think that: "Javascript is a sickly abused language with unfortunate syntax."

Doug Neiner 2010-06-17 18:00:22

@Doug: To call PHP or *anything* server side *"outdated info"* demonstrates a huge lack of knowledge.

Josh K 2010-06-17 18:03:07

@Josh K, you misunderstand my comments. The outdated info was these statements you made: "There is no reason to do that **at all, ever**", "**Do not use javascript to format HTML.**", "It is not for data processing in even the mildest of loads."... All of these statements are fundamentally incorrect, misleading, and as I said before, outdated.

Doug Neiner 2010-06-17 18:06:03

@Josh K, Google does apply the style client side. Your guess is incorrect, as Google sends JSON responses to its server calls, and renders it on the client.

Doug Neiner 2010-06-17 18:08:18

@Doug: Which would explain why I always felt Gmail was a bit sluggish.

Josh K 2010-06-17 18:09:47

@Josh K, I imagine it would feel a lot more sluggish if they were pre-formatting the amount of data they send in a single request.

Doug Neiner 2010-06-17 18:13:46

@Doug: There is little if no reason. There are cases where it is appropriate and you have fall backs. This includes an alternate version of the site if need be, see Gmail's plain HTML view.

Josh K 2010-06-17 18:14:14

@Josh K: I find the plain HTML view to load faster for me than their standard view, which is why I use it.

animuson 2010-06-17 18:18:27

@Doug: I'm not sure why it would feel more sluggish. As mentioned you can gzip any content you have to send from the server, it's just text, and therefore highly compressible. Have you run any side by side comparisons that I may see?

Josh K 2010-06-17 18:18:58

@Josh K I'll put together some benchmarks when I have time. I'll do tests with 10, 100, and 1000 rows of data, though the 1000 rows is a little extreme. I would be curious to see in which cases one method is better than the other, or if they are all better on the server or vice versa.

Doug Neiner 2010-06-17 18:28:53

@Doug: I'm interested as well. I'm not opposed to changing my mind, I just would like numbers to reinforce the position.

Josh K 2010-06-17 19:15:32

@Doug, @Josh K: Servers are HTML agnostic, so iterating through objects from memory and putting them down in JSON versus HTML is comparable (and relatively minimal in comparison with other server-side processes). Similarly, so long as you're using a modern browser, rendering either also takes a negligible amount of time. Pre-empting even one reasonably complex database query will result in a performance increase orders of magnitude higher than the choice of JSON vs HTML.

Steven Xu 2010-06-18 14:42:01

@Steven: Yes, limiting the results at the database (query) level would be the best option.

Josh K 2010-06-18 15:32:41

+2 A:

It's better to do as much as possible on the server-side because 1) you don't know if the client will even have JavaScript enabled and 2) you don't know how fast the client-side processing will be. If they have a slow computer and you make them process the entire site, they're going to get pretty ticked off. JavaScript/jQuery is only supposed to be used to enhance your site, not process it.

animuson 2010-06-17 17:32:08

@Nick: That's a query issue. Add a `LIMIT 0,10` to grab the first ten entries. `LIMIT 10,10` for the next ten. `LIMIT 20,10` for the ten after that. There are smarter ways of doing this then using AJAX to load data and process it.

Josh K 2010-06-17 17:36:23

@Nick: No, PHP will be a lot faster at formatting. You can pull 10 formatted entries and just paste them into the site with JavaScript. That will be much faster than processing them with JavaScript.

animuson 2010-06-17 17:37:01

Oh okay.. everyone seems vehemently opposed to using JavaScript, so I suppose I will go the route of the experts. Thank you!

Nick 2010-06-17 17:39:12

@Nick: No so much vehemently opposed to using, simply vehemently opposed to it's misuse.

Josh K 2010-06-17 17:44:41

Many giant, yellow boxes containing Noscript icons = Abandon hope all ye who enter here. Even more frustrating when you fill out a form in it's entirety, click submit, and nothing happens. Why link form submissions to validation via javascript only, when you could just as easily let me pass and do it server side?

bob-the-destroyer 2010-06-18 01:11:48

+2 A:

You got the trade-off correctly. However, keep in mind that you can activate compression in the server side, which will probably make adding repetitive markup to format the table a small bandwidth cost.

Keep also in mind that writing Javascript that works in all browsers (including hand-helds) is more complicated than doing the same server side in PHP. And don't forget that the "new JavaScript optimizations" do not apply to the same extent to browsers of handheld devices.

Artefacto 2010-06-17 17:35:06

Nor do they apply to IE6 (or 7), which is sadly still quite common.

Frank Farmer 2010-06-18 06:44:30

+2 A:

It depends on your target market and the goal of your site.

I strongly believe in using the client side where ever you can to offload work from the server. Obviously its important you do it correctly so it remains fast for the end user.

On sites where no-js support is important (public websites, etc), you can have fallbacks to the server. You end up doubling code in these situations but the gains are very beneficial.

For advanced web applications, you can decided if making JS a requirement is worth the trade of losing a (very) few users. For me, if I have some control over the target market, I make it a requirement and move on. It almost never makes sense to spend a ton of time to support a small percentage of potential audience. (Unless the time is spent on accessibility which is different, and VERY important regardless of how many people fit into this group on your site.)

The important thing to remember, is touch the DOM as little as possible to get the job done. This often means building up an HTML string and using a single append action to add it to the page vs looping through a large table and adding one row at a time.

Doug Neiner 2010-06-17 17:39:14

Doug, is there any reason why you suggest not to touch the DOM? I've always felt much more comfortable sending JSON representations of what I want added to a page (for instance when a user loads a next set in a paginated list) and have the browser put it together in HTML that producing the HTML segments server-side. It seems to me violate one of the desired principle of an AJAX site, which is to split off logic from presentation with the AJAX listener as the translator.

Steven Xu 2010-06-17 17:52:18

@Steven Xu, I completely agree with you. The bulk of what people say is "slow" in browsers, is when you add, say, 100 rows, but you do it one at a time. That is 100 `appendChild` calls, with info. I am just saying, build a HTML string in JS, and make a single call to append it to the page in one action. This allows the browser to do the heavily lifting only once. And if you do it right, its not even heavy, it is simply a `innerHTML = ` statement, and the data is added.

Doug Neiner 2010-06-17 17:55:49

@Doug: But the actual processing is dead slow. Maybe not so apparent at 100 rows of data, but compare backend processing with client side processing and the backend wins every time.

Josh K 2010-06-17 18:05:40

@Josh K, but you are not comparing apples to apples. Making pizza is faster at a Pizzeria than at your house, but you have to consider travel, tipping the driver, etc. There is always more at stake than simply "processing the data".

Doug Neiner 2010-06-17 18:10:10

@Doug: Now you're muddying the waters. You're talking about paying a driver to drive from the Pizzeria to your house with the ingredients (don't for get tip!) and *then* making the pizza yourself.

Josh K 2010-06-17 18:12:43

@Josh K, haha, I have never been great at examples :P I'll need to find a different one :)

Doug Neiner 2010-06-17 18:18:49

"offload work from the server"? Servers are cheap. And slapping a few HTML tags together is one of the easiest parts of rendering -- it's collecting all the data necessary to build the page that takes a long time. And don't forget, the vast majority of page render time is on the client side to begin with.

Frank Farmer 2010-06-18 06:43:11

+4 A:

Congratulations for moving to dynamic sites! I would say the following conditions have to be met for you to do client-side layout (it goes without saying that you should always be doing things like filtering DB queries and controlling access rights server side):

Client browser and connection capabilities are up to snuff for the vast majority of use cases
SEO and mobile/legacy browser degradation are not a big concern (much easier when you synthesize HTML server side)

Even then, doing client-side layout makes testing a lot harder. It also produces rather troublesome synchronization issues. With an AJAX site that loads partials, if part of the page screws up, you might never know, but with regular server-side composition, the entire page is reloaded on every request. It also adds additional challenges to error/timeout handling, session/cookie handling, caching, and navigation (browser back/forward).

Finally, it's a bit harder to produce perma-URLs in case someone wants to share a link with their friends or bookmark a link for themselves. I go over a workaround in my blog post here, or you can have a prominent "permalink" button that displays a dynamically rendered permalink.

Overall, especially when starting out, I would say go with the more kosher, better supported, more tutorialed, traditional approach of putting together the HTML server side. Then dip in some AJAX here and there (maybe start out with form validation or auto-completion), and then move on up.

Good luck!

Steven Xu 2010-06-17 17:46:44

+1 Great answer Steven, really well thought out.

Doug Neiner 2010-06-17 18:01:28

I do a great deal of AJAX app development and I can tell you this from my experience. a good balance between the two is key.

do the raw data server-side but use javascript to make any modifications that you would need to it. such as paging, column sorting, row striping, etc.

I absolutely love doing everything in AJAX heh.. but there are some short falls to doing it using AJAX, and that's SEO. search engines do not read javascript, so for the sake of your website's page rank, I would say have all data served up server side and then formatted and made look cool client-side.

The reason I love AJAX so much is because it drastically speeds up your APP usage by the user as it only loads the data you need to load where you need to load it, versus load the entire page every time you do something... you can do a whole bunch of stuff, such as hide/show rows/columns (we are talking about table manipulation here because you mentioned a table) and even with these show/hide actions add delete actions where when you click a delete row or button it deletes that row not only visually but in the database all done via AJAX calls to server-side code.

in short.

raw data: server-side sending to the client the raw data in html layout (tables for table structured data, however I do everything else in divs and other flexible html tags, only do tables for column/row style data)

data formatting: client-side which also includes any means of interacting with the data. adding to it, deleting from it, sorting it differently etc. This achieves two things. SEO, and User Experience (UX).

JSD 2010-06-18 00:19:37

ansaurus

tags:

views:

answers:

Client-side or server-side processing?

related questions