Thursday, January 29th, 2009

What Server Side JavaScript needs; Join in!

Category: JavaScript, Server

Kevin Dangoor, colleague of ours in the Mozilla Developer Tools group, has created a Server JavaScript group to discuss what server side JavaScript needs. It feels a little like the Java world pre-Servlets, with many similar but different APIs in implementations. Let’s listen to Kevin’s thoughts, and let us know your thoughts!

Server side JavaScript technology has been around for a long time. Netscape offered server side JavaScript in their server software back in 1996, and Helma has existed for a number of years as well. But, server side development has changed a lot over the past few years.

Aptana’s Jaxer gives an innovative view of how you can leverage a JavaScript environment running on both sides of the wire (client and server). Very convenient communication and the ability to easily share code between client and server are big benefits of running JavaScript on the server.

Jaxer and Helma are interesting projects, to be sure (and there are many others!). But what I see missing from JavaScript on the server is not interesting projects, but rather a useful ecosystem. People working in Python like to talk about the fragmentation of web frameworks and whatnot, but that’s nothing compared to the fragmentation of JavaScript.

For example, JavaScript needs a cross-interpreter standard library. Thankfully, some amount of standard library exists (the part inherited from the browsers). So, you get regular expressions and dates. But, what about files and directories? Why can’t the same API be made to work in Rhino, Spidermonkey, V8 and JSCore?

A handful of standard interfaces. Connecting to a database and running queries is a well understood and common problem. In Rhino, you get to use JDBC. But, JavaScript really should have its own cross-interpreter standard like Python’s DBAPI. It should also be possible to take a webapp that was originally deployed behind an Apache module running Spidermonkey and then put it behind Jetty thanks to a standard web server/web app interface.

JavaScript needs a standard way to include other modules and for those modules to live in discreet namespaces. There are easy ways to do namespaces, but there’s no standard programmatic way to load a module (once!). This is really important, because server side apps can include a lot of code and will likely mix and match parts that meet those standard interfaces.

There needs to be a way to package up code for deployment and distribution and further to install packages. Linux people will correctly point out that they can just type “apt get” (or yum, or whatever) and their work is done. But there are a lot of people using Macs and Windows who need a convenient way to get their development environments set up and to package up the code they write for deployment and for other people to use.

Part of the distribution and installation problem is a package repository. I don’t know if JSAN is the answer there, but I do know that an easy way to install a package and its dependencies makes a huge difference in how many libraries people will likely pull together in their apps.

And, on top of all of this goodness, we’d get template engines, object relational mappers, middleware, packaged apps, etc. In fact, many of those things already exist. But, the problem is that they have no common basis to sit on. And that’s what prevents an ecosystem from growing.

If you search the Python Package Index for WSGI (the Python standard for connecting webapps with web servers), you’ll find 180 packages today… servers, middleware, full blown applications. And those are just the packages that have “WSGI” in their listings. That’s what an ecosystem looks like. And Java has one, and Ruby has one, and JavaScript needs one.

It’s also worth noting that many of those WSGI components can run unchanged on CPython, Jython and IronPython, thanks to a common standard library. JavaScript has a collection of implementations in C, as well as Java and .Net implementations and there just needs to be a little agreement on some interfaces and such. Libraries that run in all of those places can attract more users and, hopefully, more committers to help the libraries grow.

What I’m describing here is not a technical problem. It’s a matter of people getting together and making a decision to step forward and start building up something bigger and cooler together.

To that end, I’ve set up a new ServerJS group in hopes of getting the interested parties talking and maybe even to get us together face-to-face to produce some code and settle on some interfaces. There’s a tremendous collection of JavaScript code out there already, and let’s see if we can make all of that code that much more valuable.

In the web developer tools group at Mozilla, we have a wide open charter to help software developers make the best use of the open web. Doing our bit to help the server side JavaScript community grow and flourish can certainly be a part of that.

Posted by Dion Almaer at 11:10 am

2.9 rating from 115 votes


Comments feed TrackBack URI

