Server Side Javascript

Post by
Scott Francis

I've long been familiar with server-side Javascript because, while at Lombardi, we used Rhino's javascript engine on the server for all kinds of server-side computing tasks.

Why would we use server-side javascript?? Well, recently Read-Write Web has produced an article about the "return" of Server-Side Javascript.? As the article proposes, this idea was often derided in years past, but it makes a lot of sense for BPM, and for applications in general:

Point 1: "Given that you're already using it in the browser, why not stick it in the server too? One language all the way down makes it easier for a single programmer to work on either side of the wire; there's less of a mental shift."

Point 2: "There's also a promising reuse story for this "dual-side Javascript" scenario. Take form validation for example. Right now, it's common to write the same logic in two different languages. In Javascript, you write a validator to give the user immediate feedback inside the browser, and in a language like PHP, you write a validator to ensure data integrity once the form data has been uploaded to the server. But once you switch to Javascript on the server, you just need to write a single validation routine at both ends."

Point 3:? "Javascript performance has also moved forward in leaps and bounds, thanks to browser competition."? Seriously, javascript performance has improved about 40x over the old days.

Point 4:? "Server-side Javascript also dovetails nicely the new breed of NOSQL databases. Being web-native, these databases tend to communicate in HTTP, and in some cases JSON (JavaScript Object Notation) is the message format."? In other words, you can already do these things with Javascript libraries rather than rolling your own code... HTML 5 just furthers this confluence.

Point 4:? its browser roots make Javascript well-suited for responding to events and manipulating the DOM... We didn't use this in our BPM solutions but there are interesting implications for the core technology: "With Comet, the server holds on to the connection for a while, and continues to stream out information intermittently to the browser. The typical example is a two-way chat - as soon as one guy says something, the Comet server sends the message to the other guy. This is event-driven programming all over again, and compared to the usual suspects on the server, Javascript is well-placed to support this paradigm."? Node is another example of this kind of design pattern of keeping a stream open for future events, and writing out new information to the browser.

Finally, Javascript solutions are well-suited for porting to the cloud - they can be generally easily isolated from the OS, hardware, etc., and replicated across identical server instances or virtual instances (or even run in a multi-tenant mode).

Its interesting that a language that was once only deemed suitable for doo-dads in the browser, is now becoming the primary language of interesting web applications (in many cases, thanks to underlying tech like GWT, extJS, YUI, etc.).? In some cases Java is the primary language and the javascript is generated (GWT) but that isn't always the case.

It is a little known advantage of Lombardi's approach to BPM that javascript is the server-side scripting language-? the integration to Java is trivial, as is access to XML, and XML-based APIs.? And its convenient that most everyone knows Javascript and there are easy online resources to use to pick up syntactic details (e.g. ).

More From Blog

You Might Also Like

Driven Day 5: The Final Day of Automation Goodness: Enterprise UX and Design
Read More
Driven Day 4: Application Modernization
Read More
Driven Day 3: Process Automation Day
Read More
We Work With Companies Just Like Yours
Are You Ready?

Let’s Work Together

BP3 gets you there fast. Contact us today to see how we can bring more focus, foresight, and follow-up to your projects.