[Israel.pm] Java Script in Web-Pages

Shlomi Fish shlomif at iglu.org.il
Wed Feb 11 09:05:51 PST 2004

Hi all!

In Gabor's lecture in the last meeting, the question was raised about using 
Java Script in HTML. Now first here's some explanation:

When HTML first started it was served by the server and brought to the client, 
who had to either follow links, fill forms, etc. Starting at Netscape 2.0, a 
technology called Java Script (or JS for short) was introduced which enabled 
writing scripts to manipulate the HTML page elements that will run on the 
client side. What it means, is that I can tell my script to reject a form 
submission if one of the fields does not contain a valid telephone number, 

Later on, JavaScript was extended, and now can manipulate all aspects of the 
page and even change the HTML and DOM (Document Object Model). It is now a 
W3C standard titled "ECMAScript". The JS language is a bit lame in comparison 
to more serious languages like Perl and Python (and even Java), but is still 
Turing complete and usable. 

So should you use it?

First of all, a JavaScript on the client-side is not a guarantee that the 
server will receive correct input. A malicious user (let's say a cracker) can 
forge invalid input. (say if he disabled JavaScript). So, you still have to 
make sure that your server-side scripts are sane. Maintaining both a a 
server-side logic and an equivalent client-side logic can become a huge 

Secondly, browsers differ in their implementation of JavaScript. Internet 
Explorer seems to have a mind of his own which differs considerably from 
web-standards. As a result, a lot of JavaScript code, especially one 
generated from code generators, works only there, and not on other browsers.
This is a huge headache for users of Mozilla, Opera and non-Windows operating 
system. If people complain because of that, don't be surprised.

Thirdly, JavaScript that comes instead of more simple plain HTML+CSS markup
is heavily frowned upon by professional web-designers. One can see that in the
"javascript:" links of sorts that appear in various links in one of the 
JavaScript-infested sites. A simple "<a href="">" would have been much 
better. Or a Java-Script animated navigation menu instead of a simple 
click-and-reload one, which achieves much the same effect.

Moreover, JavaScript can increase the user experience. If we take a bugzilla- 
based bug tracker, then if you click on the product you get a list of its 
components. This is fully portable and tested JavaScript, and it solves a 
huge headache. Also, getting a meaningful warning about the form before it is 
submitted can save the user the frustration of waiting for the server to 

OTOH, JavaScript can actually increase frustration if it doesn't work 
properly. This is something any Linux user can tell you about dysfunctional 
forms and pages that appear in poorly-coded Israeli sites. Not only that, but 
search engines may find it difficult to trace this JavaScript. As a result of 
that, most JavaScript-infested commercial sites have little if any presence 
on Google (for example) except for their front page. Compare it to more 
usable sites like these of IBM, Yahoo, or Microsoft (which have many pages on 
Google), and you'll see that using JavaScript instead of a plainer syntax can 
put you in a big problem.

Furthermore, one cannot be certain that JavaScript be present in the browser. 
It could have been disabled, or the user is using lynx.

There may be other things I'm forgetting.


Conclusion: I never found the need to write JavaScript markup in my pages, 
except for a game I wrote in JavaScript and the DeCSS for JavaScript hack. 
(which is pretty useless, because you'll need an extremely fast machine to 
run it in real-time, but still cute and thought-provoking) I keep my HTML 
small in size and simply relies on the server to do all the sanity-checking 
logic. Complicating my code further to include JavaScript which I'll later 
have trouble maintaining, is not my idea of keeping myself out of an asylum.

I do think, however, that using JavaScript as part of "shrinkwrap" marketplace 
(open-source or otherwise) software packages, where it is indeed appropriate. 
Things like pull-down JavaScript-menus, bugzilla's embellishments, 
client-side form validation callbacks in form generation routines. etc. This 
is because, then the developer of the product can make sure it is indeed 
portable, and working perfectly on all browsers. 

Usually just passing things back to the server will simplify your life 
considerably. Maintaining complex JavaScript logic as well as server logic 
for software for internal use or such that is deployed only on one or a few 
web-sites, is a recipe for disaster.

As an example for JavaScript done poorly, I can give the Chiq-Chaq Wiki 
implementation. It is a JavaScript hell, and not a very reliable one, and 
what complicates things further is that the JavaScript and the server-side 
logic are maintained by two different people. I'm planning to switch to TWiki 
(or perhaps Moin-Moin) for my only deployment of it on the Perl-Begin site. 
(other than that, it's a very nice Wiki, but this is a huge issue)


	Shlomi Fish

Shlomi Fish      shlomif at iglu.org.il
Homepage:        http://t2.technion.ac.il/~shlomif/

I don't believe in fairies. Oops! A fairy died.
I don't believe in fairies. Oops! Another fairy died.

More information about the Perl mailing list