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:

1. A Web Services Connector that uses SOAP to provide a connection to external
database data;

2. A XML Connector component for linking to any external data source that
returns XML through HTTP (such as JSP, ASP, Servlet, or ColdFusion);

3. Flash Remoting for accessing data directly from an application server
using a more efficient binary protocol.

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.