This article introduces server-side JavaScript and describes what you can do with it.You can either jump to the specific section that interests you by following these links, or read the article from beginning to end by clicking here.

Introduction: A Simple Way To Deliver Complex, Cross-Platform Solutions
Using JavaScript to Develop Web-Based Applications
Aside About LiveWire
What is Server-Side JavaScript?
State Maintenance Objects
Database Access With JavaScript
A Word on Scalability and Performance
Compatibility: JavaScript and Enterprise Server 3.0
Conclusion: JavaScript in Your Future

INTRODUCTION: A SIMPLE WAY TO DELIVER COMPLEX, CROSS-PLATFORM SOLUTIONS

Maybe you've seen this Dilbert comic strip: It shows one of the regular characters saying to a guy who looks like Santa Claus, "I know who you are. That scruffy beard, the red suspenders, smug expression. You're a UNIX programmer." "Santa" replies: "Here’s a nickel; go out and get yourself a real computer."

UNIX programming and programmers' are in the spotlight these days. A couple of years ago, noone (except perhaps UNIX programmers) would have believed that UNIX would get so hot. But there's no question that with the spread of the Internet, UNIX programming, especially for adding functionality to and creating applications for Internet/intranet servers' most of which sit on hardware running UNIX is in demand like never before. Same goes for professional C/C++ programmers for CGI and other types of server development on a variety of platforms.

This is great if you're a UNIX or C/C++ programmer, not so great if you're seeking the services of one. There are only so many professional "native language" programmers, and if you're lucky enough to find a good one, he or she can be expensive.

The good news is that you don’t have to know UNIX, C/C++, Pascal, and other languages designed for writing native code to accomplish a great many server programming tasks today. I’m not talking about Java, either; Java is less complex than many native programming languages, because of its object-oriented nature, and the code you create using Java runs, as is, on all platforms with a Java virtual machine. However, Java programming is generally best done by the same professional programmers who are comfortable writing native code.

I’m talking about the server-side JavaScript solution provided by Netscape’s LiveWire development tool. JavaScript lets you add features to Netscape’s Enterprise and FastTrack servers using an easy-to-understand scripting language instead of having to write low-level, native code. It lets you produce cross-platform code that runs in the same way on both UNIX and Windows NT versions of the servers—an improvement on native languages, which generally don't produce cross-platform code. It can be used to write both small and large Web-based applications that run at least as efficiently as their CGI counterparts. (And, as Netscape continues to enhance JavaScript and its servers, such applications can soon be expected to run more efficiently than CGIs.) And, in doing all the above, it’s enabling a whole new class of previously nonexpert programmers to create sophisticated Internet applications that can access and modify corporate databases and build dynamic Web pages.

Is this bad news if you’re a UNIX, C, or Pascal programmer who’s been making a living writing CGIs and other server software? No. There’s tremendous demand for what you do, and that demand should probably increase as more and more businesses set up intranets. However, LiveWire and server-side JavaScript are great news if you’re trying to set up an intranet—or develop an application for a public Web site—and you don’t really think of yourself as a programmer.

J.J. Kuslich, a consultant with Application Methods, Inc., and the developer of a sample application that ships with LiveWire, had this to say about server-side JavaScript:

JavaScript is a simple language with a short learning curve. Yet, given the database connectivity extension that LiveWire provides, it’s possible to create a Web site that allows dynamically created pages filled with data from corporate databases. JavaScript and LiveWire make this orders of magnitude simpler than was previously possible with C/C++ code and CGI scripts. Plus the execution is generally faster than CGIs. Essentially, JavaScript and LiveWire are excellent replacements for CGI technology—faster, simpler, more powerful. Using LiveWire will give you an advantage because you won't need expensive specialists to maintain the code (in most cases), yet, at the same time, it gives you a nice breadth of capabilities.

I’m going to spend the rest of this article describing server-side JavaScript and saying, briefly, what you can do with it. If you’re developing Web-based applications—especially for viewing, entering, and/or modifying information in databases—I think you’ll soon discover why you want to take a close look at JavaScript (if you haven’t already). If you’re inexperienced at programming, it will allow you to do things that you probably didn’t know you could do; even if you’re an old hand with UNIX or C/C++, you’ll be able to save time and accomplish some of the same things—and maybe more—that you’ve been doing with the CGI approach to server programming.

ASIDE ABOUT LIVEWIRE

Before I really get started, I want to say what I'm not going to talk about. This is not an article about the entire LiveWire development tool product; instead it's only about the server-side JavaScript parts of it, which are most relevant to the subject of building Internet/intranet applications.

To sum up the entire Live Wire product in one paragraph, also part of LiveWire is Site Manager, a visual tool for managing Web sites, and Navigator Gold, Netscape’s HTML authoring tool. LiveWire is available for use on Windows 95 and Windows NT systems. Also part of the product line is LiveWire Pro, which adds the Informix-OnLine Workgroup SQL database to the basic LiveWire product offering; LiveWire Pro for Windows NT also includes Crystal Software's Crystal Reports Professional Version 4.5.

In case you’ve been confused about where you can find LiveWire (as many have been), LiveWire and LiveWire Pro are available as separate products, while all components of LiveWire also ship with the Netscape Enterprise server.

Finally, I should point out that the newest versions of LiveWire—rid of most of the bugs that used to slow LiveWire development, thanks to the diligent efforts of Netscape's engineers—is available from the Netscape download site. Further, with the release of SuiteSpot 3.0, JavaScript will be part and parcel of the Netscape server line, and you won't have to purchase LiveWire separately to do server-side scripting.

USING JAVASCRIPT TO DEVELOP WEB-BASED APPLICATIONS

To move on to what I am going to talk about: Code created with JavaScript runs on Enterprise and FastTrack servers using the JavaScript runtime, which is yet another part of LiveWire. LiveWire also includes the JavaScript server-side compiler and the database connectivity library, a set of JavaScript objects; these last components are what I'll talk about for the rest of this article.

To give LiveWire’s server-side JavaScript solution its broadest description, you can use it to develop Web-based applications, or, to be a bit more precise, you use it to make Web servers carry out the tasks you and your users want them to do. Web-based application can be generally defined as code that sits on a web server that performs specific tasks--either on the client or on the server, depending on how the code is written; the code is accessed by the end-user through a Web page.

Server-side JavaScript isn’t (yet) developed to the point that you can program a server to do anything, but it does let you program the features that are among the most in demand today: database connectivity and what’s known as state maintenance. Actually, while database connectivity is what many LiveWire developers think of first, Netscape engineers originally designed server-side JavaScript to provide both the database object as well as a set of state maintenance objects, that is the code that lets servers keep track of clients and what they’re doing when they’re connected to the server. Additionally, if there's a feature you can't add to your application with JavaScript, you can do it using C; the resulting code can be tied into your application using the C-call application programming interface that's part of the Netscape Enterprise Server.

You can read about how a leading enterprise systems intregrator has used LiveWire to develop private intranet and public Internet sites for its clients in a recent installment in the Netscape Intranet Executive Column on the Netscape Home Page.

Future View Source articles will provide more detailed descriptions of how developers have used—and how you can use—server-side JavaScript, including code examples. For now, let’s take a quick look under the hood of that part of LiveWire to get an idea of its features and what you can do with it, starting with its state maintenance objects. For a lot more detail about each of the following subjects, you’ll want to reference the LiveWire Developer’s Guide; the sections below include pointers to specific parts of that document.

WHAT IS SERVER-SIDE JAVASCRIPT?

Starting with the basics, let’s first define server-side JavaScript. All JavaScript code resides within an application, actually an HTML page, sitting on a Web server. Depending on how it’s tagged, the code executes either on the server or on the client that’s connecting to the application or the HTML page. To create client-side JavaScript code—code that executes on the client computer—you use the <script> tag; for server-side JavaScript, which executes on the server, you use the <server> tag.

How do you determine whether to have your JavaScript code run on the client or the server? That’s a complicated question that would be a good subject for its own article. To give you a quick answer though, here’s what the JavaScript Developer’s Guide says on the subject:

"As a rule of thumb, use client scripts for the following:

• Validating user input; that is, checking that values entered in forms are valid
• Prompting a user for confirmation, and displaying error or informational popups
• Performing aggregate calculations (such as sums or averages) or other processing on data retrieved from the server
• Conditionalizing HTML
• Performing other functions that do not require information from the server

"Use server scripts for

• Maintaining information through a series of client access
• Maintaining data shared among several clients or applications
• Accessing a database or files on the server
• Calling external libraries on the server
• Dynamically customizing Java applets, for example, visualizing data using a Java applet"

To sum up, you generally use server-side JavaScript for state maintenance, to provide connection from a Web application to a database, or to access functionality from code written in other languages. Also, to make Web application development easier, LiveWire provides a variety of JavaScript functions that are designed to run only on servers—for example, to generate dynamic HTML, for redirecting a client to another URL, to flush the server’s output buffer, or to encode special characters so they can be used in a URL. For more detail on this subject, see chapter five of the JavaScript Developer’s Guide.

STATE MAINTENANCE OBJECTS

You might have heard it said that HTTP is a stateless protocol; this means that there’s nothing inherent to the protocol that helps a server know whether a client has visited the server before, what processes the server has run on the client’s behalf, what data the server has previously served to a particular client, or even how many times the server has been accessed. These are all tasks that have to be written in to the server, and JavaScript provides an easy way of doing that.