I feel like I’m in a time warp and the remnants of Netscape are rewriting Netscape Enterprise Server LiveScript. :)

Comment by cromwellian — January 29, 2009

Wow, I don’t know why all the negative votes (and no responses). I thought the article was very honest and well thought it. It describes several of the reasons why I haven’t attempted to use javascript on the server yet.

Comment by tj111 — January 29, 2009

i think someone wrote a votebot or otherwise cheated. Anyway, the one thing Jaxer needs for me to get started with it is access to PostgreSQL on *nix, rather than just Windows.

Comment by eyelidlessness — January 29, 2009

I’d rather have C# (or whatever) on the browser than JavaScript on the server. Is it mandatory for an ajaxian to like JS?

Comment by JohnDeHope3 — January 29, 2009

I would love to see the PHP language replaced by JavaScript. PHP is so similar to JS anyway, why not simply replace it. Like Adobe replaced Lingo with some JavaScript dialect some years ago.

Comment by Spocke — January 29, 2009

A great server side implementation of JS should retain the flexibility and simplicity. It should still be normal JS, but with a few more built in objects (ala PHP). In my dreams, it looks something like this:


var conn = new MySql.Connection("localhost","root","password");
var query = new MySql.Query("SELECT * FROM employees");
for (var result in query) {
document.write("Employee: " + result["name"] + "")
delete query; // unpollute, of course

And of course you would have the option of including frameworks.

Comment by mjuhl — January 29, 2009

@JohnDeHope3 : C# in the browser, uhhhh,
@Spocke : PHP and JavaScript are totally different, the only major thing they have is that are too easy to start with, and the newbies learn some bad practises

As for the article I really agree with most of the stuff there, JavaScript will be a great server side language. I haven’t got time to try Jaxer, but I think to change that soon.

Comment by RStankov — January 29, 2009

for me

I like jaxer too

Comment by nunziofiore — January 29, 2009

Oh to have a standardized JavaScript interpreter on the server! The (only?) great thing about PHP is that it is available everywhere. I think server-side projects often default to PHP because it is so ubiquitous (at least I do). I know I personally would choose JavaScript instead, if it were also so readily available. Ruby-on-Rails was rapidly became part of the standard distro. If only we could also get JS distributed with a common system API. In this new discussion group, perhaps the various server-side JS distributors could work on a standardized library that wrapped all of their implementation-specific code.

Comment by westonruter — January 29, 2009

I think it’s great that Ajaxian finally figures that without the server it’s nothing but DHTML and that to get the server into the picture is Alpha Omega. Though JS on the server is *not* the solution. The “multiple programming languages problem” when doing Ajax development is only *one* of the problems, and there are at least 10 other problems of equal size. And to put JS on the server creates like 50 *new* problems…!
Sometimes it seems as if the people of the the world is destined to not being able to learn from other people’s experience and mistakes. It really annoys me … :(
But I guess noobs are bound to make their own mistakes, and there’s nothing I could ever do to help them avoid it. And people will try to do JS on the server for 5 years before miserably failing and resorting to the “next mistake”…
But hey, good luck…

Comment by ThomasHansen — January 29, 2009

What Server Side JavaScript needs… to die?

Comment by rubley — January 29, 2009

I’m no ‘noob’ (30 years of programming experience) and I’ve been devleoping server-side JavaScript for a decade, at least. The only difficult thing I’ve encountered was working with binary strings in javascript, but even that I managed to overcome using native JS code (no plug-ins). Other than that, I have been enjoyed developing robust and functional server-side JS applications, and will continue to do so.

Quite often I can even use client-side code on the server, for various reasons. The ablility to re-use code in this way is a total win, and I’ve been able to do often enough to see the benefits.

I started off with JScript in ASP classic, but now I compile the JScript to a DLL using JScript.NET. It runs fast, and it is so easy to use, it puzzles me why more people havent already realized the benefits of server-side JS.

As far as I’m concerned, I really don’t need to look any further than JScript.NET. Every Active-x/COM server plug-in (image manipulation, uploads handlers, etc) made for ASP classic, and ASP.NET works with JScript.NET. This extends the capabilities of server-side JScript quite a bit, and makes it trivial to build powerful applications.

Seriously, I don’t see a down-side of server-side Javascript. Where’s the down-side of javascript on the server? (and “Microsoft is evil” does not apply to this argument simply because I prefer to use javascript on Windows Servers)

Comment by leptons — January 29, 2009

Good points, though I think there are bigger problems than standard calling conventions in server-side JS interpreters. Something like Jaxer takes SSJS a lot farther than most other environments (afaik), allowing DOM manipulation and a form of RPC. Those are pretty significant differences, not just a matter of what function to call for file i/o.

At the same time, I don’t think Jaxer’s style suits everyone. Some may prefer a lighter implementation without instantiating the DOM for every request. JavaScript has always been somewhat fragmented in the browser… I think it will take some time of experimenting with different approaches on the server before any particular implementation style wins out.

I do also wonder about JavaScript’s potential. Like PHP, it doesn’t have strong typing. And it has a very different style of OOP. Something like Jaxer does have its advantages, and PHP has gone far despite not being the greatest language. Still, Python or Ruby seem like better choices for big web apps, just my opinion.

Comment by nathany — January 29, 2009

Can you do (for instance) the dynamic parts of JavaScript/JScript on the server in JScript.Net…?
As far as I know JScript.Net is just built on top of the CLR compiling “JS lookalike syntax” down to IL which hardly makes it becomes “JavaScript” anymore then Managed C++ is C++ and IronPython is Python…?
But I may be wrong, maybe it is a full implementation of Ecma JS specification in which case I was wrong and you were right…
Now the main reason why doing JavaScript on the server is *wrong* the way I see it is because JavaScript is one of very few languages which was written for a *specific purpose* (browser scripting) which made it have a lot of features which are really not features but rather “bugs” in another environment (like e.g. the server)
JavaScript was written to be extremely small – even to the extend that it would be unsafe, scriptable and dynamic – which takes “buffer overflow security breaches” to a whole new level (think what eval(myTextBox.value) could do on the server) etc, etc, etc…
Not to mention that if you create a new runtime to support JS on the server you start on scratch in regards to libraries and such where Python, .Net, Java etc has a *gazillion* existing libs to lean on.
Now if JScript.NET is a full JS implementation then a lot of my arguments collapses, still with C#, Boo and to some extend VB.NET you can do development in a portable environment (Mono and MonoDevelop), choosing not to do it “just because we already know JS” is really not a viable solution…
To put JS on the server is another famous “solving the wrong problem” approach unfortunately … :(
Just like making it easier to develop in JavaScript on the client is…
You can make it extremely easy to develop in JS on the client, and you can also make it possible to develop in JS on the server, still those two doesn’t really make it (significantly) easier to create applications…
And apps is the goal here, right…?

Comment by ThomasHansen — January 30, 2009

Thomas e.a.,

eval == evil. Why on earth would I call eval on the server from something the user/net gives me. It is a problem with almost all languages: never trust the net!

Face it: Ecmascript *is* on the client. Why not use it on the server as well? Code reuse makes it far more stable then trying to do e.g. validation (or encoding/decoding, or lib sharing, etc) multiple times.
Heck, If you don’t like js, then use $ilverlight or something.
Doesn’t it feel strange that a language, designed minimalistic and over 10 years ago, has such a huge impact on programming today.
Fundamentally different but easy to grasp OOP are one of the key contributors for it…

Don’t get me wrong: server sided you should at least have a decent option for JS. Don’t look at it as a total replacement language for anything server sided ;-)
There’s room for every language there :-)

Comment by PieturP — January 30, 2009

“So what is the right problem?”
Making it easier to create applications…
But to solve that problem we must realize that the browser is nothing but a powerful view…
Currently GWT and Ra-Ajax (to those who don’t know it I work with Ra-Ajax) are the ones that seriously have managed to solve *that* problem…
Anyway, you (TNO) know me well enough to know my stand about this… ;)

