Saturday, November 11th, 2006

Phobos: Does Sun have a good thing under its nose?

Category: Editorial

There have been a lot of discussions on JavaScript on the server side, which naturally comes up as an idea when you consider:

  • Some argue that JavaScript is becoming the platform, more-so than the JVM or the CLR. With Ajax, Flash, and Apollo, this could become even MORE true.
  • Many developers (have to) know JavaScript
  • Many developers are learning JavaScript
  • Include the Flash guys too

Instead of programming in Java, PHP, or Ruby, and having mechanisms to generate JavaScript (GWT, rails helpers, etc), maybe we will end up developing end to end in JavaScript?

Wouldn’t it be nice to be in one language (that is very flexible, and allows you to code functionally, procedurally, OO-ally, etc)?

JavaScript doesn’t have everything it needs. But, there is glue to help it out. With Rhino, the under pinnings could be written in Java, but the developer wouldn’t have to write Java. This always happens of course. My Rails applications rely on a LOT of C code, but I am not spending my time in that area.

What if the next BEA is a company that comes up with the killer JavaScript Application Server?

This is where Phobos comes in:

Project Phobos is a lightweight, scripting-friendly, web application environment running on the Java platform, aimed at addressing emerging developer requirements. Scripting and dynamic languages are growing in popularity among developers, especially for building Web applications. These developers place special value on rapid application development and deployment.
The goal of Project Phobos is to show that Java is an excellent platform for server-side scripting, allowing dynamic-language developers to leverage the power of Java SE and EE. The initial focus for Project Phobos is JavaScript, but the design supports the use of other dynamic languages as well.

Sun may already have this. Will they be able to market it? Unfortunately, the track record isn’t there, so it will probably languish. Buy maybe not.

Posted by Dion Almaer at 8:23 am

4.1 rating from 28 votes


Comments feed TrackBack URI

Microsoft IIS has supported Javascript (JScript) as a server side environment for years. I use it daily.

I’m concerned that the current support will fall off.

Guess we will see.

Comment by Kris — November 11, 2006

Server-side JavaScripting is already there, it’s just not wide-spread. I see hype coming.

Comment by kourge — November 11, 2006


Comment by mikael bergkvist — November 11, 2006

a couple of years ago I worked at a place that used server side javascript as the development language supporting it’s web app. It did make interfacing between client and server easier. I’d wouldn’t mind using it again but would have two main concerns – speed and lack of a built in support for true Object Oriented developement. I know we can all fake it to various degrees in JS but it would nice to get rid of that overhead. I’ve heard rumors this will be the case in ecmascript 4. Another thing of note- JS is not a strongly typed language. But ya know I kind of like that freedom.

Comment by Hans Brough — November 11, 2006

In Apache Cocoon your Webapp logic may be written in JavaScript (in Cocoon it is called FlowScript, based on Rhino with Continuations).
It is a very productive environment !!

Comment by Jerm — November 11, 2006

The big question is. What’s the point?

We’re starting to get into more mature compiled languages like .NET and Java running our websites. Do we really need another PHP?

Comment by Harlequin — November 11, 2006

Javascript has been there all along, it’s an intergrated part of the web, there’s nothing new about it, and that’s the whole point.
Everyone knows how to use it because it’s in the browser – you can’t really avoid it.
Using it serverside means there’s one less thing to learn and get distracted by.
While learning is part of the joy of life, it’s also a matter of going ahead and actually build stuff, and being able to focus on that, and the constant changes of the server environments and the rebuilding of apps as a result, are sometime distracting and tiresome.

Comment by mikael bergkvist — November 11, 2006

Hey guys,

We’re trying to keep our db storage costs down so please try to limit your comments. (looking at you mikael)

Comment by Dion Almaer (actually someone else who used my name) — November 11, 2006

Umm didn’t we happily kill that like 8 years ago? Netscape Enterprise Server had support for Javascript as a Server Side Language.
Those who fail to remember the past are doomed to repeat it.

Comment by Vance Dubberly — November 11, 2006

Actually, most new technologies appears once or twice before being finally accepted, and ypu know what.. the same is true for ajax itself.

Comment by Sam — November 11, 2006

Besides the already listed old solutions above which supported server side JS, also Broadvision used this technologie in their server applications (BV One2One etc.) about 8 to 6 years back. Scripting in JS, extensions in C++. And they switched to Java so they could extend and script all in one language.

Comment by Dirk Steins — November 12, 2006

To cite :
“Helma is an open source web application framework for fast and efficient scripting and serving of your websites and Internet applications.
Helma is written in Java and employs Javascript for its server-side scripting environment, removing the need for compilation cycles and reducing development costs while giving you instant access to leverage the whole wealth of Java libraries out there.”

It’s mature, stable and fast (used for sites with more than 100k dynamic pageviews a day) an developing applications with it is fast and joyful (thanks to it’s builtin ORM features and the easy integration of Java libraries)

