Is there a way of accessing the source code of all the predefined JavaScript methods,
and objects?
I was sort of wondering if there was a way of accessing the methods, objects, and functions of all the javascript predefined concepts?
Can anyone tell me why javascript is not the same as server side programming? What exactly are the limitations? I ask, because from what i understand, one can technically create objects with javascript, so in a sense, you could do classes, like in Java, but yet, i am also to understand that javascript is only a client side language, and not a server side, like Java. This being the case, what exactly are the technicalities that makes this language incapable of going into the regions that other languages can?
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.
Javascript works when the whole document has loaded and all the necessary code for it to work has been cached by your pc. The server's job is done at that point. Now, whatever has been included as script in the document can do its job. Javascript works "on the fly" at that point. It responds to events, that is the key. The doc could already have been loaded hours ago but that same code (now cached on the client) will obediently respond to a user's interaction with the webpage. Specifically, events triggered by an onBlur, onChange, onClick, onDblClick, onDragDrop, onError, onFocus, onKeyDown, onKeyPress, onKeyUp, onLoad, onMouseDown, onMouseMove, onMouseOut, onMouseOver, onMouseUp, onMove, onReset, onResize, onSelect, onSubmit, onUnload etc, etc. All these events, and many more, trigger certain behaviours that were programmed to take place in response to the users interaction with html elements. Just looking at the names of these methods and you can see the possibilities inherent in an event-driven scripting language.
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.
Location: Los Angeles, CA Original Location: Philippines
Posts: 10,241
Thanks: 0
Thanked 112 Times in 111 Posts
I would say IE alongside with javascript is the dangerous combination.
That is because of ActiveX. With ActiveX enabled in IE, you can do anything on the client's computer.
i am also to understand that javascript is only a client side language, and not a server side
er ... actually, you can code javascript on the serverside. this is funnily enuff called Serverside Javascript (SSJS), as opposed to the Clientside Javascript (CSJS) we're all accustomed too.
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.
I would say IE alongside with javascript is the dangerous combination.
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.
..by others? I thought it funny how spy ware ends up on my system. Never could figure out how my machine seems to be controlled by others through viruses, and the what not.
er ... actually, you can code javascript on the serverside. this is funnily enuff called Serverside Javascript (SSJS), as opposed to the Clientside Javascript (CSJS) we're all accustomed too.
Server side javascript's still available in IIS servers and can be used in place of VBScript in ASP pages. Actually it has morphed into JScript, IE proprietary. I have a book here called Pure Javascript that has nearly 200 pages at the end, and more on the pdf, devoted to both MS and NN flavors of the server side part.
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.
Before you post, read our: 
ahhh ... bring back SSJS