Comment by ThomasHansen — January 30, 2009

So you’re saying we shouldn’t put JS on the server because Framework X “solved” that “problem” and at the same time we shouldn’t build applications in browser’s because everybody has one and they’re powerful?

Comment by TNO — January 30, 2009

The most probable reason for why people would put (and consume) JS on the server is to remove the “two language barrier” and that’s not the real problem. The real problem is that it’s difficult to create applications for the web. And to put JS on the server is “moving closer”, but not anymore then to kill a pimple on your cheeks when you’ve really got brain cancer…

Comment by ThomasHansen — January 30, 2009

To share a type system, libraries and such would probably be a great addition and make things easier. In regards to JScript.NET that would never be possible unless we embed the CLR on the client – which effectively is what Silverlight is doing. And when shit hits the fan I think we all know what Silverlight is – ActiveX2.0…
In general a runtime and a language for the server would have very much different needs then a runtime for the client. For one security is far more important on the server while size is far more important on the client. So all the features that makes JS extremely small would not be a benefit on the server since it would compromise the things that’s important on the server. Some would also argue that dynamic typing is great on the client, but bad on the server – I don’t want to start a language war here for dynamic versus static typed languages, but it’s an interesting argument…
Let’s take one simple example, look at the Object.extend method from prototype.js (which have equivalents in all major JS libraries, including also Ra-Ajax)
Object.extend is often used to create “inheritance chains” between prototype objects. This works perfect on the client, but on the server you might have thousands of users hitting the iron at the same time. Now you don’t want to extend the prototype objects for every request since it’s just plain stupid and this could be shared among all requests as long as the application lives and to re-create the inheritance chain for every request would burn a lot of unnecessary resources in server land for you. However to “cache” them creates multi thread issues since thousands of users might hit your server at the same time. Now this could be out-factored to some “Application.StartUp method”, though this creates additional “design patterns” for server-side JavaScript. And as we all know after reading Paul Graham’s logic on Lisp, Design Patterns are created to make up for lacking and badly implemented language constructs, right…? ;)
Now this is just one example, and it was the first one to hit my consciousness. If we search we will probably find thousands of other problems…
End of the day the code gets complicated. Why…?
Because JS isn’t written for doing server-side code, JS is created to be as small as possible and to live in “client-land”.
Now to share a type-system, libraries and data structures would probably be awesome. When I started with Ajax about four years ago I created something called O2X and X2O which means Objects To XML and vice versa because I thought that to serialize to and from XML on both the client and the server would be awesome. Then I discovered JSON and agreed insanely with Doug on that JSON is superior to XML. So I created O2J and so on. Finally I figured that all those problems are not interesting at all, the one problem that’s interesting is to make it easier to create *applications*. Today Ra-Ajax uses JSON internally to serialize from server to the client, but you wold probably never notice if you used Ra-Ajax since that’s not even an interesting problem because the *interesting* problem when doing application development is how do you make it easier to create applications. For ASP.NET and Ra-Ajax that happens to be “how to modify and manipulate WebControl objects on the server and propagate those changes back to the client”. Now if you need to serialize your own data from the server to the client using some “JSON library” then I haven’t done my job! And there’s a missing feature in Ra-Ajax (or a bug)…
The way to go is to think about the client as a “view” or a “surface”. Ra-Ajax tries to do that, GWT also to some extend. Look at Jack Slocum, this guy have been spending like 5 years making “JS easier to develop in”. Then he probably starts investigating GWT after reading all mine (and others) bashing of “JS development”. Catching; Ext-GWT…!
Even John Resig has started “talking about the server” now. Though with very small steps…
And prototype, the “original JS library” was written to reduce syntactical differences between server and client by adding stuff like “each” on arrays and so on which existed in Ruby…
The problem about libraries and code isn’t that there’s “too little”. The problem about code, libraries, constructs and solutions is that there are too many, and 99.9% of all the “solutions” in this world are not really “solutions” but rather “problems of themselves” – and very seldom the best solutions prevails. Look at Lisp, Boo and Haskell, these languages are far better then all the most popular ones alive today. Still they have combined probably less then 0.1% adoption and usage. Even though Lisp has been around since like the 50s or something. In 50 years from now it is highly likely that all major languages have implemented every feature from Lisp and that we don’t need “Design Patterns” anymore.
JS on the server is not a solution, it’s a problem! We’ve tried to do JS on the server since like 1995 (ref; Netscape and classic ASP), and it has never worked and it never will. In “server-land” JS is an inferior language just like C# and Java are inferior languages on the client (think Silverlight, ActiveX, JavaFX and Java Applets)
It is solving the wrong problem!
But hey! Don’t believe me, waste another 10 years trying … ;)

