pros and cons of serverside javascript implementation??

Question

Hi,

I just started experimenting with Aptana Jaxer server side javascript engine for my next project. And i have few quesions about that

• By using server side JS, can we implement the whole web application without using any server side languages (like C#,java etc). Or server side JS sits in between the web server and other langauge stack.

• Is it really a better approach ??

• what are the advandages and disadvandages?

• how this works well in terms of performance?

• is there any real time implementation (public websites) only using server side JS(no other languages)?

• what are the alternatives available over Aptana jaxer (open source)??

• how well we can implement & maitain db transactions? can we do that in serverside JS..?

• is it possible to develop RESTFul and SOAP services in serverside JS..??

i know this is too long (and naive questions). I am just hoping someone have already come across all these while implementing serverside JS.

EDIT:

As per Matthew & Ken comments, i have added some clarity to the question Is it really a better approach??

this is what i intend to ask..

Is it really a better approach than using server side languages (assume c#), how we can compare this with the c# implementation of a website (performance , language features)?? And which one is a better approach , using JS alone in serverside or JS in middle layer between other language stack and webserver??

Cheers

Ramesh Vel

Answer 1

By using server side JS, can we implement the whole web application without using any server side languages (like C#,java etc).

It shouldn't be necessary to write code in any other languages, although many server-side JavaScript frameworks use the Rhino engine, which allows you to call any Java code.

Is it really a better approach??

I don't think JavaScript (as a language) is really a better or worse option than traditional server-side languages. It has advantages (along with other dynamic languages like Ruby and Python) like flexibility, fast prototyping (no pun intended), flexibility, etc. On the other hand, it doesn't have the library support that Java and C# have or static typing (I won't get into the debate over which is better here; I like both for different reasons).

If you want the best of both, you can use JavaScript as a scripting language, embedded in your application. Rhino for Java, and JScript.NET make it easy to manipulate "native" objects in JavaScript. You could, for example, write your domain classes in Java or C#, and script them with JavaScript where you want more flexibility. If you are comfortable enough with JavaScript, writing in a single language may be simpler though.

I've never written a "real" server-side application using JavaScript, so I can't really make a judgment about whether its better or worse than .NET (I've also never used JScript.NET). I have played around with a few frameworks for fun though and I'm currently rewriting my personal site using Helma NG. So far it's been a good experience (much better than PHP, which I've never really liked).

what are the advandages and disadvandages?

Advantanges:

• Only one language needed for server-side and client-side programming.
• Possibility for shared code, for things like form validation. Jaxer lets you run scripts on the client, server, or both.
• You get to program in JavaScript (assuming you like the language).

Disadvantages:

• Many frameworks are experimental/not very mature.
• You have to program in JavaScript (assuming you don't like the language).

how this works well in terms of performance?

Performance should be approximately comparable to other scripting languages.

is there any real time implementation (public websites) only using server side JS(no other languages)?

I don't know of any large websites using JavaScript, but there may be some.

what are the alternatives available over Aptana jaxer (open source)??

Wikipedia has a large list of options, but it doesn't have much useful information. There are lots of options with a wide range in maturity and size.

Here are a few that I'm familiar with (to varying degrees)

• Helma - Rhino (Java) based framework with active record.
• Helma NG - Helma Next Generation (experimental rewrite, under active development).
• Phobos - Has good support in NetBeans.
• v8cgi - Small and simple, uses Google's V8 engine, probably not production-ready yet.
• Jaxer - Runs on Spidermonkey with a DOM implementation, so you can manipulate the page with frameworks like jQuery or Prototype. Has good IDE support in Aptana Studio.

how well we can implement & maintain db transactions? can we do that in serverside JS..?

Rhino-based frameworks let you use Java classes, so you have full JDBC support. I haven't used Jaxer's database libraries, so I don't know anything about its capabilities.

is it possible to develop RESTFul and SOAP services in serverside JS..??

RESTful APIs shouldn't be any problem. I don't know of any specific support for SOAP, but it should be possible.

Answer 2

As a preface, I use SSJS at my day job. We run a reasonably large (in terms of complexity as well as page views) website on SpiderMonkey. I'll add to Matthew's excellent answer where I have experience.

Is it really a better approach than using server side languages (assume c#)

"Better" really depends what you want to do with it. JavaScript itself has some great features, as well as pretty awful ones. If you're serious about developing JS (client or server), I cannot recommend highly enough that you watch Douglas Crockford's presentation, Javascript: The Good Parts if you haven't already. He's done a fantastic job sorting out the cruft, and he's an excellent speaker to boot.

The biggest thing that I find the SSJS world lacking right now is maturity. I'm not familiar with C#, but JavaScript has no mature standard library, and no mature means of package distribution. To me that's a big piece of the puzzle.

That said, keep your eye on the CommonJS group. They're working toward defining those exact things. Also, The Jaxer Api Documentation lists the built-ins that are included with that framework.

how this works well in terms of performance?

JavaScript itself is not a slow language, nor is it a particularly fast one. As Matthew pointed out, it should be comparable to any other scripting language you would use. The war between the browser vendors to see who can build the fastest browser will benefit the SSJS crowd as well.

The generational garbage collection that the V8 team build into their engine is a great example of this. Halting the virtual machine to free unreachable objects from the heap and reclaim their memory can be somewhat slow, but they've mitigated that by reducing the amount of objects that need to be inspected when the garbage collector runs.

how well we can implement & maintain db transactions? can we do that in serverside JS..?

Jaxer appears to have MySQL and SQLite database APIs. As Matthew mentioned, if you use Rhino, you can use the JDBC api.

Edit: Added links

Answer 3

I am the developer for Myna (www.mynajs.org), an Open Source server-side JS platform based on Rhino and Java. I'll address the issues as they relate to Myna, but many of these points apply to server-side JS in general:

By using server side JS, can we implement the whole web application without using any server side languages (like C#,java etc). Or server side JS sits in between the web server and other langauge stack.

In Myna it is possible to write your entire app in JS. Myna already includes API's for Database access, Object Relational Mapping, crytogrophy, OpenID, etc.

Is it really a better approach than c#/Java?

With a Rhino based server it is trivial to drop down to Java whenever needed. You can easily install open-source/commercial/hand-coded Java libraries and then script them from JS. This means you get the rapid development of JS but maintain the advantages of the Java platform

what are the advantages and disadvantages?

pros:

• Rapid development: In Myna you just create files in the webroot with an .sjs extension. This means you can create an edit-save-refresh browser cycle with is very fast for debugging/tweaking code.

• Easy JSON: Having JS support server-side means moving complex structures is very easy

• Shared code: If you need to perform the the same function on both the server and the browser, you can use the same code

• Dynamic ORM: Statically typed compiled languages make it hard to alter objects at runtime. This usually means that ORM has to be defined in advance. In Myna building ORM is as simple as

  var manager =new Myna.DataManager("DataSource name").getManager("table name");
  

  You get an object that can do all basic CRUD operations without ever explicitly defining the DB tables. As another example you can insert a row with all the matching values from a form post:

  manager.create($req.data);
  

• Functional Programing: If you have started playing with advanced JavaScript features then you will appreciate how helpful they are server-side. Because of the consistent server-side environment it is safe to use advanced features such as Array Extras, generators and iterators, destructuring assignments, and E4X

cons:

• Tools: Statically typed languages like C# and Java have excellent IDE and developer tools. Dynamic languages like JS just don't have the tool support yet. Personally I find that the large reduction in boilerplate code and fussy type casting makes up for this, but this is still a big disadvantage if you have been doing a lot of development in IDEs. If you are currently using an IDE, consider using jedit for dynamic languages

• Maturity/Standardization: Serverside JS is still a new paradigm, and there are many players and no clear winners. ECMA does not have any standards for serverside JS. As mentioned in Brandon's answer, the CommonJS group is attempting to form a serverside JS standard and Myna has experimental CommonJS support via Narwhal

how this works well in terms of performance?

In raw computational speed, few dynamic languages can match statically typed compiled languages like C# and Java. Having said that, it really doesn't matter. Any part of your application that is computationally intensive should probably be written in Java, or use an existing Java library. I wouldn't suggest that anyone write a Database in JS for instance. For real world web applications/SOA services, the primary cause of slowdowns isn't raw computational speed, it is inefficient code, especially database access. Myna helps with this by doing things like:

• internally caching compiled JS scripts
• Internally using cached prepared statements for database transactions
• Query and output fragment caching
• Database connection pooling
• Automatic ETag hash support
• Profiling tools
• Lazy loading of metadata

how well we can implement & maintain db transactions? can we do that in serverside JS..?

If you mean transaction as in "a set of SQL statements that can be reversed or committed", then Myna does not yet support transactions. I am open to implementing this if there is enough interest.

If you mean "what kind of database support does server-side JS have?" then the answer is platform dependent. The Myna platform provides the following database features:

• A web-based administration application where you can define "datasources", i.e database connection information. You can then query these datasources by name. Myna includes JDBC drivers for H2, MySQL, Microsoft SQL Server, and Postgresql, but any JDBC or ODBC datasource can be used
• Myna.Database and Myna.Table provide database-neutral metdata access as well as table creation and modification.
• Myna's Query object supports maxRows, paging, SQL parameters,custom row handlers, query-of-query, caching and more
• Myna's DataManager object supports runtime ORM object creation

is it possible to develop RESTFul and SOAP services in serverside JS..??

REST and SOAP support are platform specific features. Myna's WebService object supports the following protocols:

• SOAP
• XML-RPC
• JSON-RPC
• Ext Direct
• JSON-MYNA (a simple protocol that uses normal form posts and returns JSON. Easy to use from the browser)

Myna also understands the PUT and DELETE request methods and presents access to request body content in both text and binary form, so that it is possible to handle these RESTful methods in an application specific way.

Debugging

Traditional breakpoint debugging is a real challenge serverside. Although Rhino supports debugger hooks, using these from a stateless web app would be pretty involved. Personally I don't even use breakpoint debuggers even when they are available (e.g. firebug). Instead I prefer logging.

In Myna,

 Myna.log(type,label,detail)

will spawn a low priority thread to write an HTML log message to Myna's logging database. These logs can then be searched through the Myna Administrator. Logs also record timestamps and elapsed milliseconds for profiling purposes. Myna.dump(obj) can also be used to present an HTML table representation of any object. Myna also logs all un-handled exceptions with stack traces, source code context, and request details. Between dump(), log(), and the default error handler I haven't much difficulty debugging Myna code