Server Side Javascript

Scott Francis
Next Post
Previous Post
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. www.w3schools.com ).

Tags:

  • Greg Harley

    I’ve long felt that one of the key differentiators between Lombardi and most every other BPM suite in the marketplace (open source or commercial) was the existence of what Lombardi terms it’s “service layer”. This is the implementation layer where user forms are assembled, connectors to external systems are implement and data manipulation occurs. Those suites that don’t possess a similar layer will explain that this really doesn’t belong in BPM. Instead they will point to SOA layers and web service connectors. In 90% of cases, these are simply overkill for the level of data manipulation required and mean yet another skill set necessary in the implementation team. Funny thing is, Lombardi really don’t make much noise about this “feature”. Why” don’t know, possibly having an embedded integration layer is not considered a totally modern architecture. But I can say without question, the feature saves time and effort and should be part of any complete BPM suite (in my opinion). Now, all we have to do is resurrect Tcl!!

  • Greg Harley

    I’ve long felt that one of the key differentiators between Lombardi and most every other BPM suite in the marketplace (open source or commercial) was the existence of what Lombardi terms it’s “service layer”. This is the implementation layer where user forms are assembled, connectors to external systems are implement and data manipulation occurs. Those suites that don’t possess a similar layer will explain that this really doesn’t belong in BPM. Instead they will point to SOA layers and web service connectors. In 90% of cases, these are simply overkill for the level of data manipulation required and mean yet another skill set necessary in the implementation team. Funny thing is, Lombardi really don’t make much noise about this “feature”. Why” don’t know, possibly having an embedded integration layer is not considered a totally modern architecture. But I can say without question, the feature saves time and effort and should be part of any complete BPM suite (in my opinion). Now, all we have to do is resurrect Tcl!!

  • LOL, Greg, please let’s not resurrect TCL :)
    but I agree with your points above. In fact, I think you were the first person to make this argument to me – that the service layer is the most differentiating aspect of Lombardi (much to our surprise). There are a few other differentiators from a business perspective, but this one is all about TCO and Time-to-Market with your deliverables…

  • LOL, Greg, please let’s not resurrect TCL :)
    but I agree with your points above. In fact, I think you were the first person to make this argument to me – that the service layer is the most differentiating aspect of Lombardi (much to our surprise). There are a few other differentiators from a business perspective, but this one is all about TCO and Time-to-Market with your deliverables…

  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Server Side Javascript -- Topsy.com()

  • There’s a nice mention of this post, and expansion of the topic, by John Reynolds here: http://thoughtfulprogrammer.blogspot.com/2009/12/businessscript-cobol-izing-javascript.html

  • There’s a nice mention of this post, and expansion of the topic, by John Reynolds here: http://thoughtfulprogrammer.blogspot.com/2009/12/businessscript-cobol-izing-javascript.html