Comment by ThomasHansen — January 31, 2009

It is very simple; Javascript on the front-end. JSON as the transport. JavaScript on the back-end. It’s just so easy. Ok, ECMAScript if you like, JScript, ActionScript, whatever, it’s very interchangeable.

I’ve done plenty of other languages on the back-end – php, python, perl, mason, vbscript,, java – and always used javascript on the front-end. I’ve also implemented too many XML based transport systems to never want to do it again. Seriously, every browser and back-end has its own ways/quirks to traverse an XML document. No more. JSON and Javascript are the only tools I need to create very powerful web applications, the only problem I have is LACK OF TIME. Programming is the least of the problem for me now. Using one system has many advantages to saving me time and frustration. I will say that I haven’t used JScript.NET for any high-traffic situations YET, but if the specific project is designed well enough, I don’t really see a problem. Compiled JScript.NET runs just about as fast as compiled C# or VB.NET (its .NET CLR after all).

@TNO – I agree with everything you said.

@ThomasHansen – JScript.NET is actually the same as Actionscript 3, and both are based on ECMAScript 3. You obviously know a lot about programming with Javascript. I wonder if you use mac, linux or windows primarily. Windows Script Host is a great place to get used to javascript on the server-side or as an application programming language. Its really fun to also be able to write .NET applications that run like any other .NET windows-form app using Javascript. If you haven’t, you should take a look at MSDN, in the JScript section, and the .NET 2.0 class library.
I think MSDN is one of the best documentation sites i’ve ever used. They don’t promote JScript as much as they should but I think that could change once it bubbles up to the people in charge at MS that JavaScript is experiences a bit of a renaissance lately. V8 and SpiderMonkey should provoke the expected reaction from MS somewhere down the road. Sometimes they lead and sometimes they follow.

