Become a fan of Slashdot on Facebook


Forgot your password?

Trying To Bust JavaScript Out of the Browser 531

eldavojohn writes "If you think JavaScript is a crime against humanity, you might want to skip this article, because Ars is reporting on efforts to take JavaScript to the next level. With the new ECMAScript 5 draft proposal, the article points out a lot of positive things that have happened in the world of JavaScript. The article does a good job of citing some of the major problems with JavaScript and how a reborn library called CommonJS (formerly ServerJS) is addressing each of those problems. No one can deny JavaScript's usefulness on the front end of the web, but if you're a developer do you support the efforts to move it beyond that?"
This discussion has been archived. No new comments can be posted.

Trying To Bust JavaScript Out of the Browser

Comments Filter:
  • by slug359 ( 533109 ) on Tuesday December 01, 2009 @12:34PM (#30284558) Homepage
    Here's my three favourite language flaws, which make the language nearly unusable for non-trivial projects:
    • Variables are global by default, leading to accidental memory leaks, conflicts and various other fun things.
    • A lack of namespaces.
    • Lack of block scope (despite the fact the language has blocks), i.e:

      function a() {
      var b = 1;
      var b = 2;

      will alert 2.

  • Re:Why bother? (Score:5, Informative)

    by jellomizer ( 103300 ) on Tuesday December 01, 2009 @12:45PM (#30284702)

    Yes lets put all the work on the server. The server should handle all formatting and every single error check and lets wait for the server to respond and reload the entire page to say something is wrong. Lets not have the ability to hide or move objects, because we need to reload the page over and over and over again... Never mind CPUs are Really fast and the standard Desktop has ton of memory. Lets fill up the slower bandwidth with reloading the same information over again.

    Sorry your post is screaming, I am not comfortable with JavaScript and it is effecting my 7337 status. So I will insult it so I can seem like I am skilled programmer.

  • by slim ( 1652 ) <john@hartnu p . net> on Tuesday December 01, 2009 @12:51PM (#30284792) Homepage

    This is the book that'll make you realise Javascript is OK: []

    It's not afraid to call out the bad parts, and to show you how to work around them. That's down to a rushed standardization process.

    It doesn't deal with the DOM at all - after all, that's not part of JS.

    It leaves you thinking JS is pretty neat, if you use it right.

  • by Rayban ( 13436 ) on Tuesday December 01, 2009 @12:54PM (#30284842) Homepage

    All strings coerce to boolean true in JS, as they do in C (with the exception of the empty string):

    char* a = "false";
    if (a) {
        printf("a is true?\n");

    In fact, most values coerce to true except integer zero, NaN, undefined, null and empty string.

  • by brundlefly ( 189430 ) on Tuesday December 01, 2009 @01:23PM (#30285214)

    >> The willful violation of the javascript object model for document.all in HTML5 (see bottom of page) is one particularly nasty example...

    Not really nasty to implement at all:

    get document all() {
    return document.getElementById.apply(document, arguments);

    That's interpreted code, of course, not native code. But if you're in the business of writing parsers and compilers, rolling that into native code is about a 10-minute operation.

    Now... I might agree with you that it's misleading to newbies to design a language such that a potentially ubiquitous and expensive call to an external technology (the DOM) is hidden behind a seemingly innocent property lookup. But there again, expensiveness of such a call is an artifact of how browsers are coded, not a deficiency in design.

    In principle, there's nothing wrong with providing a associative-array-like API to an action which performs a flat lookup within a namespace of unique keys [albeit admittedly unenforced in this case]. Python, Ruby, JavaScript and most other functional languages offer this functionality as standard fare.

    Pick a different example....

  • by Procasinator ( 1173621 ) on Tuesday December 01, 2009 @01:32PM (#30285334)

    The absence of a trim method is not a DOM problem: I should be a method available on String.

    As for the lack of this consistency, this is due how Javascript scopes references to methods. Being able to change this behaviour can be handy at times, but often not the expected behaviour.

    Read [] to see how apply/call can help set-up the correct binding for this and a method.

    JavaScript behaves this way to support prototypal inheritance.

  • by rycamor ( 194164 ) on Tuesday December 01, 2009 @01:44PM (#30285520)

    If you delete an array key directly with the delete command, eg: `delete myArray[4];` the length property doesn't get updated even though the number of elements in the array does. (WTF?!?!)

    That one I can't speak to... interesting if true.

    Yes, delete will mull the value of an array element but leave the index. To remove an array element, use splice(), which removes AND returns the indexed element in question:

    js> arr = [4,5,6,7];
    js> print(arr.splice(2));
    js> print(arr);
    js> delete arr[1];
    js> print(arr);

  • Re:Beyond What? (Score:1, Informative)

    by Anonymous Coward on Tuesday December 01, 2009 @01:55PM (#30285682)

    The only similarity between JavaScript and Java is the word "Java".

  • by aztracker1 ( 702135 ) on Tuesday December 01, 2009 @02:07PM (#30285914) Homepage
    Actually, JScript 5.x was pretty much ECMAScript 3.x compatible, the only real thing it added was the support for ActiveXObject (for COM/ASP interaction) and an enumerator (since COM enumerations & recordsets weren't treated like Arrays). I used JScript with classic ASP a lot, since I could use the same scripts on both the client and server for some communications, and manipulations. The biggest issue with JScript server-side in classic ASP was in working with ADO recordsets.
  • Re:c++ is good (Score:5, Informative)

    by dgatwood ( 11270 ) on Tuesday December 01, 2009 @02:09PM (#30285946) Homepage Journal

    The logical fallacy is only because the quote has gotten distorted severely over the years. The original saying, translated to English from Old French, reads "Bad workers will never find a good tool." This version makes much more sense.

    Source: [].

  • by maxume ( 22995 ) on Tuesday December 01, 2009 @02:09PM (#30285956)

    You haven't addressed the part where document.all needs to return a special collection type that breaks the object model in several different contexts (when passed to toBoolean, it should evaluate to false, which breaks the object model, and there are a couple of contexts where it should evaluate to undefined...).

    Understand the example...

  • Re:Why bother? (Score:3, Informative)

    by Glabrezu ( 215236 ) on Tuesday December 01, 2009 @02:13PM (#30285990)

    "One of the few popular languages with first-class functions"? Allow me to disagree but almost every dynamic language I know of has first-class functions.

    Other languages, like C, C++, C#, also allow you to use functions as a data type.

    I agree that, in some of them, their syntax does not make it easy to define functions as, for example, an argument, but you can define the function first, and pass it as an argument later if needed.

    Closures are another thing altogether, but they are supported on many dynamic languages.

  • by kbielefe ( 606566 ) <> on Tuesday December 01, 2009 @02:26PM (#30286234)

    so until and unless major browsers start implementing things like JIT compilation

    Wish granted [] (at least for chrome).

  • by Anonymous Coward on Tuesday December 01, 2009 @02:57PM (#30286786)

    See Objective-J

    That is an indication of the power and elegance that Javascript might have outside the browser.

  • by shutdown -p now ( 807394 ) on Tuesday December 01, 2009 @03:04PM (#30286910) Journal

    So, what was your point? That you can use the var keyword twice in a scope block?

    The point is that variables are scoped to functions, not to blocks like in all other C-style family languages (and all other languages which permit variable declarations within blocks; the only other exception I'm aware of is VB6).

    What's worse is that the second "var" looks like a variable redeclaration, but ends up being a simple assignment.

    Compare with C++:

    void foo(int n) {
        int y = 123;
        if (x > 0) {
            int y = 456; // shadows outer declaration
        cout << y; // 123, as it should be

    Java and C# go one step further, and prohibit shadowing of locals altogether. E.g. C#:

    void foo(int n) {
        var y = 123;
        if (x > 0) {
            var y = 456; // error, y already declared in local scope

    JavaScript approach is worst of all: it's inconsistent with conventional behavior, it lets you declare variables anywhere within the body even though it doesn't affect their scope (so no good reason to allow it), and it silently ignores the "var" declaration (treating it as plain assignment) rather than raising an explicit error.

    Even VB6, which also scoped locals to the entire function body regardless of where inside it they were declared, would raise an error if it would see two declarations clash in the same scope.

  • Re:Why bother? (Score:4, Informative)

    by Carewolf ( 581105 ) on Tuesday December 01, 2009 @03:36PM (#30287488) Homepage

    I know exactly what a let form is. The code was not scoped so it was already on global level, declaring variables local in global scope doesn't do much. This did on global level exactly what let would in a procedural language. That is define the value for all following statements (for functional languages, all embedded statements). If you need let-embedding add a lamba expression (called function() in js), and you get nice scoped variables.

    Of course I would have gone for something a little more complex than a LET form...

    Sure.. but given JS expressive power, I dare you.. Especially compared to LISP.

    If you ask for threading though, I yield ;)

  • Re:Why bother? (Score:3, Informative)

    by kdemetter ( 965669 ) on Tuesday December 01, 2009 @05:02PM (#30288810)

    I know, the commas in my sentences make no sense at all.
    I just type them automatically, without thinking about it. It's a bad habit which is hard to lose.

    Anyway, thanks for reminding me.

  • by Spliffster ( 755587 ) on Tuesday December 01, 2009 @06:37PM (#30290132) Homepage Journal
    This is silly. The story is about a common Serverside Javascript implementation standard and not about whatnot is faster. For those who haven't RTFA it's about standardisation of JavaScript on the server side (JS has really only lived brightly in the browser so far with it's enormous install base on the client side). Cheers, -S
  • by Anonymous Coward on Wednesday December 02, 2009 @06:42AM (#30295468)

    Javascript was designed to be a scripting language, using it as a host language is quite possible.
    I am using Google V8 implementation as a scripting language for C++ application. It's like using SQLite, it's VM read SQL language and run it while the database engine is C. There are many things you can do with it:

    1. You can easily expose C++ functions to Javascript, since the host C++ application already build and compiled, using Javascript can customize the app behavior, such as combining several functions into one batch.

    2. You can save app settings and options directly to Javascript and just run it, you don't even need a parser to read config file this way. I have not found a way to let Javascript do heavy lifting, for example here is a CRC function expose to Javascript, the file reading and calculation threads are C++, Javascript just feed in the filenames and wait for the result. The only namespace concerns me is C++ namespace. I am not side-stepping the performance issue, scripting is just the way it is.

    3. If you expose variables, you can access them inside Javascript space as well. With it's simple, no non-sense and concise syntax, you can write an entire test suite for your application in Javascript with ease.

    4. You can modify the language: say I have a tokens() function in C++ which can be called in C++ and Javascript with tokens( "a string", delimiter ). Now I can modify the Javascript language like the following:

    String.prototype.tokens = function( delimiter )
            if ( typeof( delimiter ) == "string" )
                    return tokens( this, delimiter );
            else return tokens( this, " .,;:-_/\\|\n\r" );

    Running this from RC file, I can now do something like "hello how are you?".tokens() in Javascript. I am no Javascript expert, but this is quite flexible.

    5. There is NO DOM.
    You app is the DOM, or whatever you design it to be.

    6. There is no access to the outside world. You cannot even read/write a file, I have to provide my own library for it, but then I am in total control. While in C++, you use fopen, iostream or even boost::filesystem access anyway. You can just bind a fopen()/fread()/fclose() or iostreams to a Javascript function and then you have all the access you need. You have access to anthing the host language or external libraries provides, with a simple binding you can access them inside Javascript as well.

    The combination of Javascript and C++ is very light weight and very fast ( at least with V8 ). I imagine doing the save with pure Java would cost 3 times more memory and no scripting capability, but of course I have no proof. But if you Java GUI it will certainly consume much much more memory.

    Either you add features to your application, or using Javascript as a job-control language, sometimes scripts are one-time throwaway. Sure you can do most of the above mentioned with some other language, but Javascript syntax is clear, concise, no "let's just do something different" syntax like using "\" in path kind of thing. For newbie, a clearly structured language is MUCH easier to learn. For C/C++ or Java programmer, Javascript is dead easy to lean. Big companies like Adobe are using it on all their apps, or some variations of Javascript. Why shouldn't you?

    Sure, there are no "standard" libraries in 2D/3D, OpenGL, GUI or what's not, but if you can connect them to C/C++, you can expose them to Javascript. But you should think about if using Javascript as a host-language is really what you want in the first place. I have no prior programming experience in Javascript, just looking for a concise, simple language for scripting applications, preferably C-like. All the duct-tape shell scripting languages are less flexible, there are a few C-like scripting languages but too slow and development are slow. Newer languages suffer from weird syntax and structureand pure bad tastes. I choose Javascript for what it provides, not because it is being used in browsers.

As of next Tuesday, C will be flushed in favor of COBOL. Please update your programs.