What is something that can not be done with client-side JavaScript?
Six answers:
ʃοχειλ
2007-07-06 15:00:12 UTC
Good question.
Client-side javascript is used to control the look and behaviour of a web page after it is sent to the browser. It can change the style of the html elements, the texts or the properties of them, navigate to other pages, validate form data, ...
It cannot do things like,
- modifying html tags, their style, associated text and data before the page is sent to the browser.
- accessing server-side database or text files.
- accessing visitor's computer resources like saved images on his/her computer except for the cookies which are fairly harmless.
- acting like a stand-alone computer program, accessing something outside the html web page.
- saving its states anywhere so that it can recover its state after the page being closed and revisited; something which could only be handled in server-side.
- ...
fjpoblam
2007-07-06 14:47:24 UTC
(1) Client-side javascript is not allowed to write files on the client (page visitor) computer.
(2) Because the javascript IS running on the client (page viewer) and therefore must be copied to the client (page viewer) computer memory before it can run, it cannot know anything about the client computer until it gets there, so that, in a way, you have to write the program so that it determines everything before it does anything...
(3) The web page containing the javascript cannot be written so as to DEPEND upon the javascript, as many folks who view the web page, have javascript disabled.
Neeraj Yadav♥
2007-07-06 14:19:52 UTC
AS the name suggests CLIENT SIDE
it can only help you while working on client program(BROWSER)
You cant play with server objects,You cant access/tamper server database.
OR
* Not all browsers support client-side scripting at all or JavaScript in particular. (And search engines can hardly be expected to "support" it; this means that any information which is accessible via JavaScript only is inaccessible to them.)
* Even major browsers' JavaScript implementations are not fully compatible with each other, so it takes time to make the code really work even if you only consider Netscape and IE.
* Client-side scripting can be turned off by the user or even by company management. There might be several reasons to do so. It seems that most use of client-side scripting on Web pages is between useless and annoying. And it involves serious security risks. For example, according to CNN article More bugs found in Internet Explorer, Navigator (dated 1998-10-14),
If you'd rather be safe (and somewhat inconvenienced) than sorry, both companies recommend that you disable your browser's ability to execute JavaScript until a patch is released.
Bugs are sometimes fixed, but it seems that new bugs are revealed in JavaScript implementations rather often. See e.g. an Usenet article by Elizabeth T. Knuth containing "a track record of security problems with JavaScript". See also answer to question The World Wide Web Security FAQ. That document is fairly old, but for an example of a more recent incident, see CERT® Advisory CA-2000-02: Malicious HTML Tags Embedded in Client Web Requests, which recommends: "Web Users Should Disable Scripting Languages in Their Browsers". The CERT site contains many more advisories and notes that deal with scripting languages or JavaScript in particular.
Perhaps your JavaScript code has no security risks. (Are you sure?) But many people think that JavaScript is insecure in general and therefore keep it disabled. They have other things to do than to install patches to something they don't really need, the JavaScript support. (After all, even if your JavaScript code is useful, there's a lot of JavaScript stuff on people's pages which is a nuisance, like new windows popping up for no good reason.)
This means that you should never rely on JavaScript being executed. You should first write your pages so that they work robustly, then perhaps consider adding some "spices" using JavaScript or other methods.
If you think that your page works better with JavaScript on, you might consider adding a note about this onto your page, so that users can consider switching JavaScript on or perhaps even switching from one browser to another. The note should be something brief and polite, and "Note: This page works better if JavaScript is enabled, since ...", where "..." should contain a real, practical explanation. It would be natural to put such a note into a NOSCRIPT element (but note that there are some problems in its implementation on popular browsers). Nick Kew has presented the following example in a Usenet article of his:
Let's see. I'm on your order page, and want to order something:
1. There's a plain order form with a submit button that works. Good, you have my order.
2. There's a javascript order form with a submit button that works. Likewise.
3. There's an order form that requires javascript and won't work without. I'll use the back button.
4. There is an instance of (2) done nicely, with something like
Now that's a Good usage, and might well persuade me to enable it, not just for the page, but for the entire site. Because the author has gained my respect.
Anyone tell me why there are 1000 instances of (3) for each instance of (4)?
The robust approach: processing backed up server side
hope this will solve your issues
Cheers : )
2016-11-08 13:38:37 UTC
you're taking a style and you could desire to study Javascript? Then do no longer ask for a complete answer. Your instructor will probable be waiting to inform newbie code from expert code. All you could desire to do is study the thank you to jot down a loop and use an "if" assertion with a modulus operator.
Andy T
2007-07-06 14:11:55 UTC
With AJAX anything can go; but without a lot can't be done, database, counter. Anything that is about communicating cannot be done. Writing to a file can never be done too.
hakim1125
2007-07-06 14:11:32 UTC
I believe some games can't be played with that. i dont really know, but thats what i've heard.
ⓘ
This content was originally posted on Y! Answers, a Q&A website that shut down in 2021.