Comment by leptons — January 31, 2009

I see your point about having JSON and then JS on both sides, how does that work though…?
Can you really use the JSON sent from the client as “code” when it reaches the server…?
I thought it had to be compiled anyway to support the CLR which means either it needs to run through a (*seriously costy*) compilation process or it someway bypasses the CLR and is “faked”…?
I don’t think Microsoft will “follow” here unfortunately, they are way too much invested in ActiveX2.0 (Silverlight) … :(
And Ajax is *way* too disruptive for them. Windows API have been their main lock-in ever since they started getting “real”…
If you’re on .Net you should seriously check out (Disclosure; yes I still work with Ra-Ajax)

Comment by ThomasHansen — January 31, 2009

Can you really use the JSON sent from the client as “code” when it reaches the server…?
Yes you can, and you don’t have to use eval. Jaxer should have the JSON global built in since it runs on Gecko. Otherwise you use Crockfords JSON library to emulate the Global (which is part of the ES3.1 standard)

So all the features that makes JS extremely small would not be a benefit on the server since it would compromise the things that’s important on the server…..We’ve tried to do JS on the server since like 1995 (ref; Netscape and classic ASP), and it has never worked and it never will.
Why is Rhino as popular as it is now especially with Google? Why does classic ASP refuse to die? Why is Microsoft Developing ManagedJScript? Why is Jaxer gaining popularity daily? This is all evidence of the fact that it IS working, and people want more of it.
Your entire argument of object.extend is a strawman. If you developed your application following the TSA paradigm, none of this would even come up as an issue and the server language would be irrelevant.
Continuing to treat the browser as little more than a view is dooming the web to never have the richness a traditional desktop application provides. The speed of light can only travel 500 miles in 3 milliseconds, this is a fact you can’t get around. Take that delay and add server processing time, client rendering time and all things in between and that leaves you with what? A pretty poor user experience in my book.
Even John Resig has started “talking about the server” now
Probably not in the way you are thinking. Got a reference?
The problem about libraries and code isn’t that there’s “too little”. The problem about code, libraries, constructs and solutions is that there are too many, and 99.9% of all the “solutions” in this world are not really “solutions” but rather “problems of themselves”
Which is what the discussion group aims to solve, and is the point of this article.

Comment by TNO — January 31, 2009

Correction on the first paragraph. formatting is messed up:
Can you really use the JSON sent from the client as “code” when it reaches the server…?
Yes you can, and you don’t have to use eval. Jaxer should have the JSON global built in since it runs on Gecko. Otherwise you use Crockfords JSON library to emulate the Global (which is part of the ES3.1 standard)

Comment by TNO — January 31, 2009

I thought it had to be compiled anyway to support the CLR which means either it needs to run through a (*seriously costy*) compilation process or it someway bypasses the CLR and is “faked”…?
Any ES compliant implementation exposes either the JSON global or eval, so no pre-compilation is needed. Alternatively you could trivially tokenize the string into an object (In JS, strings, properties and method names are interchangeable).

Comment by TNO — February 1, 2009

@TNO and @ThomasHansen how often have I seen you two spamming the comments on ajaxian?

CLI bytecode is strictly typed, so there must be some significant differences between and javascript.

Comment by grumpytoad — February 1, 2009

As long as it stays relevant to the topic, I wouldn’t call it spam.
In regards to the bytecode, oftentimes portions are compiled into a generic Object type which causes it to run inefficiently compared to stricter languages. Hence Microsoft’s re-invention of Managed JScript on top of the DLR

Comment by TNO — February 1, 2009

“CLI bytecode is strictly typed, so there must be some significant differences between and javascript.”
…touche…! ;)
To build anything which is untyped on the CLI is *impossible*. And JSON sent from the client is per definition untyped…
Even Boo which has most “dynamic features” like duck-typing, functional objects etc actually just mimics a “dynamic language”. To convert JSON to .Net code (any language, including JScript.NET) *must* carry quite a lot of overhead since the JSON actually must be parsed some way or another. At least until the CLI itself is no longer typed… Unless you choose to compile it that is (which is a “counted in number of seconds operation” by itself)
“The majority of the time and effort in many professional applications comes from the design phase, not the development phase.”
Show me then…!
AND show me some *code*…!
It’s 19:55 now in Norway – GMT+1, if you (or anybody else in this world) can port the above link (Calendar Starter-Kit) to any JS based framework before 02:00 GMT+1 with the same amount of security, stability, ease of maintenance etc – I will *shut down ra-ajax* and pick whatever JS based framework you did it in to develop in for the rest of my life…!
You don’t even need to design anything there, the “design” is in the existing application…!
You can even download the (LGPL licensed) code to look at if you wish…!
JavaScript has a lot of really spectacularly cool features like functional objects, dynamic typing, prototype inheritance which combined makes for a pretty cool, interesting and cutting-edge code-model.
However “stuffing JS on the server” gives us *nothing*…!
At least not by itself…
The problem is that the communication between the server and the client combined with the fact that you need to stuff code in both places makes it become really difficult to maintain (you need to change in two places when you do changes to one), less secure (it’s way too easy to leak business logic to the client), cries out for all sorts of weird and new constructs (O/RM libraries on the client in JS anyone…! :S), harder to learn (need to mess around with XHR, two runtimes, DOM, browser differences etc), less portable (it’s way to easy to implement something stupid in JS that doesn’t work on Opera x or Safari y), consumes *way* more bandwidth (amount of JS explodes as you create your solution), increases your attack surface (by forcing you into opening up stuff like WebServices etc for retrieving data)…
…I could go on like this forever!
But instead of doing that I’ll tell you how MSFT sell Silverlight in these days…
“And the alternative is to develop in JavaScript yourself” (then a loud fucking laughter goes through the audience as Don Box goes on to talk about the “MVC initiative” in Silverlight…)
Regarding; runat=”both”…
If you think the above solves anything you’re going to feel really ridiculous ten years from now when you understand why that is just a perfectly stupid example of a “solution”…
Let me name some samples;
var password = ‘xyz_456’;
Sure if you develop utilizing every single anti design pattern that exists, you might want to propagate “well known types” between the client and the server, however if you find the need to have “well known types” floating between your server and its client you’ve already got *way* larger issues then “runat=’both'”…
If you develop correctly then there’s not *one* good example of that you need the same code included on both the server and the client…
Giving up now…

