|
Let me reiterate what Simon Gray said, because I think ColdDeath missed a vital point. PHP, as typically used, is server-side code. It runs on the server, possibly builds a page dynamically, and transmits that page to the client to be rendered. The page, as it lives on the browser, is no longer in contact with the server. There is no interaction beyond what you can achieve by making a new request to the server and getting another page. I don't think you'd want to accomplish mouse interactions in that fashion.
JS (and other scripting languages) runs on the client. Interaction with client-side events is immediate. There is no demand on the server, and no demand on the internet's infrastructure, unless that event requests a new page (or the old page, again).
A lot of people now disable scripting on the client. These people won't be looking at something using the Google Map API, for instance, because the API is implemented in Javascript and loaded as part of the page load.
Another good reason, for example, is client side validation of forms. You always need to validate on the server, also, because forms can be farbled with. Nevertheless, if you validate on the client, you likely won't have to have additional request/response transactons between the client and server just to straighten the dumbass out.
Sometimes these repeated transactions don't seem important in the light of the speeds many people have, connection-wise. Who cares if you go back to the server forty times, if the pages load rapidly? Well, for one thing, not EVERYONE has cable or DSL or similar. Some still have slow modems. For another thing, someone is still paying for the bandwidth you are requiring with the additional transactions. Most web-designers don't pull out the pocketbook -- their client does. If your client ever catches on to the fact you're blowing bucks needlessly, your client will be shopping for a new web-designer.
|