Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 28
  1. #1
    Regular Coder
    Join Date
    Dec 2003
    Location
    America
    Posts
    544
    Thanks
    0
    Thanked 0 Times in 0 Posts

    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?
    LovesWar

  • #2
    Senior Coder
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    1,063
    Thanks
    2
    Thanked 0 Times in 0 Posts
    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
    Shawn

  • #3
    Regular Coder
    Join Date
    Dec 2003
    Location
    America
    Posts
    544
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Still need more

    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?
    LovesWar

  • #4
    New Coder
    Join Date
    Sep 2002
    Location
    Moncton, N.B., Canada
    Posts
    69
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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.
    Last edited by Terry; 06-26-2004 at 01:22 PM.

  • #5
    Senior Coder
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    1,063
    Thanks
    2
    Thanked 0 Times in 0 Posts
    Much better than my explanation

    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.
    Shawn

  • #6
    New Coder
    Join Date
    Sep 2002
    Location
    Moncton, N.B., Canada
    Posts
    69
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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.
    Last edited by Terry; 06-26-2004 at 06:26 PM.

  • #7
    Senior Coder
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    1,063
    Thanks
    2
    Thanked 0 Times in 0 Posts
    ahhhhh,
    Terry, master of analogies
    Shawn

  • #8
    Senior Coder
    Join Date
    Jun 2002
    Location
    Wichita
    Posts
    3,880
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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.

  • #9
    Banned
    Join Date
    Sep 2003
    Posts
    3,620
    Thanks
    0
    Thanked 0 Times in 0 Posts
    PERL used alongside of javascript is a dangerous combination indeed....

  • #10
    Regular Coder
    Join Date
    Dec 2003
    Location
    America
    Posts
    544
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Care to elaborate?

    Want to expand on the following:

    Code:
    PERL used alongside of javascript is a dangerous combination indeed....
    ?
    LovesWar

  • #11
    Supreme Master coder! glenngv's Avatar
    Join Date
    Jun 2002
    Location
    Philippines
    Posts
    11,068
    Thanks
    0
    Thanked 256 Times in 252 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.
    Glenn
    ____________________________________

    My Blog
    Tower of Hanoi Android app (FREE!)
    Tower of Hanoi Leaderboard
    Samegame Facebook App
    vBulletin Plugins
    ____________________________________

  • #12
    Senior Coder
    Join Date
    Feb 2004
    Location
    Edinburgh
    Posts
    1,352
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Arrow ahhh ... bring back SSJS

    Quote Originally Posted by SpiritualStorms
    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.

    to read up on SSJS, go to
    Devedge

    that is all ...

  • #13
    Senior Coder
    Join Date
    Feb 2004
    Location
    Edinburgh
    Posts
    1,352
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by glenngv
    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.

  • #14
    Regular Coder
    Join Date
    Dec 2003
    Location
    America
    Posts
    544
    Thanks
    0
    Thanked 0 Times in 0 Posts

    so thats how i get my machine all wrecked up

    ..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.
    LovesWar

  • #15
    New Coder
    Join Date
    Sep 2002
    Location
    Moncton, N.B., Canada
    Posts
    69
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by jbot
    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.
    Last edited by Terry; 06-29-2004 at 11:36 AM.


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •