The History of JavaScript and Databases | WebReference

The History of JavaScript and Databases

The History of JavaScript and Databases

JavaScript and databases have a mixed history, due in part to JavaScript's success as the Web's scripting language. The security provisions for Web applications has been to work in a "closed sandbox," which restricts the ability of a Web program to read (let alone write) local files. Here is the range of sandbox options:

  • One can read a PC client's file, most often an image file, for upload to a website.

  • One can write to a local cookie file addressed by name and date if the user permits cookies.

  • Each cookie can be a maximum of 4K in length (including name and date ID).

  • Your web server program may write a maximum of 20 cookies.

This is hardly the right stuff for database intensive applications; yet database operations take place in Web applications. 99.99% of those database operations are done on a Web server. Or to be more precise, are passed on through the Web server to an application server which often invokes a database server. This 3-stage operation is the heart and soul of n-tier distributed Web processing that drives most current Web development. JavaScript may be used either on the Web server or the application server and be involved in database operations.

The server side role of JavaScript is in severe decline as Netscape (whose web and application servers featured use of JavaScript) is almost extinct. This is being replaced by Java, J2EE, Cold Fusion, PHP, Perl and other popular server side scripting languages. Only Microsoft continues to develop JavaScript (or more correctly, JScript) for database use on the server side. Even that is in jeopardy as ActiveScripting (the name for .ASP files which can coded be in JScript, VBScript, VB.NET or C#) are called into question as being major security hazards in a number of specific coding situations, including some database operations.

It should come as no surprise that JavaScript has few, if any standard database manipulations, let alone file I/O commands (except those added by ISVs using JavaScript for server-side and/or macro processing capabilities). Each of these versions of JavaScript (such as Netscape's LiveWire, Microsoft's Jscript, Adobe's Acrobat-oriented JavaScript) uses proprietary extensions. They are just like client-side versions of JavaScript which have been adopted as macro languages, they all have proprietary object models for database connections, transactions, and control.

For standard Web database applications, one has to look elsewhere other than server-side JavaScript. One could consider Mainsoft's Visual MainWin which automatically and faultlessly converts ASP.NET applications to cross platform J2EE applications. Or, as previously noted, there is a wealth of server-side tools available, such as Cold Fusion, JSP, PHP, etc. These tools link seamlessly with most popular Web servers and database servers. The Java application servers offer the added advantages of compiled code, server-side caching, load balancing and enhanced security to the process of maintaining Web databases. In addition, switching between Java and J2EE servers is possible. As a result, server-side Java provides some trade-offs. There are the potential gains (as cited above) in return for sacrificing JavaScript's (or PHP, Perl and other interpreted languages), the possibility of faster development and/or easier deployment.

JavaScript's Other Database Roles

While JavaScript is waning in server-side database applications, it still has a secondary role to play in PHP, Perl, JSP and other Web database applications. JavaScript has become one of the more popular means of doing database input forms validations right at the client browser. These validations often can improve performance because they bypass the network to-and-from traffic associated with server-side validations. As a consultant, I've seen elaborate data validations performed with JavaScript, but also some nifty data graphs and running total displays in sidebar areas/window panes as users fill in a form. With JavaScript's increasing use as client-side expediter, this scripting role expands beyond data validations.

It's important to note that JavaScript has made gains as both as an internal macro and scripting language. For example, Macromedia Flash (in its ActionScript guise), Adobe Acrobat forms and PeopleSoft 8, all use JavaScript as scripting language to provide standalone code (such as runtime dialogs, animated presentations, and/or user customized report writer). As a macro language, JavaScript is used to run Adobe Photoshop, Illustrator, Atmosphere and/or Macromedia Dreamweaver and Fireworks. However, when JavaScript is used as an internal macro language it rarely provides for database connectivity. For example, Adobe's use of JavaScript as macro language in Photoshop and Illustrator involves the addition of file read/write capabilities that users wouldn't find in Web versions of JavaScript. But neither macro version of JavaScript provides database connectivity.

When JavaScript is output as a runtime or standalone application (as in the case of Adobe's Acrobat or Macromedia's Flash MX), then JavaScript tends to have database connections. For example, Acrobat's JavaScript supports (in Windows only) the ADBC-Adobe DataBase Connectivity object. This provides the ability to read and write PDF forms data to and from a local client database. This form can then be passed to other systems (Windows, Linux, Unix and Apple) where the forms data can be read, updated or processed. The unique characteristic of the Adobe solution is that it can be used online or offline as long as an Acrobat reader is available. In addition, Adobe provides a number of security and privacy options associated with the PDF form that can validate who has access to the form and when/how they can do so.

Macromedia has database enabled ActionScript. Think of ActionScript as a version of JavaScript tailored for Flash's multimedia and animation/movieclip objects. ActionScript offers three main database handling approaches:

Adobe and Macromedia have taken different approaches to database enabling of their versions of JavaScript/ActionScript - there is one major similarity. Both have used XML as a database connection translation layer instead of a direct connect or through common database connectors (such as ODBC or JDBC). This might appear to be inefficient - why have another layer between the database and client application? The reason is that ANSI SQL standards have been so loose that SQL database vendors can and have implemented various SQL data types such as strings, integers and floats in different underlying ways so that a translation layer (XML in this case) is often required. From there, the XML translation layer can then be used to interface to other data sources such as network, object or hierarchical databases (plus CSV,XML, and other structured data sources).

Summary

JavaScript originally was used to provide server-side database access by Netscape. This server-side usage has been largely displaced (except in some ASP applications) by Java, PHP and other application servers. JavaScript continues to serve as the client side scripting language for many database validation and presentation tasks - be they driven by ASP, JSP, PHP or other application servers. But when used as a macro language for the operation of programs such as Photoshop or Fireworks, JavaScript has rarely has been used for database connectivity. There is nothing to prevent such usage other than extending the Object model (which Adobe and Macromedia have done in the case of their Acrobat and Flash products, respectively).

An important point is this - unlike scripting languages such as Jython, JudoScript, Perl, PHP and Ruby - JavaScript does not have a base or standard definition in the language for database connection and access . Instead, each ISV must add this capability. These shortcomings are likely make JavaScript similar to C/C++. While JavaScript is in universal usage, those dialects are often incompatible. An interesting trend is happening in the browser and web development community. Vendors (such as Apple, Mozilla, Opera, Sun and others) are beginning to collaborate and advance common features in the DHTML space (JavaScript/CSS/DOM) and their interfaces to major languages like C/C++ and Java. The Forms enhancements done by WHATWG.org is an example. Thus, there is hope that the JavaScript community may see their way to establishing a standard data/database access framework.

Jacques Surveyer is a consultant and trainer; see some of his tips and tutorials at theOpenSourcery.com.

Created: March 27, 2003
Revised: August 27, 2004

URL: URL: https://webreference.com/programming/javascript/j_s/column9/1