You can use the following four predefined state objects—objects that let a server maintain persistent data about how it’s being used—that you build into your application and control using JavaScript:

• the server object, which contains global data for the entire server, keeping track of all requests served by the server and letting the server share data among different applications and clients; you might use the server object to keep track of the number of times an application has been called
• the application or project object, which contains data that lets the application share data with multiple clients, for example keeping track of the number of times clients connected to the server have requested an application to complete a specific task
• the client object, which contains data specific to an individual client, for example keeping track of the actions of a client using the same application multiple times
• the request object, which contains data about the latest request made by a client

More information on how you use these objects and the LiveWire object framework can be found in chapter four of the LiveWire Developer’s Guide.

DATABASE ACCESS WITH JAVASCRIPT

With today’s huge growth in the number of private corporate intranets, perhaps the most commonly sought Web-based applications are those that provide database access. There’s a virtual tidal wave of organizations who want to have their cake and eat it, too, both updating their networks with Internet technologies and still letting those new networks use the information they’ve stored in relational, and other, databases.

Traditional programming methods for accessing databases from Web servers—specifically, writing CGIs—can be quite difficult, requiring you to write complex low-level code. Server-side JavaScript lets you accomplish this far more simply, using the JavaScript database connectivity library provide with LiveWire. In brief, JavaScript code in your application can be made to obtain information from the database and display it in a standard HTML page. It also lets users enter data into the database as well as modify existing data.

JavaScript lets your Web application access information stored on Informix, Oracle, Sybase, and any other relational databases that accord with the Open Database Connectivity (ODBC) standard for Windows NT-based systems. These applications are said to be three-tier, or client-server-server applications, since they connect a client (tier one) sitting on a user’s system with a Web server (tier two) that in turn connects to a server containing database information (tier three). These applications can be used either over the public Internet or in private intranets.

When your application uses JavaScript database access methods, LiveWire opens a connection with the database, which is then reused for multiple requests. What happens then depends on the JavaScript you’ve written in to your application to control the object. You can use JavaScript to have the object accomplish many of the tasks usually associated with retrieving and working with information from a database, including the following:

• Connecting to and disconnecting from the database
• Beginning, committing, and rolling back a structured query language (SQL) transaction
• Displaying results of an SQL query
• Creating updatable cursors for viewing, inserting, deleting, and modifying data
• Accessing binary large objects (blobs) for multimedia content such as images and sounds

You can find specific information on how you can use the database object in chapter six of the LiveWire Developer’s Guide. In the near future, View Source will also include a detailed article on database access with LiveWire and server-side JavaScript written by a developer.

A WORD ON SCALABILITY AND PERFORMANCE

Scalability and performance are important issues for most developers. You want to be sure that you’re investing in code that’s scalable and can grow to meet increasing demands. You also want your software to run well on your hardware platform so that it makes your users productive and doesn’t overtax the server’s processing overhead.

On both these issues, it’s hard to give a definitive answer, because this type of development is so new. However, all the current evidence strongly suggests that JavaScript code is scalable and can meet the needs of large enterprise—even mission critical—development jobs, and that it performs in a manner that’s at least as good, if not better than CGIs and other server enhancements.

Again to quote JJ Kuslich, this time on the subject of scalability:

Sample applications that we’ve written are quite large. In one, we have around 97 custom server-side functions written in JavaScript, contained in 15 server-side JavaScript libraries and about 40 HTML pages, many of which also contain [other] server-side code. The application includes a total of about 8000 lines of JavaScript and HTML code. To tell you the truth, I’ve been pleasantly surprised at the scalability of JavaScript. It's a simple language, and requries some clever coding at times, but the fact that we're able to do all that we've done is impressive. There are certainly improvements to be made, but I would say even in its current state it is capable of both small-scale and large-scale applications.

If you look at the AppFoundry applications, you’ll see that many of them are quite large and robust, employing a wide variety of features.

It would be a mistake, however, to overblow the capabilities of server-side JavaScript. While they can accomplish a lot, there are some known limitations. For example, you can’t include simultaneous connectivity to multiple databases, and there are some limitations to the number of connections to an individual database that can be maintained (some imposed by the databases themselves). Also, there are some limits to the amount of information the state objects can capture. And, the model for database access is page-, or form-based, meaning that the client communicates with the server by submitting entire HTML pages instead of being able to submit individual functions containing discreet bits of data. Finally, you can’t currently use the database object and JavaScript to access data from legacy systems, such as older IBM mainframes.

To put some of these limitations into more tangible words, here's what one developer recently said about LiveWire and server-side JavaScript:

Here's our experience: Our [LiveWire-based] application can't serve up more than one client at a time if the client makes a database call served up by the server-side JavaScript database object. We understand that there are some hacks to get around this, such as splitting up our application. But what we've been told by Netscape is that the database library routines all share a single global lock; so, once a query is made, no others can be made until that one is done. Our queries are somewhat expensive, so our machine (a Netra i 5/100) is CPU-bound, which means that during a query we can't even serve up graphics and HTML pages (even ones containing no server-side JavaScript) to other users.

