The difference between a client-side language and a server-side language is this:
client-side: Is installed on the clients browser. It can use the info that is passed to the browser only.
server-side: Is installed on the server. It can use all the info stored on the server.
the way it works:
you make a page.
when the browser requests this page, the server-side scripts are executed BY THE SERVER. The result of all these scripts is a nice html document. the server than sends this document to the browser.
the browser loads the page and only then does it execute the client-side scripts..
So, with client-side, you can't, for example, take a file stored on the server, edit it, and save the changes since you only have access to the small bit of html the server gave to the browser.
With server-side, you can't detect events (click of mouse for example) since you only prepare the page for the browser to read and then have no power over it...
I'm not very good at words nor at server and client side technologies, lol, but this is my best explanation. If you need anything more, just tell me and I'll explain furthur with more examples and stuf like that
Ok, i understood that server, and client side differed more or less of where things were located in terms of certain things, like files, and the what not. This part i understand. What i dont understand is how the bounderies are drawn in terms of the conceptual framework. Is it an arbitrary boundery, or a boundary that relates to something revelant?
In other words, i understood that the main difference between a server, and a client side computer is that servers have more horse power as it were, hence why they are used for the storing of massive information that be recieved by a pc. But over, and beyond this, i do not know why a distinction must exist between a client, and a server. The analogy is that the client is like a car that pulls up to a gas station, and gets gas. A server, is the gas station that 'serves' the gas, which is more often than not, the files that are viewed as a webpage, like the actual html file, the images, or the other types of mime type resources, such as sounds, and videos.
But from the perspective of programming, i dont know why a distinction has to be made, since as far as i am concerned all of this is programming, so why must there be a distinction? i dont know if i can better phrase my question, but i am looking for a much more technical explanation than, "well, servers simply have more horse power!" Am i making sense?
The distinction is real. Client side programming works with code that resides on the client. All that is necessary is served to the client by the server. A very solid line and a major distinction.
So in a car..
The server gives the gas to the car.
then, the client, via client-side scripting, can use this gas to, say, accelerate using the onPedalPress event... This, the server (gas station) can't do, of course.
Actually the server owns the blueprints for the car and when you come knocking it instructs the scripting language (php, asp) that resides in the plant to make you a car from scratch! Wanting to take it for a ride depends on whether there is client-side scripting - if there isn't then it is a static piece of junk that will sit there and rust because there was never a gas tank to begin with. You need to create a new car from scratch with a gas tank (js) if you want to cruise Without js, all you can do is look at the thing.
Perhaps the browser can be likened to a parking garage ... one that can hold many vehicles within it.
Perhaps the most important distinction here is that "client side" scripts are served by a remote host which probably doesn't have the client's best interests in mind. Because of that there are severe limitations on what a client side script is allowed to do on client's machine since unresticted scripting would allow the client script to monitor the client's activities and other spying or less than honest activities. If client side script were not restricted, the internet would ba very dangerous place to be indeed.
Check out the Forum Search. It's the short path to getting great results from this forum.
to code JS on the server you'll need a compatible server. this used to be Netscape Enterprise Server, and latterly IPlanet. this has subsequently been bought by Sun, so no doubt it'll have died or be in the process of dying. which is a pity because SSJS was very powerful and probably way ahead of it's time. it preceeded ASP, JSP and PHP as a serverside programming language.
That is because of ActiveX. With ActiveX enabled in IE, you can do anything on the client's computer.
this all depends on the user's security settings. yes, you can do quite a lot, but in many cases the user has to be able to give permission first.
then again, given that M$ have a great deal of problem coding without bugs these days, there are ways to get at the user's machine without their knowledge. but that involves bug exploits and is hacking, which is not something we condone or want to encourage here. so, we'll say no more about it, never mind delve into how it's done.
nonetheless, ActiveX is very powerful, especially for intranets and applications where the user might need to work with other M$ applications. sweet.
I wish PHP had been created with a JS/C syntax instead of a Perl/C syntax. Perl programmers would disagree, I'm sure, but at least with JS everything's an object to begin with. Instead of serializing code just to comunicate back and forth between JS and PHP, we could've had a much more powerful implementation between server, client and even Java.