What's wrong with JavaScript?
Reading Jon Udell’s excellent post on languages and libraries, I wonder how we ended up with widespread support for a standardized programming language in the browser that (almost) nobody is using on the server side? I never really invested time in really learning it, but the little I know about it doesn’t suggest any reason why it should not be comparable to Ruby or Python. It’s highly dynamic, it runs on the JVM and the .NET platform, it’s got extremely cool support for XML programming … what am I missing?
Update: Fascinating follow-up from IONA’s Steve Vinoski:
Open source middleware projects like Celtix and Tuscany are getting Javascript support. Adding such support to Celtix is what I’m personally working on at the moment, in fact.
Type “JavaScript sucks” into Google, and you’ll get some reasons why it’s not popular.
Few of them seem to be related to the language, most of them are related to the browser, their implementation, environment issues such as debugging, etc. Strangely, the Ajax wave embraces JavaScript, including all those quirks, while on the server side — where everything could, in theory, be better — it simply does not seem to exist.
As you know we use Rhino, the JavaScript engine for Java once built by Mozilla, as server side scripting language in our CMS product Webgate Anywhere. While I still think it is a cool platform for “traditional” scripting tasks I also think it is surely no language to build larger object-oriented stuff with it. The prototypical object orientation feels only good while you keep your object library small. Otherwise it is an organizational nightmare. Also the variable scope rules of JavaScript are somewhat counter intuitive, at least to me. Besides that, JavaScript/Rhino offers many things that the other scripting languages “of the rage” are praised for, like integrated XML support, closures and the like. Networking support is somewhat missing in the spec. It surely is a clever little language, but - like I read somewhere else - it is always obvious that it was invented and implemented over a long weekend. But hell, since I do not know any other scripting language that close, maybe they are all like that :-)
I have argued that Javascript is the poor cousin of dynamic languages.
It’s principal failure is because most common distribution of Javascript (in Browsers and in Windows Scripting) do not provide any way to import modules. Because of this, Javascript development tend to be ad hoc rather than library-based.
Oliver, can you elaborate on the maintenance nightmare thing? What is it that makes it more likely to build bad code in JavaScript than in, say Java? Is it the lack of module support Chui Tey mentions (although I suspect that’s not a problem for Rhino)?
Defining object types in javascript is a rather “loosely handled” thing. Object type definitions just consist of a bunch of functions that, besides the functional code using a “this”-object, have no special indication that they form an object type. One function is the constructor. Besides normal initialisation tasks it is responsible for setting those functions, that shall become methods, as properties on the newly created object (as functions are only objects just like anything else in JavaScript).
But again, there is no way to tell the intended usage from the definition syntax. Those functions could all just be simple flat procedures to call directly, or they could be contructor and methods of an object. Noone would keep you from calling object methods just as functions without an object, besides that the code most likely wouldn’t work. Noone would keep you from using the wrong function as a constructor.
This, some possible variants in how to define method functions in and outside the constructor (where each developer may use her own flavor, making object definition even more messy), the lack of method scopes and the lack of any java-package-like organisational structure makes it IMHO quite easy to mess up code for large object libraries.
As for the lack of module support: This is indeed no problem in rhino since it can use any java library in the classpath without need for any interfacing.
Thanks Oliver, that’s helpful. And it does indeed sound extremely messy :-)
See for example www.processing.org for a cool application of javascript.
Errr….
Javascript as a server-side scripting language was one of the VERY FIRST ideas they had.
It had its day and is now passe. It used to be the tool of choice many years ago when Netscape’s web server was still enjoying mindshare. It’s also still supported by IIS up to today (server-side Jscript).
Overall, the Javascript server-side environment is inferior (e.g. neglected, impoverished) to what is provided by environments like Python, PHP, Tcl, Perl, etc…
I’m not suggesting JavaScript on the server side would be a new idea — I just wondered why it never really caught on.
Another point ought considering is that not many people grok prototype-based languages the way they understand OOP.
The prototype approach is simply not taught or covered as comprehensively. This is why we see so many attempts at reproducing OO in Javascript. I also believe prototype-based languages suffer from the inherent problem of combinatorial complexity. Since an object cannot be described by a “class”, it can get awfully difficult to figure out what an object is capable of.
Although JavaScript has introspection capabilities, they are quite weak compared to a language like Python. One has to dir() through an object to find all it’s attributes. Given that javascript functions do not have documentation strings, all one gets is
You know, lately I’ve been wondering exactly the same thing. It seems to me there are a couple of big benefits you could gain. The first thing you’d gain is a DOM-aware language. This is huge because you could manipulate portions of the page using DOM methods rather than constantly outputting text directly to the output. Which would be fantastic as any code generated using the DOM would, by its very nature, be standards compliant. You’d never have to remember to encode your ampersands in URls or whatever. Developers in other languages frequently have to code around how difficult it is to modify a portion of the document that has already been processed. With DOM methods, you have access to the entire document all the time, so modifying code that has already been generated is just as easy as the original generation.
And because you’re using DOM methods, the code that generates your document on the server side can be the same code that generates it on the client side in AJAX apps. This is a huge productivity gain, you can forget about having to write two different functions in two different languages that use two wildly different methods to generate the exact same output. A well thought out implementation would even allow exposing server side objects on the client side in a very transparent manner.
And if the implementation were especially clever, database access could be significantly easier. Specifically, data returned from the database could be automatically cast to an anonymous object, which is obviously expressible using object-literal notation. From there, it’s easy to imagine client-side XMLHttpRequest calls being little more than direct database queries, and the code that handles the response on the client side exactly the same as the code on the server side.
The comments I’ve read here and other suggest that Server-Side Javascript has had its day in the sun. Yes it has, and it sucked. But let’s be honest here, the language itself, as well as the level of expertise in the language, has evolved dramatically from SSJS’s heyday. I think it’s time for a second pass at it.
We just released an RC1 of the new version of our open source project, the Helma Javascript Web Application Framework. If you want to explore the use of Javascript on the server-side for a change, this is an ideal time :-)
Helma is an open source web application framework for fast and efficient scripting and serving of your websites and Internet applications. Our goal is exactly what Mark described, taking that second pass at Javascript on the server-side by beginning to bridge the server- and client-side like you wouldn’t be able to do it when not using the same language “on both sides of the environment”.
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.
Helma pioneered the simple and codeless mapping of application objects to database tables, which has only recently come into vogue with other web frameworks. In addition, an embedded object-oriented database performs automatic data persistence of unmapped objects.
New features in Helma 1.5 include a flexible new way to load multiple code repositories, many low-level improvements and features such as updateable collections, additional web-based development tools that can run inside your applications and complement existing external debugging and database management tools, and a library of Javascript prototypes and methods that extend the Java based core of Helma.
You can download it here and take it for a spin:
http://helma.org/download/
We have also put together a welcome application that will provide you with a quick introduction:
http://welcome.mocha.ch/
This web app is also what will run on your local system after you download and install Helma 1.5.
Hi Stefan,
Actually, server-side javascript(SSJS) is pretty easy to use. If Netscape had not been bought out by AOL, javascript might have been a dominant language on the server-side. Anyway, it won’t be too long before ordinary bloggers and web users want their own servers and SSJS becomes more prevalent. By the way, Helma is more like Rails. If you like php-style server-side javascript, firecat maybe a better fit:
http://firecat.nihonsoft.org