Comment by Stefan Rinner — November 12, 2006

Manual trackback

Comment by Michael Mahemoff — November 12, 2006

I would take PHP over JavaScript for server-side anyday. Or even RoR for that matter.

/me waits for the flames

Comment by shorty114 — November 12, 2006

I love it. I wish I could use just one language for all my needs, and since javascript won’t be replaced anytime soon from the browser why not move it to the server?
Netscape had a great idea killed by history. Let’s see if the mozilla guys can make it real, or Sun, or IBM, but for god’s sake not M$ noooooo.

Comment by scripkiddie — November 12, 2006

I would prefer to use server-side JavaScript than PHP.

Comment by kourge — November 12, 2006

I love Javascript, but its simply too free as a language to be a good middleware layer. I do agree that it will work on the client side ,and I expect a lot more action on the front end while the backend servers will have less and less to do with Javascript.

As it gets closer to front and center, tools will evolve that will deal with solely Javascript and HTML as a platform. Aptana is a good example.

Comment by Ivan Lazarte — November 12, 2006

I don’t see a big advantage in having a single language. I like to use each language for its strengths. My biggest issues with Javascript as a language are the lack of namespaces and the poor data structures. On the other hand, I like where the language is going. If it turns into Python with curly braces and prototypes rather than classes, I won’t complain.

Comment by Karl G — November 12, 2006

Javascript is good at what it is used for on the client, but not great. It could be better. To use it on server would be disastrous. If you want a loosely typed, single threaded language to run your applictions you’ve got issues. And it’s already been done, several times, as several people have pointed out. Does anyone research their dumb-ass comments before posting? Tomorrow’s post: I hope that someday in the future they have the Internet on computers.

Comment by Dan — November 12, 2006

I suspect that there are territorial issues involved, some pushing for their favorite languages, but using javascript serverside is hardly ‘disastrous’. :-)
I’ve done it for a long time now, and sofar those disasters are nowhere to be found..

Comment by Sam — November 12, 2006

Back in the day JavaScript was called LiveScript before the Sun-Netscape rebranding. Netscape had a suite of products, including Netscape Communicator (the browser), that could be scripted with JavaScript. The server-side exposed objects that could be scripted with LiveScript (aka JavaScript), and even had a Corba ORB that was also on the client-side for client-server communication.

While I wouldn’t want standard JavaScript 1.5 or less on the server-side, being able to do ECMAScript 3.0 on the server-side would be nice.


Comment by Brad Neuberg — November 13, 2006

Hi, I’m the Phobos architect. I’d like to point out this blog entry. As you can see, we’ve been working on making development of Phobos applications even easier. At least, it goes to prove that the project is not languishing, quite the opposite. ;-)

In our experience, JavaScript (with Mozilla Rhino) works fine as a server-side language, especially in the context of Phobos, where we are happy delegating big, heavy tasks to existing Java libraries (e.g. persistence, HTTP server, Web services). By the way, an earlier comment about JavaScript being “single threaded” is off the mark, we do support multiple threads and use the Java concurrency APIs to synchronize between them. In Phobos, JavaScript ends up being used as a glue between the different components and to write core application logic and dynamic HTML page snippets, tasks for which it is well adapted. Having a real debugger helps too!

Comment by Roberto Chinnici — November 14, 2006

umm no

Comment by char — November 16, 2006

We called it ASP 3.0 + DHTML back in the days! Of course, there wasn’t any really serious or interesting community around JavaScript at the time, so you had to develop most of your server-side framework and libraries from scratch on your own island in order to build something manageable, but now that JavaScript is becoming some kind of lingua franca, I suppose it could become a livable option…

I just wouldn’t personally go back, as a developer, to being mainly a JavaScript expert, though. Diversity is good. Besides, JavaScript knowledge is too cheap to build a career on it.

Comment by philigran — November 16, 2006

Javascript end-to-end is a really interesting solution. Project Phobos seems interesting as well.

Comment by George Moschovitis — December 8, 2006

“Besides, JavaScript knowledge is too cheap to build a career on it. ”

That might be true if you are a developer, but if you are building a service, the choice of language doesn’t matter, only the results.
If there is a manageable and reliable approach, which is also consistent and where there is a lot of know-how, like with javascript, then it’s a viable approach for sure.

Comment by Sam — December 17, 2006

Javascript is a very nice language for the client side but it still lacks a lot in terms of OO features. Reminds me of the nightmare ASP was (good for small web apps but a real pain in large projects). I would consider moving back to JS only if it was truly OO like Flashscript (I love this one and wish to have it in our browsers soon!), offered packages and was backed up by a decent community. But to be honest, I dont really see the point. There are already enough languages on the backend without adding another one. Learning PHP or Java is probably a smaller overhead than learning a new JS environment, waiting for hosting companies to support it, a community to build up (+ getting our clients to have confidence in it)..

Comment by Franck Yvetot — December 18, 2006

Leave a comment

You must be logged in to post a comment.