All these limitations are being looked at, and are likely to be eliminated soon; for example, to alleviate some of these problems, Enterprise Server 3.0—to be released in early 1997—will include the following:

• A multithreaded JavaScript virtual machine to enable multiple processes to execute simultaneously
• A pool of database connections that can be shared by multiple concurrent requests
• Multithreaded client libraries for Oracle, Sybase, and Informix database systems

Additionally, in the near future, Netscape server programming tools will become even more robust than they are right now. For example, Netscape is building support into its product line for the Internet Inter-ORB Protocol (IIOP), which will make it possible to interact with legacy system-based data and applications from Netscape clients and servers using the CORBA distributed object standard. IIOP will also enable a function-based model for database interactivity, meaning that users will be able to submit individual calls to databases rather than submitting entire forms.

On the issue of performance, by their very design, Web applications created with JavaScript run more efficiently than CGIs. With CGI solutions, the server has to both spawn an incidence of the CGI and create a connection with the database, undertaking a two-step process. With JavaScript solutions, the server has already established the connection and is reusing it, a more economical solution. Also, with a CGI, the program running on the server and the CGI are separate, and the server has to work with two files. With JavaScript, all the code is contained in one file, which means the server doesn’t use as much processing overhead to run the program.

How do JavaScript-based server applications perform in high-traffic situations? To my knowledge, and the knowledge of the Netscape engineers and technical support people I spoke with to assemble this article, JavaScript is currently being used predominantly for intranet sites, which don't usually experience high volume. However, our tech support folks told me about a site employing a server-side JavaScript-based solution that's being hit at least 100,000 times a day without performance difficulties, at least from the JavaScript code. (The company that set up the site prefers to remain anonymous.) Also, in informal testing, one of our tech support engineers said that a server-side JavaScript application can maintain at least 200 concurrent connections. So, server-side JavaScript applications remain somewhat untested for high-volume sites, although the preliminary data suggests that such software should perform well in heavy traffic. (If you're using a JavaScript-based application in a high-traffic situation, I'd like to hear from you so I can pass on your experience to the rest of the View Source readership. Please write me, and we'll talk about an article.)

COMPATIBILITY: JAVASCRIPT AND ENTERPRISE SERVER 3.0

Another important issue is the forward compatibility of current JavaScript-based server software with future releases of Netscape Enterprise Server, especially Enterprise Server 3.0, part of the SuiteSpot 3.0 server release due in early 1997. According to the server team, current applications created with JavaScript will work with Enterprise Server 3.0, but they’ll require some—probably minor—alteration. Once you undertake those alterations, though, your applications can be expected to work with future versions of the Enterprise Server, which will deliver other features that will make it even easier to build Web applications.

Netscape engineers are working to stabilize the server’s interface for handling JavaScript code so that it will change once with Enterprise Server 3.0 and then be fully backward compatible from then on. We’re looking into exactly how Enterprise Server 3.0 will work with current JavaScript-based applications to let you know in a future View Source article what you’ll have to do make your software work with the new server (and to let you know about other new Enterprise Server features, as well).

CONCLUSION: JAVASCRIPT IN YOUR FUTURE

As the title of this article suggests, the great promise of JavaScript is that it will let you program servers without having to write complex, native code. In many ways, we're well down the road to that promise: As I hope this article has shown, JavaScript provides a simple-to-use but powerful way of building state maintenance and database access into Web applications, a method that will grow more robust over time and help you expand your applications to meet the demands of future users. This article, however, is just an introduction, a very high-level view that I hope will invite you to learn more. As I've said throughout, the best place to go is the LiveWire Developer's Guide; also, in the future View Source will included detailed technical articles about how you can use JavaScript for server-side programming—without having to program in native languages.

Thanks to Netscape's Rich Yaker, Chander Sarna, Rand McKinney, and Rick Fleischman for their assistance in preparing this article.

Paul Dreyfus is the editor of View Source, Netscape's online technical magazine for developers. Not so long ago, Paul edited and wrote for a developer publication at Apple Computer called Apple Directions, which was distributed in both paper and online editions. A former Apple colleague wondered aloud to Paul one day about how gratifying it could be to publish a Web-only magazine because, in her words, "anyone can publish on the Internet." Paul's trying to prove her wrong by showing that, yes, maybe anyone can get published on the Web, but only the very best makes its way into View Source. If anything in this article, or the rest of View Source, doesn't live up to that standard, write Paul and tell him. And, if you have your own ideas for technical articles about the Netscape ONE platform, send them to Paul; he'll work with you to get them published in View Source.