Why Webcrossing Server-side JavaScript (SSJS) is the scripting language you should choose

Server-side JavaScript (SSJS) vs Web Crossing Template Language (WCTL)

Webcrossing's Server-side JavaScript (SSJS) is based on standard JavaScript, so anybody with any scripting experience at all can get started very quickly. Beginners also will find SSJS easy-going because there are so many JavaScript tutorials and references available. (*1), (*2)

As w3schools, the go-to-place for web standards and scripting help states, "JavaScript is THE scripting language of the Web. JavaScript is used in billions of Web pages to add functionality, validate forms, communicate with the server, and much more. JavaScript is easy to learn. You will enjoy it." (*2)

Webcrossing also has an older scripting language called Web Crossing Template Language (WCTL). WCTL is completely unique to the Webcrossing platform, and rather awkward to use. In this post I'll give a few examples of why SSJS is preferable to WCTL for new development, and why it is also generally easier to use, read and learn.

While this is true, many of the out-of-the-box scripts (or "templates" as they are sometimes called in Webcrossing lingo) go way back, before SSJS was created, and are still written in WCTL. Until WCTL-based scripts are completely replaced, developers often encounter WCTL sections of existing code, so they should have some familiarity with the WCTL syntax. Hopefully WCTL will disappear over time and Webcrossing developers will be able to avoid two learning curves.

However, if you are creating a completely new Web 2.0 application from scratch, you can blessedly ignore WCTL altogether and just concentrate on object-oriented server-side scripting using SSJS.

SSJS has all the control structures WCTL lacks

There are many things which are quite awkward to accomplish in WCTL, because of the lack of standard control structures. Those same tasks are quite easy in SSJS.

For example, let's say you simply want to output the numbers from 1 through 10 and their squares.

Here's how you would do it in WCTL:

%% set n 1 %%
%% while n <= 10 %%
%% n %%,%% n*n %%<br>
%% set n n + 1 %%
%% endwhile %%

(And you'd better hope you are not continuing to use the "n" variable in your chain of execution because it's impossible to create a local variable in WCTL.)

In SSJS you could write this more simply as:

for (var n=1; n<=10; n++) response.append (n + ',' + n*n + '<br>');

Or if you want to use the SSJS "+" shortcut for response.append you could write it this way:

for (var n=1; n<=10; n++) {
+ n + ',' + n*n + '<br>';
}

SSJS uses response.append() to build the "response buffer" (the page being dynamically created to serve to client browsers) instead of client-side document.write(). Otherwise, this example looks like ordinary JavaScript.

While WCTL only has while loops, SSJS has all the control structures of standard JavaScript, including while loops, for loops (both incremented and for/in loops for associative arrays) and do/while loops.

SSJS also has switch statements, which are not available in WCTL.

Other basics missing from WCTL, all present in SSJS, include:

• local variables,
• functions with parameters,
• labels,
• arrays,
• objects and
• numbers.

(In WCTL you can perform limited integer arithmetic using strings as numbers, but the number 1 is equal to the string "1" because strings are WCTL's only data type).

Setting/accessing stored node and user properties

Because of the way Webcrossing interacts with its native object-oriented database, there are no separate SQL databases to set up, and no tables or database schemas to design.

One of the great joys of Webcrossing's object-oriented database is that you can directly attach properties to any node - folders, files, messages, discussions, etc., and also to users. Webcrossing lets you just add properties and use them whenever and wherever you like.

Given this inherent simplicity, you want to be able to set and access these properties easily in your scripts. This process is conceptually much easier in SSJS than it is in WCTL.

Let's compare the two.

Suppose you have a root level folder /someFolder. To that folder, you want to attach a property called "color" and set its value to "blue." Remember, we don't need to first create a field in a record in a table anywhere, as would be required with an SQL-based system. We can just "do it."

In WCTL, however, this is awkward compared to "just doing it" in SSJS. In WCTL you have to perform a strange programming maneuver where you first save your current location, then go to the location in question, set the value, and finally return to your current location, like this:

%% set currentLocation location %%
%% setPath("/someFolder") %%
%% set path.color "blue" %%
%% setPath(currentLocation) %%

This does get old rather quickly.

In SSJS this could be written as simply as:

Node.lookup("/someFolder").color = "blue";

I think this is clearly conceptually easier for beginners than the WCTL version, is definitely easier in daily scripting practice, and is also much easier to read.

For setting user properties, it is similarly awkward in WCTL and direct in SSJS. The SSJS version is as simple as:

User.lookup("doug").color = "blue";

Conclusion

I think it's obvious that SSJS is the preferred way to get started for (1) standards compliance, (2) clarity, (3) ease-of-use, (4) available structures, (5) available data types, (6) easiest access to nodes and users in the database and (7) easiest for beginners to learn, with vast learning resources available.

doug

(*1) I learned JavaScript originally through what is still my favorite reference: "JavaScript, The Definitive Guide" by David Flanagan. This is part of the well-regarded O'Reilly series. The book gets revised regularly to keep things up-to-date. If you are completely new to JavaScript, even reading just the first four chapters will open up a world of knowledge to you. And all the core JavaScript objects and their methods (strings, dates, etc.) are in their own easy-to-find sections.

(*2) Online, w3schools has a great JavaScript tutorial at http://www.w3schools.com/js/default.asp.