Comments on: I Want Server Side JavaScript Execution

By: Ismael Ghalimi

Ismael Ghalimi — Mon, 19 Jun 2006 14:27:36 +0000

Bob,

Thanks for sharing your experience on this. The more the better.

By: Bob Urry

Bob Urry — Mon, 19 Jun 2006 09:28:35 +0000

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.

By: Ismael Ghalimi

Ismael Ghalimi — Sat, 17 Jun 2006 16:09:54 +0000

Rika,

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

By: Rika Ng

Rika Ng — Sat, 17 Jun 2006 16:05:58 +0000

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.

By: Ismael Ghalimi

Ismael Ghalimi — Sat, 17 Jun 2006 15:03:18 +0000

Tim,

Right on! Thanks!

By: Tim Moore

Tim Moore — Sat, 17 Jun 2006 07:48:05 +0000

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

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

By: IT|Redux

IT|Redux — Fri, 16 Jun 2006 20:58:02 +0000

[…] 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. […]