[ Jocelyn Ireson-Paine's Home Page | Free software | Publications ]

JavaScript for Web-based models


In this article, we want to say a little about using JavaScript for Web-based models, as an alternative to the familiar approach of running them on the Web server. We are also making available the source of our BBC Budget Day tax calculator, which this year we wrote in JavaScript. We hope it will be a useful demonstration of how to use the language.

Why JavaScript?

Until this year, all our models - Virtual Economy, the Virtual Learning Arcade simulations, and the BBC Budget Day tax calculator - ran on Web servers. This is great for ease of access - as we enthused in an article published back in 1995 when we were just starting off, anybody, no matter what machine or operating system they have, can interact with a server-side model as long as they have a suitable browser.

But the ease of access is counterbalanced by the problems that arise from concentrating all the processing onto one server - problems which can become acute for frequently-run programs. This year, BBC statistics showed that our tax calculator was run 291,311 times on Budget Day. We had written it in JavaScript; but suppose that like the previous years' versions, it had run on the server. And suppose that each run took one second, a not unreasonable assumption. Then altogether, it would have occupied the server for one third of a day - one third of its capacity. In fact, we do know that at one point during Budget Day 2001, our model was accounting for over 25% of the load on the server. To avoid such loading this year, we switched to JavaScript. JavaScript code is written into a Web page, sitting between the HTML tags. So like the rest of the page, it lives on the server. When you request a page, however, your browser downloads the lot and then executes the JavaScript itself, leaving the server nothing to do other than processing the initial request.

Not all models will be so heavily used. JavaScript, however, also offers benefits in increased responsiveness. For instance, errors in input can be caught immediately, without having to send the input to the server for checking. So what is JavaScript, and how do you run it? In a short article like this we can't provide a complete introduction to the language, but we shall give some pointers to the most important features, and some advice on how to program safely in it.

If you want to see our example, you can download the source from our Virtual Worlds site. Instructions on how to use it are included on the page. To run the program, go to this year's BBC version or our copy, linked from the Virtual Worlds page above.

What is JavaScript?

With its curly brackets, "if" statements and "while" loops, JavaScript looks not unlike C and Java. The syntax is similar, the same arithmetic operators are available. If you know one of these languages, basic JavaScript is easy to pick up.

Where JavaScript differs is in its handling of variables and objects, and of course in its ability to control a Web browser. As far as variables go, JavaScript is what's called "dynamically typed". Any kind of value can be assigned to any variable; you don't need to use a type-word such as int or String to tell the compiler what the variable contains, but just use the word var for all variables. This does make writing programs easier. However, it also means the compiler can't detect "type-check errors": those accideots that happen when you pass, for example, an integer to a function that expected a string. Such errors will remain until runtime, and if not caught by careful testing, may lie undetected for days or weeks until suddenly exploding when the statement they're in finally gets exercised. So JavaScript is simpler than C and Java; but because of this, it needs much more care in testing and debugging.

Like Java, JavaScript has objects, and you can play the same games with methods and inheritance that Java permits. But be warned! JavaScript's object system is quite different, based on something known as prototype-based inheritance. Java and C++ programmers will need to learn some new tricks to use this effectively. In learning about these, we found David Flanagan's "JavaScript: The Definitive Guide" (published by O'Reilly) very helpful, and we thoroughly recommend it to you.

On the positive side, the JavaScript object system makes it very easy to create records - for example a structure representing a book, with fields for author, title and ISBN, or a pair representing a complex number, with real and imaginary components. Arrays and lookup tables are also straightforward. But again, there is little compile-time checking. You might intend your book record to have a field called Author, but the compiler won't tell you if you accidentally write auth instead.

There's a general point here. Look at any JavaScript newsgroup or list, and you'll see many postings from newcomers who, perhaps because it's often referred to as a "scripting language", have gained the impression that JavaScript is simple, enabling you to write exciting programs after only a few hours of study. Not so. It is a complex language with unusual (but not inelegant) implementations of some common concepts, and little help to be gained from compiler error-detection. JavaScript programs need at least as much care as those of any other language. Divide your code into separate modules, one module to a file; test each separately; comment all variables and functions, making sure you know what kind of data each contains or gets passed; test functions in isolation before using them in the rest of your code.

JavaScript and the Web browser

From the point of view of this article, JavaScript's most important feature is its ability to control the Web browser. Let's consider our tax calculator. With the old server-side version, the user first pulled up a simple form into which they entered details such as marital status and house ownership. They then clicked Submit to send this to the server. The server checked the data, decided what financial information it needed, and generated another form which it send back as HTML. The process was then repeated, except that this time, the server was doing the tax calculations and returning them in the results page.

With JavaScript, all this takes place in your browser. Clicking Submit on the first form invokes a string-processing function which extracts your data from the form's input fields and then performs a series of string concatenations to put together a string containing the text of the second form. That's right - code running in the browser is generating a complete new Web page which can then replace the one currently on display.

So the second form then gets displayed. With this form, there is an issue of data validation, because if you type, for example, a letter where a number is expected, we have to make sure it doesn't get into the model and crash it. (The old server-side input form side-stepped this problem by using menus). We do two kinds of validation. It's possible to check some things as soon as the user types a character: letters never make any sense in a numeric field, and neither do most other non-digit characters, so we can reject those straight away. However, some checks have to be left until the form is finally submitted. For example, blank fields aren't valid. But we can only reject a field if it's blank at the time the form is submitted, not if it becomes blank while the user is typing: in the latter case, the user might just be in the process of retyping a number.

After the second form has been submitted and validated, our program extracts its fields, packs them into a single structure (which is more convenient to pass around than lots of separate variables), and passes it to the tax routines. These use arrays to store tax bands and rates, records to store the tax systems, and make plentiful use of JavaScript's arithmetic operators: there's not much to say, except to convince you that you really can run a tax model in your browser.

Finally, the tax calculator having done its work, another group of string-processing functions takes over and generates the output page, embedding the results into it as tables. As with the second form, this is stored as a string containing HTML; and as with the second form, we use JavaScript's built-in browser-control features to make it switch over to displaying this string as a new page.

That then is a brief example of some of the things JavaScript can do. The code is here - we hope it will be useful.

How do you run JavaScript?

The obvious way is by loading it into the browser. Create the file (or files) that is to be your final Web page, with your JavaScript code and HTML in it; put it onto your Web site; and then open it from the browser. If you don't have a Web server, the browser will probably let you type the filename into the address bar, preceded by the prefix file:.

When you test code in a browser, be warned! Our browsers were truly dreadful at reporting errors, frequently just displaying a blank page if there was something awry in the code. This is frustrating, but there is a way to trace how far the browser has got. Sprinkle the page liberally with calls to the alert function. This displays a dialogue box when called, and can be used for debugging in the same way you'd use a print statement in other languages.

When developing complicated code, we favour a different approach - Rhino. This is an open-source Java implementation of JavaScript, available from http://www.mozilla.org/rhino/. If you have Java, Rhino is easy to install. The Rhino documentation tells you how to invoke the interpreter; doing so will pop up a window into which you can type JavaScript commands. These can be simple arithmetic expressions - Rhino makes a handy desk calculator - or calls to any JavaScript function that Rhino knows about. You can load one of your own files by calling its load function, and once you've done this, all the functions defined in it become available, so you can test them by trying them out with various arguments. What you can't do, since Rhino isn't embedded in a browser, is to use those JavaScript functions that display and alter Web pages. But any kind of Web-based model will contain a lot of functions that have nothing at all to do with output - such as Ready Reckoner's tax calculations - and we do recommend getting these tested and working under Rhino first, before starting with the others.

Portability problems and browser bugs

The main problem with JavaScript is compatibility. In the beginning, Microsoft and Netscape each went their own ways with the language; although the core functions and commands were generally the same, there were big differences in some of the browser-interaction features. As new versions of the browsers appeared, new features were implemented, leading to incompatibilities not only between manufacturers but also between different releases of the same manufacturer's browser. The situation seems now to be slowly improving: older browsers are dropping out of use, and we seem to be seeing some de facto standardisation. Nevertheless, the topic is complicated, but it can be handled - once again, we refer you to David Flanagan's excellent book. We have found useful a brief account of the history of JavaScript at http://www.howtocreate.co.uk/jshistory.html, and a detailed breakdown of which browsers implement which features at http://www.xs4all.nl/~ppk/js/.

As well as intentional differences in implementation, browsers also suffer from bugs, which can cause a lot of grief until you realise what's going on. The most comprehensive site we have found for this is a German one, and for those who can read German, we give the URL: it's at http://www.browser-bugs.de/.

Don't be discouraged by this section: with the aid of the references cited, a skilled programmer can solve these problems easily. JavaScript gives you scope to do many interesting things - enjoy it!


The URLs here were checked on June 20th 2003.

David Flanagan. JavaScript: The Definitive Guide, O'Reilly, 2001.

Jocelyn Ireson-Paine and Graham Stark. BBC Budget tax calculator. http://www.virtual-worlds.biz/rr_source/.

Thomas Kobert, Michael Seeboerger-Weichselbaum, and Helma Spona. Browser Bugs (in German). http://www.browser-bugs.de/.

Peter-Paul Koch. JavaScript tricks, tutorials, and compatibility. http://www.xs4all.nl/~ppk/js/.

Mark Wilton-Jones. A history of JavaScript. http://www.howtocreate.co.uk/jshistory.html.

Rhino JavaScript implementation. http://www.mozilla.org/rhino/.

5 July 2003

[ Jocelyn Ireson-Paine's Home Page | Free software | Publications ]