I Want Server Side JavaScript Execution

Wednesday, June 7th 2006 | Ismael Ghalimi

When I met the good folks at Salesforce.com earlier this week, one of our subjects of discussion was how to allow developers to add custom business logic to applications that are deployed on the AppExchange. Currently, the only way to do that is to use the AJAX Toolkit, which generates JavaScript code executed on the browser side. This tool is great, but I advocated for a server-side counterpart that would also use JavaScript as scripting language.

Executing JavaScript on the browser side is great for building quick mashups, but it raises some scalability and security issues that could be addressed by moving the code to the server side. Traditionally, doing so required rewriting the code in Java or PHP, but with the availability of a good Java-based implementation of JavaScript — Mozilla’s Rhino — it seems to me that executing similar JavaScript code on the server side would be an interesting alternative.

Of course, not all JavaScript code can be moved from the browser to the server, especially if such code manipulates the DOM in an interactive fashion based on inputs received from the end-user. Nevertheless, for scenarios where JSON feeds are processed by some snipet of browser-side JavaScript code to generate static HTML fragments, moving such code on the server side should be a fairly trivial exercise. With the proper set of restrictions and coding patterns, it should be possible to move code back and forth between the browser and the server.

There are multiple benefits to this. One is the ability to use browser-side execution for prototyping and server-side execution for production. Another is the ability to run the code where it makes the most sense. For example, one of the objections expressed against Office 2.0 spreadsheets is the fact that some calculations run very slowly when they are executed on the server side, as is the case today — read comments to this post for more context. In many instances, moving them back on the browser side would certainly make things faster. But when datasets become too large (think gigabytes, or even terabytes), downloading all the data on the client would be a bad idea — with both Office 1.0 and Office 2.0 spreadsheet editors. In such cases, leaving the data on the server will save a lot of bandwidth and make everything faster. This kind of code mobility could open up the door to a new set of online applications that are just impossible to properly implement today.

Yet another benefit is that having to learn one language is easier than having to learn two. JavaScript and PHP have similar syntactic structures, and switching from one to the other makes everything a lot harder than it should be. Being able to use the same syntax and the very same libraries for both processing tiers would certainly make our lives as Web 2.0 developers a lot easier.

Now, there are some challenges in trying to do such a thing, as Adam Gross pointed out. For one, there is no JavaScript virtual machine that can support multi-tenancy by isolating user contexts from each other. Nevertheless, I can see two solutions to this problem: one would be to add support for multi-tenancy in Rhino — thank you Open Source; another would be to use the right kind of virtualization technology. It seems to me that 3TERA could be used for that [Disclosure: I am an advisor for the company].

In any case, Salesforce.com seems to have put the right people to the job, and I cannot wait to see what they will come up with. In the meantime, I recommended that they add support for JSON and GDATA (the Google Data API). This would make enterprise mashups a lot easier than they are today.

Entry filed under: Office 2.0

7 Comments - Add a comment

1. IT|Redux&hellip | June 16th, 2006 at 12:58 pm

[…] The question regarding the use of large datasets with Office 2.0 applications is an interesting one too. Antoine pointed out that Office 2.0 spreadsheets could not display spreadsheets with 65,536 rows, as Excel can. Well, that is true today, but I must voice two objections: first, how many owners of a license for Microsoft Excel ever developed a spreadsheet with more than 1,000 rows? I highly doubt that more than 5% did. Second, how about spreadsheets that would have 600,000 rows? Or 6 million? Or 60 million? For the truly advanced users that are using a spreadsheet to analyze very large datasets coming from datawarehouse systems, Excel cannot handle the load either, and data has to be pre-processed on the server side anyway. In that respect, the browser-server architecture of Office 2.0 spreadsheets and the ability to move code from the browser to the server as described in this previous article has far more potential than Excel’s traditional client-server architecture. […]

2. Tim Moore | June 16th, 2006 at 11:48 pm

I agree totally. Someone pointed me to this project earlier this week.

It’s still in a very early stage, but it looks promising.

3. Ismael Ghalimi | June 17th, 2006 at 7:03 am

Tim,

Right on! Thanks!

4. Rika Ng | June 17th, 2006 at 8:05 am

I used to work with Broadvision 4.0, which uses its own server-side JavaScript engine for the presentation layer. They also called it JSP (JavaScript Server Pages), ha, ha: those were the days when Sun just launched J2EE and was evangelizing it everywhere.

The concern then, as is now, would be how to use a loosely-typed language like JavaScript to handle precision-based business rules. For example, will you write your loan application processing rules using JavaScript?

AJAX will certainly introduce new complexities and new design patterns in application development, but I’m not sure I want JavaScript back on the server side again. It has a lot of catch-up to do compared to Java.

5. Ismael Ghalimi | June 17th, 2006 at 8:09 am

Rika,

For complex rules, I think one should use a Business Rules Engine.

6. Bob Urry | June 19th, 2006 at 1:28 am

I have just recently spent many waking nights building an application to run in a browser. While learning to program in JavaScript for things other than simple GUI scripting, I have constructed a set of working practices to guide how I would distribute the functionality between browser script and the server.

I take the view that the browser should normally be used to manipulate the presentation (or the View of the MVC) layer. If you try to put to much more on you’re really moving back to having a “fat” thin client! Worst still, you tend to be moving the application across the network at runtime, unless you have a very good caching policy. You then need to off load the main part of the processing to the server, delivering only the visible content to the screen. I tend to choose to talk straight to the process layer on the server.

While there are JavaScript tools to be found, and more are on the way, there is a lack of support in this space for serious development. Most of the tools that are evolving seem to support AJAX. It would be better if there was better support for JavaScript first, then have AJAX support on top. This would certainly better help developers extend AJAX.

There is a case for enhancing (or even redefining) the capability of JavaScript to provide better support for a number of things that should include a rationalization between different browser vendors, multi-threading, security, DOM manipulation and general object management. The way things are developing with Web 2.0, this would seem to be one of the most important things to look at. Having said that, I found that the use of XML and support for transformation, etc, to be very useful when working with BPEL in the browser.

7. Ismael Ghalimi | June 19th, 2006 at 6:27 am