Comment by ThomasHansen — February 1, 2009

And JSON sent from the client is per definition untyped
The types are String, Object, Array, Boolean, and null.
To convert JSON to .Net code (any language, including JScript.NET) *must* carry quite a
lot of overhead

Worst case scenario if one had to tokenize the string, creating an object from it would look
something like this in JS:
parsedObject[tokenName] = tokenValue;
Plus, there is no reason why SSJS would necessarily have to be compiled.
Show me then!
Once again, you’re deferring the issue towards your framework. If I copy and pasted all of your source code and ported it
to JScript.NET using an automated tool, would that count? The point is that there is not a sufficient reason NOT to allow
JavaScript to be a 1st class citizen of the server, and the arguments thus far have been due to a misunderstanding of what it
entails.Obviously you will take absence of evidence as evidence of absence, but oh well. I don’t care enough.
O/RM libraries on the client in JS anyone…! :S
Kris Zyp’s proposal is quite an interesting alternative to this “problem”
Let me name some samples;
var password = ‘xyz_456?;

Why would you place user information such as this anywhere in your code? Would not such things be determined by inference
from an encrypted database or from your encrypted web config? The things you would want to runat=”both” would obviously be
utility related an not security related. Such as user input validation, or some method to parse and create
a communication package.This allows you to avoid copy and pasting the same code and maintaining those multiple files.
Sure if you develop utilizing every single anti design pattern that exists, you might want to propagate “well known types” between the client and the server,
I think Schema’s would fall into this category yes? And those are debateably good things
Giving up now…
I’ll have to agree, this is going nowhere.

