View Full Version : Which is faster - PHP or Javascript

07-13-2005, 02:28 PM
I know this is comparing apples and oranges, one is client side and one is server side. But say I am making a randomizing script. I can do this in either PHP or Javascript, and the first time through I chose JS. I am redoing things now, and need to know is one better than the other (speed wise)

07-13-2005, 02:40 PM
PHP, because the user might not have JS installed or enabled. it's the kind of script which is somewhat superfluous and is therefore best done serverside.

07-13-2005, 06:35 PM
Thank you, I will go and do it in PHP then :).

06-30-2006, 09:02 AM
For this kind of script I'd definately go server side as well.

But in general, i'd try to use both for certain types of scripts. But never base my core functionality on Javascript, hench scripting being disabled on some machines.

Majority of machines have Javascript enabled, so catering for them, should give you better performance in certain cases - but still base core functionality server side.

But ya, this all is obvious, just stating the obvious hehehe.

06-30-2006, 10:37 AM
If you need speed, in theory any server-side language is faster than javascript. This advance reduces considerable in case of repeatedely submits/change of sessions, as user have to wait a wile the server response.

In fact there are few things where php (or any server-side language) and javascript chalanged, for the simple fact that they were designed for different purposes. Usually, a developer uses succesfully both languages.

Bill Posters
06-30-2006, 11:07 AM
PHP, because the user might not have JS installed or enabled. it's the kind of script which is somewhat superfluous and is therefore best done serverside.

Personally, I'd consider 'superfluous' scripts best handled client-side where possible. Why load the server with tasks which aren't critical to the site?

(However, depending on the criticality of the random effect, I'd still be inclined to go server-side.)

06-30-2006, 11:34 AM
See, if i look at the whole postback structure thing they've got going on in asp.net for example, lets think about the Calendar for example.

Each time you click on a date item, a postback occurs.... which in itself is a waste, a lot of components does this, cause they rely on the viewstates, which requires postbacks.

Lot of this can however be done client side, and simply be submit, when the user is done with the current page - They are using a lot of javascript in there already in anycase for their components, why waste it on going up and down to the server all the time?

06-30-2006, 11:41 AM
If you need speed, in theory any server-side language is faster than javascript.

Interesting comment, i doubt one can really compare client side scripts and server side scripts with each other....

If you want to compare it looking at the postback issue doing simple tasks, javascript wins, since you can do 1 postback once you're done, instead of doing 1000 for simple tasks.

But other than that.... cant really compare them.

06-30-2006, 04:17 PM
Actually, in theory, putting off more processing onto the client is more efficient. In reality, however, this is not the case.

The theory is that if you have 10,000 tasks, for example serving 2 page loads to 5,000 clients, then what's more efficient, processing 100% of 10,000 tasks on one centralized server (could be a farm, granted) or processing 5% of 10,000 tasks on the centralized server and 95% of 10,000 tasks on 5,000 machines (the clients). In theory, passing the processing off to the client is more efficient.

But the reality is that browsers are slow. None are designed with dynamic content in mind as the most important thing. The most effort on speed goes into rendering a static page, because that's the staple of the internet. The reality is that the clients are almost exponential in the extra time they take to process logic for dynamic page rendering when compared to preprocessing it on the server.

So, for many many things, at this point in time server-side processing is simply more efficient, barring all discussion of security and consistency for the moment. But there are many ways to use the client properly, that use the clients' strengths and mitigate their weaknesses to increase the efficiency of the system over all. Your example of ASP controls constantly posting back is an example of bad system design, not a question of which is faster server or client. If your server is only interested in certain pieces of information, and multiple steps are required to collect that information, figuring out a way to collect it all and preprocess on the client efficiently is always better than making multiple round trips to the server for it. And that's because the theory is sound, and it can be executed properly sometimes. It IS always more efficient in theory to off load processing to the clients. Our job as programmers is to determine when the theory and the reality line up, and when they do not.

06-30-2006, 11:08 PM
This question is like asking whether a car or a plane is the better form of transport. You wouldn't use a plane to visit the next su8burb and you wouldn't use a car to travel half way around the world.

Similarly if you are talking client side processing Javascript is much faster since PHP doesn't run at all. For server side processing PHP is much faster since Javascript doesn't run at all. For Ajax processing you need both and trying to use just one or the other wont work so neither is faster there either.

06-30-2006, 11:29 PM
The title of the thread and question in the poll are definitely meaningless as you state, but the OP's post clears up his question. He's trying to figure out what's faster, doing things client side or doing things server-side.

I think his question can be stated easily this way:

"Barring security and data integrity, is it faster to do logical processing on the server or the client?"

It just seems that the OP uses JavaScript to mean "client-side processing" and PHP to mean "server-side processing". I think it's clear from his posts that he is using his terms loosely.

I hope that this thread not only clears up the various options, pros, and cons for people, but also helps them learn to speak clearly, and differentiate their terms properly so they can participate more effectively in technical discussions such as these.

07-01-2006, 02:31 AM
Doing things client side is always faster because it avoids the round trip to the server. Doing things server side is always needed as at least some of your visitors will not be able to run the client side processing and some things can't be done client side.

The best way to handle this is to create your pages using server side processing so that they work that way then add javascript to speed up the processing where the trip back to the server can be avoided but leave the server side version untouched so that it still works without Javascript.