Comments on: Next Big Language = JavaScript

by: Chui Tey

Fri, 29 Jun 2007 07:59:55 +0000

Javascript can potentially be pretty fast, considering it’s Self-heritage.

On top of it, MS has already shown how optional type annotations on JScript can make a language both dynamically and statically typed.

There are some pretty cool implementations of coroutines and tasklets on top of Javascript as well.

Rhino offers continuations, something Seasiders have enjoyed for years.

by: Matthew Mondor

Thu, 28 Jun 2007 23:51:07 +0000

You can use threading with SpiderMonkey without problems, but the JSAPI-using C stubs also need to be thread-safe, obviously. I don’t think that exporting an API to allow JS scripts to control threading themselves would be impossible, but it’s generally not necessary (the C/C++ application can control threading and run concurrent user scripts).

I agree that JavaScript is an interesting language. In fact, some time ago I wrote a framework to easily code various applications on unix using it (http://mmondor.pulsar-zone.net/ has more information on it for those interested). The site itself is served by a test HTTPd that was written in JavaScript. The code is open under a BSD-style license. There were eventual plans to write a web development server-side framework with a custom JSON-based fcgi-like protocol but I couldn’t dedicate time to complete this lately. Maybe someday.

As for the furure planned features to JavaScript, I’m not convinced that creating a general purpose Java-like language from JavaScript is a great idea. I use it for things which don’t require the performance of C and which take advantage of its very dynamic nature (part of which is lost if using the class-based model rather than the protype objects one). But why not, since applications will be able to use both.

by: Andrew Gwozdziewycz

Thu, 28 Jun 2007 10:56:51 +0000

“First, with JavaScript there isn’t a good way to avoid shipping source code. Sure, you an obfuscate JavaScript with various tools, but the results remains far for amenable to readable-source recovery than in a more traditionally compiled language.”

I’ve been under the impression that something like Rhino would be used to run javascript as a _server_ side language. If that were the case, you wouldn’t have to send the client _all_ the javascript. Just that that gets run for display purposes like we do now. I don’t see a problem there.

by: James F

Thu, 28 Jun 2007 07:29:33 +0000

One thing I see holding JS back (and perhaps this has been addressed in ecmascript 4) is a complete lack of threading. I will openly admit to not having written a lot of javascript, but I don’t see it going very far if it is constrained to a single processor, as we already have common dual-core and quad-core machines and 8-16 core is surely just around the corner. I think this is especially important in a dynamic language such as JS where performance is already (generally) below that of a compiled language such as C, and a developer needs access to every potential speed-up they can muster.

Another issue I guess, would be the lack of a really good development environment. Firefox + Firebug + Web Developer toolbar is great, but I don’t think it currently competes with polished environments for mainstream languages, such as VC++ or KDevelop for C++, VS.Net for C#/ VB.net/ C++/cli etc.. However, when I started developing an application in Python recently, I found the adhoc text processor + IDLE setup to be beneficial to development, so perhaps this isn’t such an issue (for small projects, anyway).

Given the very Java/C-like grammar and syntax of Javascript, I image that wide-scale adoption will come much more easily than would wide-scale adoption of many of these other newer dynamic languages. Some of the available AJAX applications today really do demonstrate how effective Javascript can already be,so I can’t wait to see more..

by: foo

Thu, 28 Jun 2007 02:24:51 +0000

Apparently you’re out of the loop, this was the consensus several months ago.