Comment by TNO — February 1, 2009

To me, the question of whether it should be Javascript on the server is irrelevant… the language being used isn’t what really matters.

The question, in my opinion, is if there is a rich library that whatever language you choose can use.

I for one *love* Java on the server. Oh, not every aspect of it of course… if EJBs were a person I’d be in jail for killing that person in short order :) But the fact is that just taking a basic JRE, sans any other specs or libraries, is tremendously powerful. If Javascript on the server, or PHP, or VBScript, or Ruby, or whatever else you choose to try doesn’t have access to a library as powerful as that, then it’s a non-starter for me. And it better be extensible too with add-on libraries and whatnot, as Java is.

I don’t see any real downside to Javascript on the server as the language per se, but nor do I see any real upside. Sure, the idea of being able to use the same language on both sides of the fence is attractive, but not enough to be a deciding factor for me. Maybe if everything else was equal it would be, I’m not sure.

Also, the combination of Ext JS + DWR pretty much == perfection to me. I get that RPC mechanism being talked about here, plus I get all the power of Java on the server plus a kick-a** client-side library. Java versus Javascript language-wise isn’t so different that most competent developers have an issue, so once again the fact that it’s not all the same language across the board doesn’t hurt my head much.

So, what does Javascript on the server need? Access to a library of existing code at least as rich and robust as Java provides. So long as it provides that (and I know many implementations I’ve seen do provide access to the Java class library) then there’s at least something to consider. If it doesn’t give me that though, then the discussion is a non-started.

Comment by fzammetti — February 1, 2009

Leave a comment

You must be logged in to post a comment.